意外的上下文变化（自动跳转、自动提交）会打断用户的预期
别名: 自动跳转 · 自动提交 · on focus on input
概念解释
焦点落到某项就打开新页、选完下拉就提交整张表、倒计时结束把人甩到别处——上下文在用户没发出「走」的指令时先变了。意外的上下文变化（on input context change）打断的是「我还在做这件事」这条预期。认知障碍用户把意图捡回来的成本更高，常常表现为不知道自己被送到了哪、刚填的内容还在不在。
自动播放的运动停在同一页里抢注意，是另一条。产品换版本把导航整体搬家，也是另一条。这里只处理当前会话里，界面在用户未请求时换了地点或提交了数据。
机制
人按稳定上下文规划下一步：还在这张表上，下一个控件是下一个字段。自动跳转或自动提交是一次强制任务切换，外加用户正在建模的表单状态可能被提交或丢弃。执行功能受损时，切换本身就会把目标从工作记忆里挤掉；再面对一张突然出现的新页，人无法把「我刚才在填地址」接上去。
焦点变化就导航，对只靠键盘的人尤其严重：Tab 本意是移动焦点，不是激活。输入即提交把「我在比较选项」误判成「我已决定」。两者都违反同一预期：改变上下文的动作应当是用户明确发出的（按下提交、按下链接），而不是焦点或值变化的副作用。
怎么研究
只用键盘走完带下拉、单选、日期控件的表单：改每一个 select 和 radio，页面不得导航或提交。符合性对应「焦点上不改变上下文」「输入上不改变上下文」，除非事先告知且可撤回。
自变量：onchange / onfocus 是否触发导航或提交、自动跳转是否可取消、跳转前是否有足够阅读的提示。 因变量：意外提交次数、焦点移动导致的离页次数、中断后能否回到原字段。
会话超时把人踢到登录页，是时间限制与意外换页的叠加：若超时静默提交或清空，两条一起失败。
边界
用户点了链接或提交按钮，跳转是预期。登录成功后进入原目标、且目的地可理解，通常可接受。单页应用在点击导航项后换路由，只要是该点击的直接结果，不是意外。安全上的强制登出需要事先警告并保住草稿，不能毫无提示地瞬间换页。自动保存草稿而不换页、不提交，不属于上下文变化。
怎么落地
- 禁止在焦点进入或值改变时导航或提交；提交只绑在明确的提交控件上。
- 必须自动跳转时（例如即将离开的会话），给出可打断的提示与剩余时间，并说明跳转后数据怎么办；用户应能取消。
- 验证：只用键盘改遍所有选择类控件，页面不得跳转或提交。再打开一个带延时跳转的地址，在倒计时内必须能取消并留在当前页。任何 onchange 提交，即使「能加快流程」，也判失败。