网站无障碍基础：键盘、焦点和文字替代

键盘能走完整个页面、焦点位置始终看得见、图片有可读的替代文字，这三件事是网站无障碍的底线。很多自定义组件看起来功能完整，实际却把键盘用户挡在门外：点击能用，Tab 却根本停不上去；弹窗打开了，焦点还留在背景里；装饰性图片被读屏念出一长串文件名。这些问题不涉及复杂算法，但需要开发者按真实使用顺序去检查，而不是只看视觉稿是否还原。

先确认交互元素的语义

判断一个控件该用按钮还是链接，标准很简单：触发后停留在当前页面的是按钮，跳转到新地址的是链接。用 <div> 加点击事件模拟按钮，键盘用户无法聚焦，读屏软件也不知道它是什么角色。原生 <button> 自带 Enter 和空格键触发行为，<a href> 自带跳转，这些能力不需要额外写 JavaScript。

自定义组件的情况更复杂。假设页面里有一个下拉菜单，它需要满足：Tab 能进入菜单按钮，Enter 或空格能展开选项，方向键能在选项间移动，Esc 能关闭菜单并把焦点还给按钮。这些键盘交互不是浏览器自动提供的，必须由开发者用 JavaScript 实现。检查方法很直接：关掉鼠标，只用键盘从页面顶部开始走一遍，看能否完成所有操作。

另一个高频问题是焦点顺序。默认情况下，DOM 顺序就是 Tab 的移动顺序，所以用 CSS 的 order 属性或 position: absolute 重排视觉位置时，要确认键盘顺序是否仍然合理。一个典型错误是：视觉上左侧的侧边栏在 DOM 里位于主内容之后，键盘用户每次都要跳过一长串导航才能到达正文。

焦点样式不能只靠浏览器默认

浏览器默认的焦点环（focus ring）在部分设计者看来不够美观，于是常见做法是加一句 outline: none。这会让键盘用户完全失去位置感。正确思路不是去掉焦点样式，而是把它设计成视觉上清楚、对比度足够的自定义样式。

```css
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
```

:focus-visible 的作用是只在键盘导航时显示焦点环，鼠标点击时不显示，这样既满足键盘用户需求，也不干扰鼠标操作的视觉体验。注意这里不写具体颜色值作为唯一方案，实际项目中应选择与页面背景对比明显的颜色，并检查在深色背景、图片上方等场景下是否仍然可见。

容易出错的地方是：焦点样式被父元素的 overflow: hidden 裁切掉，或者被相邻元素的背景色遮住。检查方法是在键盘操作时放大页面到 200%，确认焦点环没有被裁切，且与周围内容有足够区分。另一个常见问题是弹窗打开后焦点没有移入弹窗，关闭后焦点也没有回到触发按钮，这会让键盘用户迷失在页面的某个角落。

图片的替代文字要区分用途

图片的 alt 属性怎么写，取决于图片在页面中承担的角色。内容图片——比如教程里的架构图、新闻配图、产品照片——需要用 alt 描述图片传达的信息。装饰性图片——比如纯视觉的分隔线、背景纹理、图标旁的重复文字——应该写空 alt=""，让读屏软件直接跳过，而不是念出“image001.jpg”这类无意义内容。

判断标准是：如果去掉这张图片，页面信息是否完整？完整，就是装饰图，用空 alt；不完整，就是内容图，需要写清楚它传达什么。对于包含文字的图片，alt 应该包含图片中的全部文字，因为读屏用户无法看到图片内的文字内容。如果图片旁边已经有相同的文字说明，那么这张图片可以视为装饰性，使用空 alt 避免重复朗读。

复杂的图表或信息图，单靠 alt 属性放不下完整信息。这时可以在图片下方提供文字版数据表格或详细说明，并把图片的 alt 写成“2024年各季度销售趋势图，详细数据见下方表格”。这样读屏用户可以选择跳过图片，直接阅读表格，而不是听一段冗长且难以理解的描述。

