符合WCAG21AA无障碍标准是否需要使用真实设备开展测试？

核心结论 #

仅使用axe这类自动化无障碍检测工具，完全无法满足WCAG 2.1 AA的合规要求，必须额外补充手动测试，其中就包含屏幕阅读器等辅助设备的真机实测。 #

原因说明 #

1. 自动化工具的规则覆盖范围非常有限 #

行业通用统计显示，自动化无障碍检测工具最多只能覆盖30%~40%的WCAG 2.1 AA规则项，axe官方也明确标注了自身的检测能力边界：

• 可自动检测的都是具备明确可量化判断标准的场景：比如图片缺失alt属性、文本对比度不达标、表单控件无关联label、语义标签错误嵌套这类可通过DOM结构、样式计算直接校验的问题。
• 无法自动检测的场景占比更高：
  • 无法判断非文本内容的替代文本是否准确：比如工具只能校验图片有没有alt属性，但无法判断alt描述是否和图片实际表意匹配，像提交按钮的图写了alt="图片1"，工具会判定为合规，但实际完全不符合无障碍要求。
  • 无法校验交互逻辑的合理性：比如键盘导航顺序是否符合用户操作习惯、自定义ARIA组件的交互逻辑是否符合预期、动态内容更新是否会正确通知辅助技术用户等场景，都没有统一的自动化判断标准，工具无法识别。
  • 无法判断内容语义逻辑是否通顺：比如工具只能校验页面有没有h1标签，但无法判断整个页面的标题层级（h1~h6）是否和内容结构匹配，是否能让辅助技术用户快速梳理页面内容框架。

2. 真机实测是验证真实用户可用的唯一标准 #

WCAG 2.1 AA的核心要求是保障真实的辅助技术用户可以正常使用产品，而非仅通过工具规则校验。主流屏幕阅读器（如NVDA+Chrome、VoiceOver+Safari、JAWS+Edge）对语义标签、ARIA属性的解析逻辑存在原生差异，很多axe检测完全合规的代码，在不同辅助技术组合中的表现可能完全不符合预期：比如自定义弹窗组件的ARIA属性配置全部正确，但实际使用时存在焦点不会自动跳转至弹窗、关闭弹窗后焦点无法回位、状态变化没有语音播报等问题，这类问题只有真机实际操作才能发现。 #

合规测试推荐流程 #

• 第一步：先使用axe等自动化工具全量扫描，优先修复所有可自动识别的问题，降低后续手动测试成本
• 第二步：开展纯键盘导航测试，全程不使用鼠标操作页面，校验所有功能可通过键盘完成、无焦点陷阱、焦点状态清晰可识别
• 第三步：选取至少2~3款主流的屏幕阅读器+浏览器组合，覆盖核心业务路径开展实测
• 第四步：有条件的情况下可邀请真实的视障用户开展可用性测试，是最能发现实际使用问题的方式

内容的提问来源于stack exchange，提问作者DevX