提交失败需把焦点移到首个错误字段
别名: 提交后聚焦错误 · first error focus · move focus on invalid
概念解释
点提交之后，键盘焦点通常还在按钮上。校验失败若只在远处画红框，人的操作点与出错点断开。把焦点移到首个错误字段指：提交被拒绝的同一拍，程序化焦点落到阅读顺序里第一个仍无效的输入，让键盘、开关控制和屏幕阅读器的「当前位置」与要改的那一项重合。首个按的是文档顺序里的第一处错误，不是随机一项，也不是最后一项。这条管的是焦点落点，不是把字段滚进视口的几何问题，也不是红框能不能只靠颜色辨认。顶部清单是否存在，不代替焦点移动。
机制
提交是一次注意重置：人的目标从「填」切到「送出去」，注视和焦点都在按钮。错误若只改外观，注意不会自动跳回字段，尤其当按钮在一屏底部、错误在屏幕外或在按钮上方很远时。焦点移动是系统替人做的一次定向：当前位置 = 要处理的对象。第二层是辅助技术的插入符。屏幕阅读器不读「哪里变红了」，只读焦点所在节点及其名称；焦点留在按钮上，播报仍是「提交」，错误等于没发生。开关控制和全键盘用户没有指针可点红框，焦点不走，任务就停在按钮上。选错「首个」——例如聚焦到隐藏的蜜罐字段或被 tabindex 打乱的后面一项——会把人送到无法编辑或不相关的控件，比不移动更糟。
怎么研究
提交一张含多处错误的表，比较「焦点留在按钮」「焦点到视觉上第一处错误」「焦点到 DOM 第一处错误」。参与者包括只使用键盘和屏幕阅读器的组。
自变量：失败后焦点目标（按钮 / 视觉首错 / DOM 首错）、首错是否在折叠区或隐藏字段。 因变量：从提交到开始编辑错误项的时间、键盘用户能否在不看屏幕的情况下改到第一项、屏幕阅读器是否播报该字段的名称与错误、误聚焦到不可编辑控件的次数。
实验室里鼠标用户会自己点红框，掩盖焦点失败。必须强制键盘条件和辅助技术条件。不要把「页面有没有滚动」当成焦点成功——滚动没有焦点，阅读器仍停在按钮。
边界
模态里的表单若把焦点移到遮罩外的字段，会把用户锁在模态下的页面里。单页应用在提交后整页重绘，焦点移动必须发生在重绘之后，否则落到被销毁的节点上。验证码、文件选择这类不能稳定接收焦点的控件，应聚焦到它的可聚焦代理（触发按钮或说明文本）。成功提交不应抢焦点到某个字段。实时失焦校验已经把人留在下一项时，不要在每次失焦时强行拉回首错，那会变成焦点争夺。
怎么落地
- 在提交被客户端或服务端拒绝的回调里，把焦点设到阅读顺序中第一个无效的可编辑控件，而不是留在提交按钮或跳到页面顶端。
- 首错的判定与 Tab 顺序、视觉顺序使用同一套阅读顺序；跳过
display:none、蜜罐和aria-hidden的节点。 - 移动焦点时一并暴露该字段的可访问名称和当前错误，使屏幕阅读器在落地时读到「字段名，错误原因」。
- 验证：只用键盘填到提交，故意留两处错误，确认焦点落在第一处而不是按钮或第二处。开屏幕阅读器重复一次，确认落地播报含字段名与错误。把第一处错误放进默认折叠的区块，确认焦点要么先展开再落入，要么落到可见的第一处错误，而不是落入不可见节点。