可访问性（a11y）实战：让产品对所有人可用

a11y 常被当成「合规负担」，其实是更好的通用设计——键盘可达、语义清晰、对比足够，受益的不只是视障用户，还有键盘党、临时受伤者、弱网与小屏用户。这篇给出按投入产出排序的四层基础、焦点管理与测试方法。

一、先破除五个误解

可访问性（accessibility，常缩写 a11y）最大的障碍不是技术，而是几个流行的误解：

• 「只服务盲人」：它服务所有「能力受情境限制」的人——键盘用户、临时受伤的人、强光下的屏幕、嘈杂环境里的语音输入用户
• 「加上 ARIA 就无障碍」：ARIA 是最后手段，语义化 HTML 优先；错误的 ARIA 比不写更糟
• 「成本很高」：多数问题来自基础 HTML 用法（div 当按钮、没有标签），修复成本远低于事后返工
• 「只有大公司才做」：它同时带来合规与口碑收益，且组件库层面一次修好，全站受益
• 「跑一遍自动扫描就够了」：自动化只能覆盖一部分规则，键盘走查与真人测试不可替代

好的可访问性设计，本质上就是更好的通用设计——它让产品在更多情境下可用。

二、四层基础：按投入产出排序

这四层是"地基"：语义化 HTML 做对了，键盘、焦点、屏幕阅读器支持大多免费得到；反过来，用 div 拼装一切，就得靠大量补丁去还原浏览器本来免费给你的能力。

<!-- ✗ 丢失键盘与语义 -->
<div onclick="submit()">提交</div>

<!-- ✓ 原生按钮：键盘、焦点、语义全部自带 -->
<button type="submit">提交</button>

三、焦点管理：SPA 与弹窗最容易翻车的地方

• 弹窗：打开时焦点移入弹窗、关闭后归还触发它的按钮；模态内 Tab 循环不跑出去（焦点陷阱），Esc 可关闭
• 路由切换：单页应用切页后把焦点移到主标题或主区域——否则屏幕阅读器用户不知道"页面换了"
• 动态提示：异步结果与错误用 aria-live 播报，让读屏用户第一时间知道发生了什么

四、ARIA 的三条纪律

能不写就不写——原生元素已经带着正确的角色与行为，role="button" 远不如一个真正的 button；写就写对——角色、状态必须与实际行为同步（标了 aria-expanded 就要真的切换），错误的 ARIA 会把读屏用户带进更混乱的境地；可访问名称与可见文本一致——语音控制用户会说"点击提交"，名称不一致就点不到。

五、怎么测：三层验证

• 键盘走查（性价比最高）：只用键盘完成一遍核心流程——能不能 Tab 到、焦点看得见吗、能不能提交。十分钟能发现大半问题
• 自动化扫描：axe 或 Lighthouse 接进 CI，主要作用是防回归，别指望它覆盖一切
• 屏幕阅读器与真实用户：抽测几个关键页，配合真实用户反馈——价值最高，也最容易被跳过

自查时对照 WCAG 的四条原则即可：可感知（有替代文本、对比足够）、可操作（键盘可用、时间可控）、可理解（提示清晰、错误可懂）、健壮（兼容辅助技术）。

六、把 a11y 放进流程，而不是当作专项

• 设计阶段：把对比度与焦点样式画进设计稿——先有样式规范，开发才不用返工
• 开发阶段：可达性做进组件库（按钮、弹窗、下拉、表单），一次修好、全站受益
• 评审阶段：把「键盘能走通吗」「对比度够吗」写进 PR 检查清单
• 上线之后：CI 跑 axe 防回归，关键页面定期人工走查

七、五个常见坑

• 用 div 做按钮：键盘不可达、无角色、无状态——最基础也最常见的错误
• 去掉焦点轮廓：视觉是清爽了，键盘用户却在页面里"迷路"——替换成更醒目的自定义焦点样式，而不是删除
• 只靠颜色传达状态：色弱用户看不出红绿差异——补图标或文字
• placeholder 当标签：输入一开始就消失，回填时更糟——可见的 label 才是正解
• aria-label 与可见文本不一致：语音控制点不到，读屏播报也对不上

速查卡

写在最后

可访问性的正确打开方式是：把它当作产品的基础质量，而不是一次性的专项整改。语义化 HTML 打好地基、组件库统一实现、键盘走查进入评审清单——这三件事做完，大多数问题就不会再产生。而它带来的回报，是产品在更多情境下可用、被更多人真正用上。