键盘操作中的边界情况

键盘无障碍不只是“能 Tab 到每个元素”。实际使用中会遇到几个容易忽略的边界。

弹窗和抽屉组件是重灾区。打开弹窗时，焦点应该移入弹窗内部，通常放在标题或第一个可交互元素上。弹窗打开期间，Tab 不应该走到背景页面的元素上，这需要开发者手动管理焦点范围，或者使用 inert 属性让背景内容暂时不可交互。关闭弹窗时，焦点必须回到打开弹窗的那个按钮。缺少任何一环，键盘用户都会觉得页面“卡住了”。

长页面中的“跳转到主内容”链接是另一个基础但常被遗漏的细节。页面顶部放一个只在键盘聚焦时才显示的链接，指向 #main-content，可以避免键盘用户每次都要 Tab 过几十个导航链接才能到达正文。这个链接在鼠标操作时隐藏，键盘聚焦时显示，实现成本很低，收益却很明显。

还有一个常见问题是自定义键盘快捷键。如果页面实现了快捷键，比如按 ? 显示帮助、按 / 聚焦搜索框，要确保这些快捷键不会与读屏软件或浏览器自身的快捷键冲突，并且最好提供可见的快捷键说明。对于普通用户来说，快捷键是效率工具；对于依赖键盘的用户来说，快捷键冲突可能直接导致某个功能无法使用。

文字替代的边界情况

文字替代不限于图片的 alt，还包括图标按钮的可访问名称。假设页面里有一个只有放大镜图标的搜索按钮，视觉上用户能猜到它的功能，但读屏软件只会念出“按钮”或者图标的某个属性值。这时需要给按钮提供可访问名称，比如用 aria-label="搜索"，或者用 CSS 隐藏但读屏可读的文字说明。

判断方法：把页面上所有可见文字遮住，只看图标和图形，能否理解每个控件的功能？如果不能，说明这些控件缺少文字替代。反过来，如果页面上的文字已经完整说明了功能，就不需要重复添加 aria-label，否则读屏用户会听到两遍相同内容。

对于验证码这类本身就有无障碍矛盾的内容，图片验证码需要同时提供音频验证码或其他替代方案。纯文字验证码对读屏用户相对友好，但要注意区分容易混淆的字符，比如数字 0 和字母 O、数字 1 和字母 l。如果无法提供替代方案，至少要让用户能刷新获取新的验证码，而不是卡在一个看不清的图片上。

验证结果的具体方法

完成修改后，验证不能只看代码是否正确。最直接的检查方式是完全脱离鼠标，只用键盘操作一遍完整的用户流程：从页面顶部开始，Tab 进入导航，跳转到主内容，完成一次表单提交或弹窗操作，再返回起始位置。过程中观察焦点环是否始终可见、操作顺序是否符合预期、是否有焦点“掉进”了页面某个无法出来的区域。

读屏软件测试需要选择一款实际使用的工具，比如 NVDA、VoiceOver 或 TalkBack，在真实浏览器中听一遍页面朗读顺序。只听代码不看页面，很难发现朗读顺序混乱、控件角色错误、替代文字重复等问题。如果项目条件允许，找一位实际使用读屏软件的用户做一次简短测试，比开发者自己猜测有效得多。

自动化工具可以作为辅助检查，比如 axe 或 Lighthouse 的无障碍审计，能发现缺失的 alt、错误的 ARIA 属性、颜色对比度不足等问题。但自动化工具无法判断焦点顺序是否合理、弹窗焦点管理是否正确、替代文字是否准确描述了图片内容，这些仍然需要人工操作验证。

修改完成后，在代码注释或项目文档中记录：改动了哪些组件、检查了哪些页面、使用了哪些验证工具、发现了什么问题、如何修复的。这份记录对后续维护和团队协作都有实际价值，也能避免几个月后重复排查相同的问题。