无障碍测试基础
说实话，刚入行那几年，我对无障碍测试的态度就是「有空再说」。直到有一次，一个视力障碍用户在网上公开吐槽我们产品，说他们团队花了半小时都完成不了一个注册流程——我才意识到，这不是小毛病，是硬伤。
从那以后，我不管做哪层测试，都会在脑里过一遍：这个功能，如果用户只看键盘操作，能走通吗？如果看不清颜色，信息会丢失吗？说白了，无障碍测试不是附加题，是合格线。
WCAG 标准——无障碍测试的金科玉律
聊无障碍，绕不开 WCAG（Web Content Accessibility Guidelines）。目前最常用的是 2.1 版，2.2 版也在逐步普及。它的核心归纳起来就四个词：可感知、可操作、可理解、健壮——业内常叫 POUR 原则。
- 可感知：信息必须能以用户能感知的方式呈现。比如图片加替代文本，视频配字幕。
- 可操作：所有交互组件必须能被用户操作。比如键盘能访问所有功能，点击区域够大。
- 可理解：内容和界面要清晰、一致、可预测。比如错误提示要指明具体问题，不要只报个「系统出错」。
- 健壮：内容要能被各种用户代理（包括辅助技术）可靠解析。比如使用语义化的 HTML，不要滥用 div。
WCAG 还划分了三个达标等级：
| 等级 | 说明 | 常见检查项示例 |
|---|---|---|
| A（最低） | 必须满足，否则部分用户无法访问 | 所有非文本内容有替代文本；纯键盘可操作 |
| AA（中） | 大多数项目的合规目标 | 颜色对比度 ≥ 4.5:1；文本可缩放至 200% |
| AAA（最高） | 最严格，但不是所有内容都能做到 | 手语翻译；无背景音乐；对比度 ≥ 7:1 |
我个人习惯是把 AA 作为默认目标。AAA 有些要求太苛刻（比如纯文本无背景音），只能在特定场景里追求。但 A 级是底线，一个都不能落。
课代表记法：把 WCAG 四个原则当成测试 checklist 的四大板块，每个板块下再挂 A/AA/AAA 的测试用例。这样分层管理，不容易遗漏。
无障碍测试的意义——不止是「好人好事」
很多团队觉得无障碍是「给盲人用的」，其实这是误解。你想想看，一个手臂骨折的人只能用键盘操作；一个在嘈杂环境里的用户听不到语音提示——这些都是无障碍覆盖的场景。
从业务角度：忽视无障碍，等于放弃全球 15% 的残障用户群体。这是真金白银。
从法律角度：欧美有 ADA、EAA，国内有《无障碍环境建设法》。被告的案例越来越多，一旦出事，赔偿和声誉损失远大于前期开发成本。
从技术角度：无障碍测试往往能提前暴露代码耦合问题。我在一个项目中测 aria 属性时，发现组件库里有个事件绑定写错了，导致键盘事件冒泡异常——修复后，普通用户的点击响应也快了 30%。
所以别再觉得接无障碍是搞慈善。它跟性能测试、安全测试一样，是产品品质的硬指标。
常见无障碍问题类型——我踩过的坑
下面这几类，是我在项目中遇到频率最高的。每一条背后都有真实血泪史。
1. 颜色对比度不足
浅灰文字配白背景，看着挺「高级」，但弱视用户根本看不清。规范要求：普通文本对比度 ≥ 4.5:1，大文本（≥18px 或 ≥14px 加粗） ≥ 3:1。
工具推荐：用 Chrome DevTools 的「颜色选择器」直接看对比度值，或者装 axe DevTools 扩展，自动标注问题。
2. 键盘陷阱
弹出模态框后，Tab 跳不出去了——这是我最常遇到的问题。我曾经排查一个日历组件，发现开发者把焦点硬绑定在弹层内，但忘记处理 Esc 键和关闭按钮的焦点返回。结果用户只能强制刷新页面。
检查方法很简单：用 Tab 键从头走一遍流程，看是否丢焦点、死循环。记住，所有鼠标操作必须能用键盘等价完成。
3. 表单标签缺失或错误
<input> 没有关联的 <label>，屏幕阅读器只会播报「编辑框」，用户根本不知道要填什么。正确做法是：
<label for="email">邮箱地址</label>
<input type="email" id="email" name="email">别偷懒用 aria-label 代替 label——前者对鼠标用户没帮助，而且多个浏览器支持不一致。
4. 动态内容更新无提示
单页应用里经常有「加载成功」的 toast 提示，或者列表自动刷新。如果只用视觉闪烁（比如颜色变化），屏幕阅读器用户完全不知情。需要用 aria-live 区域告诉辅助技术：这里的内容变了。
<div aria-live="polite" id="announce"></div>
// 更新文字时，屏幕阅读器会自动播报
document.getElementById('announce').innerText = '数据已更新'5. 错误提示不明确
「输入有误」四个字，谁都看不懂。无障碍要求：错误提示要带上具体字段名和修复建议。比如「密码最少 8 位，至少包含一个数字」而不是简单标红。
注意：不要只依赖颜色或图标来提示错误。色盲用户看不出红色，纯图标用户可能不知道含义。一定要配合文本说明。
一张图理清无障碍测试的知识结构
下面这张 SVG 图，帮你把本章核心要点串在一起。从左到右：先熟悉 WCAG 四大原则，然后对照常见的五类问题类型，最后回到测试的意义——形成一个闭环。
这张图里的「常见问题类型」只是冰山一角。实际测试中，你还会遇到焦点管理混乱、ARIA 属性过度使用、视频无字幕等问题。但万变不离其宗——回到 WCAG 的四个原则去排查，总有一条能对上。
我的个人习惯：每测一个功能，我都先在脑子里过一遍 POUR，然后对着那五类高频问题逐一扫。虽然不能保证 100% 覆盖，但能堵住 90% 的痛点。
记住，无障碍测试的核心不是「把所有问题都找出来」，而是 让每一位用户都有平等的机会去完成他们想做的事。这不是口号，是工程师的本分。