自动工具跑出高分，只能说明部分可机器判断的规则没有报错。真正的无障碍测试还要验证：不用鼠标能否完成任务，放大后信息是否仍可读，错误是否被清楚说明，屏幕阅读器是否能理解页面结构。
自动工具跑出高分，只能说明部分可机器判断的规则没有报错。真正的无障碍测试还要验证：不用鼠标能否完成任务，放大后信息是否仍可读，错误是否被清楚说明，屏幕阅读器是否能理解页面结构。
01 不要把一次扫描当成完整测试
无障碍问题有两类。第一类可以由工具发现，例如缺少标签、对比度不足或结构属性冲突；第二类必须由人判断，例如按钮名称虽然存在却毫无意义、焦点顺序与视觉顺序不一致、错误提示读出来仍然无法理解。
因此，更可靠的测试顺序是：自动扫描先清理基础问题，键盘和缩放验证操作，屏幕阅读器检查语义，最后让真实辅助技术用户验证关键流程。 每一层解决的问题不同，不能互相替代。
02 测试前先选关键流程
不要从首页开始把每个页面平均检查一遍。先列出产品中最重要、风险最高的任务：登录、注册、搜索、支付、提交表单、上传文件、审批、查看账单、联系客服等。
对每个流程准备三种状态：正常、出错和无数据。许多产品只测试“正确填写并成功提交”，却忽略了用户在表单报错、会话过期、权限不足时能否恢复。
03 第一层：自动扫描，用来找基础缺陷
可以在页面和组件层面运行自动化工具，并把结果接入持续集成。但测试人员需要逐条确认，避免机械地追求“零错误”。
自动扫描重点关注：
- 页面语言、标题和主要区域是否定义；
- 图片是否有符合用途的替代文本，装饰图是否被正确忽略；
- 表单控件是否有可识别名称；
- 标题层级、列表和表格结构是否合理；
- 文字与背景、控件与背景的对比是否满足目标等级；
- ARIA属性是否无效、冲突或引用不存在的元素；
- 重复ID、空链接、空按钮等基础实现问题。
工具报告只是线索。比如图片有 `alt` 不代表描述有用；按钮写着“点击这里”也可能通过部分规则，却仍然缺乏上下文。
04 第二层：只用键盘走完任务
拔掉鼠标或把手离开触控板，从浏览器地址栏开始测试。至少检查以下问题：
| 检查点 | 合格表现 | 常见问题 |
|---|---|---|
| 焦点可见 | 当前控件始终有清晰焦点样式 | 焦点与背景几乎融为一体 |
| 顺序合理 | Tab顺序与阅读、操作顺序一致 | 焦点跳到屏幕外或反复绕行 |
| 所有功能可达 | 按钮、菜单、弹窗、表格操作都能触达 | 只能悬停出现的操作无法访问 |
| 无键盘陷阱 | 用户可以进入，也能退出组件 | 焦点困在弹窗、编辑器或轮播中 |
| 弹窗管理 | 打开后焦点进入，关闭后回到触发点 | 焦点丢失到页面顶部 |
| 快捷操作可理解 | Enter、Space、方向键符合控件习惯 | 自定义组件没有说明且行为混乱 |
不要只按几次Tab。要真正完成任务，包括展开菜单、修改字段、触发错误、取消操作和关闭弹窗。
05 第三层：放大、重排与非颜色表达
将页面放大到200%，检查文字、控件和内容是否仍能使用；在窄视口下观察内容能否重排，是否需要同时横向和纵向滚动。对于数据表格等确实需要横向浏览的组件，应确保行列关系和关键操作仍然清楚。
还要暂时忽略颜色。状态、错误、必填和选中不能只靠红绿、深浅或色块区分。建议同时提供文字、图标、形状或结构位置，并检查高对比模式下是否仍能识别。
06 第四层：表单与错误恢复
表单是无障碍问题最集中的区域。测试时故意漏填、填错格式、提交重复数据，并观察：
- 字段标签是否持续可见，而不是只靠占位符；
- 必填要求是否在输入前说明；
- 错误是否与具体字段关联；
- 提交后焦点或摘要是否把用户带到错误位置；
- 错误信息是否告诉用户如何修复，而不是只说“输入有误”；
- 自动保存、超时和验证码是否有可用替代方案；
- 已正确填写的内容是否在报错后保留。
07 第五层：用屏幕阅读器验证语义
不需要一开始就测试整个站点。先选择一到两个与目标用户匹配的常见组合，围绕关键任务进行。
一段可复用的测试脚本
1. 不逐字朗读页面，先通过标题或区域导航了解结构；
2. 找到主导航和当前页面标题；
3. 定位关键表单或数据区域；
4. 完成一次正常提交；
5. 制造一个错误并修复；
6. 打开弹窗、菜单或展开行，确认状态变化被读出；
7. 返回原位置，继续完成任务。
重点记录的不只是“能不能读”，还包括读出的名称、角色、状态和值是否足以让用户判断下一步。图标按钮如果只读成“按钮”，技术上可聚焦，实际仍不可用。
08 第六层：真实用户测试关键流程
团队内部能发现大量问题，但不能替代长期使用屏幕阅读器、语音控制、放大软件或其他辅助技术的用户。高风险产品、公共服务和核心交易流程，应尽量邀请相关用户参与，并让他们使用自己的设备和习惯设置。
真实用户测试尤其适合验证：复杂表格、图表、拖拽、自定义编辑器、身份验证、长表单和跨页面流程。
09 问题单怎么写，开发才容易修
一条无障碍缺陷至少包含：
| 字段 | 内容 |
|---|---|
| 场景 | 用户正在完成什么任务 |
| 环境 | 浏览器、系统、辅助技术和版本 |
| 操作步骤 | 从哪里开始，如何稳定复现 |
| 实际结果 | 用户看见、听见或无法操作什么 |
| 预期结果 | 应提供的名称、顺序、反馈或替代方式 |
| 用户影响 | 哪类用户被阻断，是否有绕行办法 |
| 证据 | 截图、录屏、语音输出或代码位置 |
| 验收方式 | 修复后应怎样复测 |
不要只贴一条规则编号。开发人员需要知道问题发生在什么任务中，以及修复是否可能影响其他组件。
10 修复顺序：先看阻断，再看覆盖范围
界达设计建议按用户影响划分优先级：
- 阻断级：关键任务无法完成，且没有替代路径；
- 高优先级：核心信息无法理解、焦点丢失或错误无法恢复；
- 中优先级：操作可以完成，但效率和理解成本明显增加；
- 改进级：局部一致性、冗余朗读或非关键体验问题。
同时看组件覆盖范围。一个公共按钮组件的名称问题，单页影响不大，却可能出现在全站数百处，应优先从设计系统修复。
11 上线前的最小验收清单
- 关键任务通过自动扫描，没有未解释的严重问题；
- 全流程可以只用键盘完成，焦点始终可见且不丢失；
- 200%缩放和窄视口下内容仍可阅读和操作；
- 表单标签、必填、错误和成功反馈可被感知；
- 状态不只依赖颜色；
- 页面标题、标题层级、区域和链接名称有意义；
- 屏幕阅读器能够理解关键组件及动态变化；
- 修复项完成回归测试，公共组件同步更新。
常见问题
无障碍测试必须等开发完成吗？
不需要。信息结构、颜色、焦点顺序、文案和组件行为可以在设计与原型阶段检查；语义标记、键盘实现和辅助技术兼容则需要在可运行版本中验证。越早发现，修改成本越低。
自动工具选一个就够了吗？
不同工具的规则和实现略有差异，可以组合使用，但增加工具数量不能替代人工检查。更重要的是将结果去重、确认影响，并建立稳定的回归测试。
是否所有项目都必须做到完全相同的标准？
团队应先确定适用法规、行业要求和目标等级，但“最低合规”不等于关键流程可用。即使某个组件形式上满足规则，也需要结合真实任务和用户群判断体验。
12 让研究和设计真正进入产品决策
链接复制成功
