焦点顺序需与视觉顺序一致
别名: Tab 顺序 · tab order · keyboard sequence · 阅读顺序
概念解释
键盘用户按 Tab（或系统等价键）走过表单时，焦点经过的字段序列应与眼睛从上到下、沿阅读方向扫到的序列相同。一致不是「所有控件都能聚焦」——那是可达；也不是回车会不会提交。CSS 把「邮箱」画在「姓名」上面，DOM 或正 tabindex 却先落到姓名，就是顺序破裂。移动端「下一项」跳转是另一条通道，但若桌面 Tab 已经乱了，同一份 DOM 通常也会把移动跳转带乱。
机制
视觉顺序是人用来建「下一空是什么」的空间模型；Tab 顺序是键盘的实际路径。两者不一致时，人的手走到眼睛还没准备的字段，或跳过眼睛正在看的字段。第二层是布局与文档流脱节：绝对定位、网格里后写先画、浮动的「帮助」插进 Tab、正数 tabindex 把页脚链接插进字段中间，都会制造一条眼睛看不见的路径。双栏桌面表单尤其危险：眼睛按左列自上而下再右列，DOM 却按行左右走，或反过来。破裂的代价不是多按一次 Tab，而是把答案填进错误的框——因为人以为焦点还在刚才看的那一项。阅读器用户跟的是同一条焦点序列，视觉错位对他们是完全错的朗读故事。
怎么研究
把视觉顺序编号，把 Tab 顺序编号，算逆序对。再用键盘盲填（不看焦点环，只看字段），看填错栏。
自变量：布局（单列 / 双栏 / 含绝对定位的帮助）、是否使用正 tabindex、DOM 顺序是否与绘制顺序一致。
因变量：Tab 序列与视觉序列的逆序对数、填错栏次数、完成一组字段的按键次数。
不要只测「能不能到提交按钮」。能到但路径穿插，才是这条要抓的。屏幕阅读器的浏览模式（虚拟光标）和焦点模式可能不同，表单填写应在焦点模式测。
边界
视觉上并排的标签与输入，Tab 只应进输入，不应先落标签再落输入——那不是「与视觉一致」，那是多余节点。模态打开时焦点锁在模态内，表面上看跳过了背后的字段，这是焦点陷阱的正当范围，不是顺序错误。动态插入的错误文案若可聚焦，会在字段之间多出一个停靠点，应让文案不可聚焦、随字段一起被读到。从右到左界面的视觉顺序是从右开始，Tab 应跟阅读方向，而不是硬跟 LTR 的 DOM。
怎么落地
- 按视觉阅读顺序排列 DOM；不要用正数
tabindex修补。双栏时先决定人是按列读还是按行读，让 DOM 跟那个决定。 - 绝对定位的帮助、广告、页眉链接不得插进字段的 Tab 链；把它们放在表单前或后。
- 改布局后用键盘走一遍，给每个停靠点编号，对照设计稿的视觉编号。
- 验证：不看鼠标，只按 Tab 填完，焦点环走过的路径与视觉编号一致，零逆序对。把「邮箱」在 CSS 里挪到「姓名」之上、DOM 不动，作为必现的反例。开阅读器的焦点模式再走一遍，确认朗读故事与视觉故事相同。