检测焦点顺序问题需要实际用键盘遍历而非仅检查代码顺序
别名: 键盘走查 · Tab 遍历检测 · source order inspection
概念解释
源码里的 DOM 顺序、tabindex 列表、无障碍树的快照，都可以看起来「没问题」，而手指按 Tab 时走的是另一条路。检测焦点顺序的方法是键盘遍历本身：把指针拿开，从浏览器控件 Tab 进页面，一站一站跟到末尾。代码检查是假说，遍历才是测量。
自动化能列出可聚焦节点，列不出「焦点被粘性页眉盖住」「Shadow DOM 把序列接错」「视觉上的下一步其实要先穿过隐藏菜单」。那些只出现在按键的那一拍。
机制
焦点序列是运行时产物。参与计算的不只是源顺序：还有用户代理对原生控件的默认、正负 tabindex、disabled / inert / hidden、Shadow 树的扁平化、iframe 的嵌套浏览上下文、以及「视觉上被 overflow: hidden 裁掉但仍可聚焦」的节点。静态审查看到的是作者写下来的意图，不是合成后的序列。
还有一层物理现实：焦点指示落在粘性栏或 cookie 墙下面，代码顺序完全正确，人却看不见自己在哪——这是顺序体验失败，只有盯着屏幕按 Tab 才会发现。放大镜把视口缩成一小块时，错误会放大：焦点跳到屏幕外，代码仍然「按顺序」。
怎么研究
把键盘遍历当作实验仪器，而不是发布前的手势。协议可以很简单：禁用指针；从地址栏进入；每按一次 Tab 截一张带焦点指示的图；与视觉预期并列。对同一 URL 至少覆盖：刚加载、打开过一次菜单再关上、提交过一次失败表单。这三种运行时状态的序列常常不一致，而仓库里的 HTML 只有一种。
自动化作前筛：标出正 tabindex、离屏可聚焦节点。前筛通过仍须人工遍历。WCAG-EM 抽样页每类模板至少走一整圈，不要只抽组件故事书里的孤立控件——孤立控件没有粘性栏，也没有页脚回跳。
边界
组件库里对单个控件做键盘单元测试是必要的，但不能替代整页遍历：顺序问题多数发生在控件与控件、控件与第三方脚本之间。阅读器浏览模式的快捷键走的是虚拟缓冲区，不是 Tab 序列，用阅读器「听一遍」不能代替键盘遍历。触控设备没有 Tab 圈，接上外接键盘或打开开关控制再测；用手指点一遍不算这条的检测方法。
怎么落地
- 把「禁用指针、Tab 走完整页」写成每类模板的必做步骤，不要用 lint 结果代替。
- 遍历时眼睛跟着焦点指示：被挡住、跳到屏外、走进已关闭的菜单，都记失败，即使 DOM 顺序看起来对。
- 验证：找一页「源码审查已通过」的模板，只按键盘走一圈。若出现审查没写过的跳跃，说明检测方法用错了仪器。