第四章：常见的无障碍障碍类型
做无障碍测试，首先得知道你在跟谁打交道。说白了，我们需要弄明白：哪些用户可能会被拦在门外？他们遇到了什么坎儿？我刚开始接触无障碍的时候，以为就是给图片加个alt文本，后来踩过坑才意识到——远没那么简单。
通常我们把障碍分成四大类：视觉障碍、听觉障碍、运动障碍、认知障碍。每一类的应对策略都不一样，测试手段也千差万别。先给你一张总览图，帮你脑子里搭个框架：
1. 视觉障碍
视觉障碍并不等于全盲。我遇到的大部分用户其实是低视力、色盲或者老花眼。举个例子，红绿色盲在男性中比例超过8%，你的按钮如果是「红色禁用、绿色可用」，那对他们来说就是一团灰。
测试要点：
- 屏幕阅读器（NVDA、JAWS、VoiceOver）是否能正确朗读所有内容。
- 所有功能是否都可以通过键盘完成——不用鼠标。
- 颜色对比度至少达到AA级（4.5:1普通文本，3:1大文本）。
- 图片必须有alt文本，装饰性图片用空alt。
我曾经测过一个数据大屏，工程师觉得「反正背景是深蓝色，文字用白色就行」，结果我拿色盲模拟器一看——根本分不清哪行是哪行。后来的方案是：
加了一层半透明遮罩 + 文字描边。
用小工具快速测对比度：color.review 或者浏览器自带的 DevTools 无障碍面板。
2. 听觉障碍
听觉障碍用户并不是「听不到声音就没事」。他们依赖视觉反馈。比如一个弹窗提示，如果只用「叮」一声来提醒——那他们就完全收不到信息。
测试重点：
- 所有音频内容必须有同步字幕或文字转录。
- 重要的提示（报警、成功、错误）必须同时提供视觉反馈。
- 视频播放器必须支持字幕开关、音量独立控制。
注意：不要只依赖颜色变化来提示状态。想想看，红绿色盲同时又是听觉障碍——双重障碍用户怎么办？所以文字提示 + 图标 + 颜色，三重保险才稳妥。
我个人习惯在测试音频通告时，把电脑静音，只看屏幕。如果还能准确完成所有操作——那就通过了。
3. 运动障碍
运动障碍覆盖范围很广：帕金森导致的颤抖、脊髓损伤、肌肉萎缩，甚至临时骨折。他们的共同特点：精细操作困难。比如点一个10×10像素的小叉号关闭按钮，对他们来说可能就是噩梦。
测试检查清单：
| 检查项 | 说明 |
|---|---|
| 点击区域大小 | 至少 44×44 CSS 像素（WCAG 2.5.5） |
| 时间限制 | 任何限时操作必须可关闭、可延长、可调整 |
| 语音控制 | 用自带的语音识别能完成所有核心流程吗？ |
| 按键粘连 | 支持长按、双击等替代方案 |
| 拖拽操作 | 必须有非拖拽的替代方式（比如先点击选择，再点击放置） |
我最近测一个表单，提交按钮居然在页面底部，用户需要滚动到底才能点。运动障碍用户为了点这个按钮，手抖着滚了老半天。后来我把「提交」固定到了底部浮动栏——好多了。
4. 认知障碍
这一块容易被忽视。认知障碍包括：阅读困难、注意力缺陷、记忆力差、自闭症等。说白了，用户可能看不懂复杂的操作指引，或者被花里胡哨的动效搞得心烦意乱。
测试时我特别关注：
- 语言简单：用词是否直白？比如「身份验证」改成「登录」。
- 一致性：同一个功能在不同页面叫法是否一致？导航结构是否每次都在同一位置？
- 错误提示温柔：用户输错了，能不能告诉他「哪里错了 + 怎么改」？而不是一串红色代码。
- 避免闪烁/动效：快速闪烁可能引发癫痫，无意义的动画会分散注意力。
一个真实案例：我测过一款医疗App，注册流程有8步，没有进度提示。认知障碍用户走到第3步就忘了前面填了什么，直接放弃。后来我建议加了一个「步骤进度条 + 可返回修改」——完成率提升了40%。
交叉障碍：别忘了「多重障碍」
现实中，一个用户可能同时存在视觉+运动障碍，或者听觉+认知障碍。如果你的测试只针对单一分类，那还是有盲区。
我常用的一个笨办法：每次测试至少模拟两种障碍组合。比如关掉屏幕（模拟盲人）+ 只用键盘（模拟运动障碍）。再比如静音（模拟聋人）+ 放大字体（模拟低视力）。你会发现很多漏洞。
千万别觉得「我们用户肯定没那么多障碍」——实际上因为老龄化、临时损伤等原因，至少15%的人口存在某种功能性障碍。不是小数目。
小结一下
这四种类型不是彼此独立的。测试的时候，要灵活组合。我也特别建议在项目的每一个迭代里，都拿这四类用户角色去跑一遍你的核心流程。你想想看，如果连盲人都能走通注册，那普通用户只会更快。
我的个人原则：把无障碍测试当作「质量门禁」的一部分。如果某个版本连最基本的大按钮、高对比度、字幕都没有——那就别上线。