键盘 Tab 键顺序：无需开发人员即可测试和修复

Tab 键顺序混乱不只是看起来凌乱，它可能让人完全无法使用您的网站。 按下 Tab 应当让焦点按合理的顺序依次经过每个交互元素，而焦点永远到不了的内容，对只用键盘的用户来说根本无法操作。您只需要 Tab 键，大约 60 秒就能测试自己的网站。

要点

• Tab 键顺序是有人按下 Tab 键时焦点移动的先后次序，不涉及鼠标。Shift+Tab 沿同一顺序向后移动。
• 这不是小众问题。 任何无法可靠使用鼠标的人，无论是因为手抖、瘫痪、重复性劳损，还是暂时性受伤，都完全依赖键盘导航来使用网站。
• 有两种不同的失败模式，其中一种比另一种严重得多。 顺序混乱令人恼火。而 Tab 完全到不了的交互元素，是硬性阻断，而不是可用性方面的抱怨。
• 您现在就可以自己测试，无需开发人员，也无需特殊工具。 点击地址栏，然后反复按 Tab，观察焦点去了哪里。
• axe-core 会以高置信度自动修复这个问题的一种特定形式，即 tabindex 的正值，并标记几个确实需要人来判断的相关问题，因为判断顺序是否“合理”需要理解页面。

Tab 键顺序到底是什么

按下 Tab 会把键盘焦点移到页面上的下一个交互元素：链接、按钮、表单字段，以及用户可以操作的任何东西。Shift+Tab 则向后移动。默认情况下，这个顺序遵循元素在底层 HTML 中出现的先后，通常与视力正常的用户从上到下阅读时遇到它们的顺序相同。

可见的焦点指示器，通常是围绕当前焦点元素的轮廓，让键盘用户知道自己在哪里。没有它，或者背后没有合理的顺序，键盘导航就无法使用，尽管使用鼠标的人看不出任何问题。

为什么这很重要

无法使用鼠标的人，无论是因为手抖、瘫痪、缺失肢体、帕金森病、渐冻症，还是像手腕骨折这样普通的原因，仍然需要结账、填写表单和浏览菜单。键盘是他们完成这一切的方式。屏幕阅读器用户也会用 Tab 键遍历交互元素，作为在页面中移动的几种方式之一，所以这与屏幕阅读器无障碍有重叠，但并不完全相同。

混乱的 Tab 键顺序是真正的可用性问题：焦点从页眉链接直接跳到页脚按钮，跳过整个页面中部，迫使人去猜测并回头。但最终仍然可以浏览。焦点完全到不了的交互元素，则是性质上不同，而不是程度上不同：键盘用户字面上无法用 Tab 到达的按钮，就是他们无法按下的按钮，仅凭键盘没有任何变通办法。

60 秒 Tab 键测试

1. 先点击一个中性位置，比如浏览器的地址栏，这样您从一个已知的位置开始，而不是焦点碰巧落在的任何地方。
2. 反复按 Tab，观察可见的轮廓如何在页面中移动。它是否按大致符合您视觉上从上到下、从左到右浏览页面时的顺序移动？
3. 尝试激活您到达的元素。 在链接或按钮上按 Enter，按空格键切换复选框。它在键盘上真的有效吗，而不只是在视觉上获得焦点？
4. 检查每个交互元素都有机会获得焦点。 菜单项、表单字段、按钮、日期选择器或手风琴之类的自定义小组件，都应该能通过这种方式到达。
5. 留意陷阱。 如果 Tab 或 Shift+Tab 曾经卡住，无法让您离开某个元素，那比单纯的顺序问题更严重，这是 WCAG 2.1.2 下的键盘陷阱，需要立即修复。
6. 确认您确实能看到自己在哪里。 如果焦点在移动但没有可见轮廓显示位置，那是一个独立但相关的失败，即 WCAG 2.4.7“焦点可见”，尽管它不是这里的主要话题，也值得记下。

混乱的 Tab 键顺序实际上是什么样的

tabindex 的正值。 试图强制特定顺序的开发人员有时会添加明确的数字：tabindex="1"、tabindex="2"，依此类推。这会覆盖文档的自然顺序，而且一旦以后有人添加新元素却没有对周围所有元素重新编号，它就会失效。

<!-- 失败：强制编号，之后会逐渐失去同步 -->
<input tabindex="3" name="email">
<input tabindex="1" name="name">
<input tabindex="2" name="phone">

<!-- 通过：不覆盖，由文档的自然顺序处理 -->
<input name="name">
<input name="phone">
<input name="email">

