键盘导航

键盘导航意味着你不用鼠标，也能访问和操作每一个交互元素，包括链接、按钮、表单和菜单。就像你可以用 Tab 键在表单字段之间移动、用 Enter 键提交一样，设计得当的网站会遵循可预期的操作方式，让键盘用户高效浏览。对于依靠键盘替代鼠标操作的肢体障碍用户来说，这一点必不可少；对于各种能力状况的熟练用户来说，键盘操作也往往更快。 试试这样：在任意网页上按 Tab 键，看看是否有清晰可见的轮廓线，标出当前获得焦点的元素。

键盘导航如何工作

键盘导航的基础是 Tab 顺序，也就是你按下 Tab 键时，各个交互元素依次获得焦点的顺序。这个顺序应该符合内容的逻辑走向，通常是从上到下、从左到右。元素获得焦点后，你就可以激活它，通常使用 Enter 键或空格键。键盘用户可以通过清晰可见的焦点指示器，比如轮廓线或高亮效果，知道自己当前在哪里。

基本导航方式

Tab 和 Shift+Tab 用于在可获得焦点的元素之间向前和向后移动。Enter 键用于激活链接和按钮，空格键用于切换复选框的选中状态，以及选中单选按钮。方向键用于在菜单、滑块和下拉列表等组件内部移动。Escape 键通常用于关闭对话框或退出某种模式。这些标准化的操作方式让交互变得可预期：用户学会后，就能在不同网站上用相同的方式操作。

用跳转链接解决重复导航

跳转链接平时隐藏，获得键盘焦点时才会出现，让用户直接跳到主要内容或导航区域。它解决了一个实际问题：用户每次访问页面，都得按很多次 Tab 键才能穿过冗长的导航菜单。实现跳转链接很简单：在页面顶部放置一个带有 href="#main-content" 的锚点链接，并通过样式让它只在获得焦点时显示。这个简单的做法能大幅提高仅用键盘操作的用户的效率。

要避免的常见问题

缺少焦点指示器会让键盘用户不知道自己当前在哪里。Tab 顺序不正确会让导航路径变得混乱，常见原因包括 CSS 定位造成的视觉顺序与 HTML 源码顺序不同，或不当使用正数 tabindex 值。让非交互元素获得焦点，比如把装饰性图标设为可聚焦，会浪费用户的按键操作。不支持键盘操作的自定义控件会困住用户，而使用标准 HTML 元素本来就能默认获得无障碍支持。

测试键盘无障碍

最有效的测试很简单：拔掉鼠标，试着只用键盘操作你的网站。你能访问每个交互元素吗？焦点顺序符合逻辑吗？你能始终知道自己当前在哪里吗？这个基础测试能发现影响数百万用户的问题，也往往能通过让界面设计更周全、操作更可预期，改善所有人的使用体验。

键盘无障碍是数字包容的基础。研究一直表明，肢体障碍影响着数百万人，而键盘导航是主要的替代输入方式。《Web 内容无障碍指南》（WCAG）将键盘可操作性列为 A 级要求，也就是无障碍的最低标准，体现了它的基础性地位。要做好键盘无障碍，你需要同时理解技术标准和用户需求。

• W3C WCAG 工作组（2023）：成功准则 2.1.1 要求，所有功能都能通过键盘接口操作，且不要求单次按键操作满足特定的时间限制。这确立了无障碍网页内容必须满足的键盘访问基本要求。[1]

• WebAIM（2024）：肢体障碍的情况包括震颤、缺乏精细肌肉控制能力，乃至完全瘫痪，因此，用键盘替代鼠标等操作方式至关重要；键盘导航也有助于通常通过键盘浏览的盲人用户，以及偏爱键盘操作效率的熟练用户。[2]

• WebAIM（2024）：跳转链接可以把每页需要数十次 Tab 按键的导航过程，缩减为一次激活操作。研究表明，这种方式能显著缩短仅用键盘操作的用户完成任务所需的时间。[2]

• MDN Web Docs（2024）：正数 tabindex 值会让焦点顺序偏离页面的逻辑结构，造成困惑；正确的实现方式是让 HTML 源码顺序与合理的导航顺序一致，而不是用 tabindex 重新排序。[3]

• W3C WAI（2023）：焦点顺序必须保留内容的含义，并让界面保持可操作，但不必与视觉布局完全一致；只要用户能够理解和操作界面，就可能存在多种有效的顺序。[1]

键盘导航标准主要针对网页内容，可能无法全面涵盖游戏或专用工具等复杂应用。自定义控件需要谨慎实现 ARIA，才能具备与原生元素一致的键盘行为；如果处理不当，这种复杂性可能引入无障碍问题。移动设备还带来了额外挑战：虽然可以使用外接蓝牙键盘，但屏幕键盘可能无法支持所有导航方式。一些有严重肢体障碍的用户可能需要开关扫描式界面，也就是通过开关在依次扫描的选项中进行选择，这超出了标准键盘导航的范围。此外，键盘操作方式会因操作系统和地区语言设置而异，因此需要仔细关注跨平台的一致性。