只改变视觉顺序、不触及底层顺序。 flexbox 或 grid 布局中的 order 之类 CSS 属性，可以改变视力正常的用户看到的内容，却不改变 Tab 键遵循的实际 HTML 顺序。结果是：鼠标用户和键盘用户在同一页面上体验到两种不同的顺序，而屏幕上看不出任何问题。

没有真正键盘支持的自定义元素。 一个样式做成按钮的 <div>，绑定了点击处理程序，却没有 tabindex="0" 也没有键盘事件处理，对 Tab 导航来说完全不可见。这不是顺序混乱，而是彻底阻断，因为键盘用户根本无法到达它。

仍然可获得焦点的隐藏元素。 已折叠的移动菜单，其链接在技术上仍然存在于页面中，或者本应不可见却仍能接受焦点的元素，会产生“幽灵”Tab 停靠点：焦点明显在移动，却移向用户看不见的东西。

axe-core 能发现什么，以及只有您能判断什么

规则	检查内容	修复路径
tabindex	元素有正的 tabindex 值	始终自动修复，重写为 0
aria-hidden-focus	隐藏的元素仍可单独获得焦点	自动修复，尽力而为，范围较窄：修复该元素本身，而不是仅仅包含可聚焦元素的隐藏容器
focus-order-semantics	实际 Tab 键顺序是否与页面的视觉和逻辑顺序一致	手动
scrollable-region-focusable	键盘无法到达或操作的可滚动区域	手动

这里的模式与其他每个值得坦率讨论的修复类别一致。tabindex 的正值是明确的，没有任何正当理由使用它，所以 axe-core 每次发现都会完全有把握地重写它。整个页面的 Tab 键顺序在逻辑上是否合理，则是关于那个具体页面想要表达什么的判断，需要一个能看着页面并做出决定的人。

Axeazy 在这里修复什么

Axeazy 会完全有把握地自动修复 tabindex 的正值，把它重写为 0，让浏览器的自然顺序接管。它还会自动修复范围更窄的“隐藏但可获得焦点”的情形，即一个在隐藏时不应被到达的独立元素。两者都是真实、可用的自动修复。

关于顺序是否真正合理，或自定义小组件是否内置了真正的键盘支持，都需要开发人员亲自查看页面。这不是 Axeazy 在隐瞒的缺口，而是这份清单中每个修复类别最终都会划出的同一条诚实界线：脚本可以有把握地重写一个属性，但无法决定页面内容在逻辑上应该按什么顺序阅读。

修复路径也取决于您的平台。在连接 GitHub 的 React、Next.js 或其他代码库上，tabindex 修复会以真实的 pull request 送达。在 Shopify 上，扫描仍然会发现它，但没有自动的代码更改，它会成为引导式清单中的一项。在 WordPress 上，这一特定类别不属于免费插件的三项即时修复（跳过导航、语言属性、替代文字后备），因此目前在 WordPress 上也没有自动路径。查看完整的修复类别说明。

常见问题

Tab 键顺序混乱与键盘陷阱有什么区别？

Tab 键顺序是有人按 Tab 时焦点移动的先后次序。键盘陷阱更严重：焦点卡在一个元素上，Tab 和 Shift+Tab 都无法让它离开。顺序混乱是可用性问题。陷阱则是硬性阻断，而且它本身就是一条独立的 WCAG 要求，即 2.1.2“无键盘陷阱”。

添加 tabindex="0" 能解决一切吗？

它能让原本无法获得焦点的元素（比如样式做成按钮的 <div>）可以通过 Tab 到达，并把它放进页面的自然文档顺序中。它并不保证那个顺序合乎逻辑。元素在实际 HTML 中所处的位置，仍然决定它何时获得焦点。

如果正的 tabindex 会引起问题，开发人员为什么还会使用？

通常是出于好意，想在不重新排列实际 HTML 的情况下强制特定顺序。短期内往往更省事，之后却更费事，因为之后每新增一个元素都需要手动重新编号，才能避免再次破坏顺序。

我可以在手机上用同样的方法测试 Tab 键顺序吗？

不太行。Tab 键导航是硬件键盘的交互，所以这项测试是围绕桌面浏览器设计的。移动端的键盘无障碍仍然重要，主要针对在移动浏览器上使用外接键盘或开关控制设备的人，但测试方式不同。

只修复 Tab 键顺序就能让我的键盘导航完全可用吗？

没有任何单一修复能涵盖只用键盘的用户可能遇到的一切。Tab 键顺序是真实而有意义的一部分；页面仍可能存在其他问题，比如缺少焦点指示器或真正的键盘陷阱，需要各自单独检查。

参考来源

• W3C：理解成功准则 2.1.1，键盘
• W3C：理解成功准则 2.4.3，焦点顺序
• W3C：理解成功准则 2.1.2，无键盘陷阱