为什么自动化无障碍测试会漏掉一半问题

关于自动化无障碍测试的一个令人不安的事实

自动化无障碍测试是 Web 团队可以养成的最佳习惯之一。它能发现缺失的表单标签、低对比度文本、无效 ARIA、重复 ID、空按钮，以及其他本不应进入生产环境的缺陷。

但它也经常被误解。

一份通过的自动化无障碍报告，并不意味着页面就是无障碍的。它只意味着工具没有发现它知道如何检测的那一部分问题。这个子集很有价值，但也有限。许多无障碍失败取决于含义、顺序、意图、上下文和人的交互。软件可以检查标记。它无法可靠地理解，对于使用屏幕阅读器、键盘、放大、语音控制、字幕或认知支持的人来说，体验是否真的可用。

这就是为什么“自动化测试会漏掉大约一半问题”的说法并不愤世嫉俗。它甚至算是保守的。有些问题类别高度适合自动化。另一些则几乎无法自动化。

实际的答案不是放弃自动化工具。而是把它们放在正确的位置：尽早、频繁，并作为更广泛测试工作流的一部分。

自动化测试擅长什么

自动化工具非常擅长发现确定性的失败。如果一条规则可以表达为机器可读的条件，扫描器通常就能快速且一致地检查它。

常见示例包括：

• 缺少 alt 属性的图片
• 没有关联标签的表单输入
• 没有无障碍名称的按钮
• 未达到对比度阈值的文本
• 无效的 ARIA 属性或角色
• 以可疑方式跳级的标题层级
• 缺失或重复的地标
• 无障碍名称为空的链接
• 缺少基本结构的表格

这些检查值得自动化，因为人类不擅长重复性检查。如果工具能在毫秒内发现缺失标签，就不应该让任何人手动扫描每个页面。

自动化检查也让无障碍更容易进入工程工作流讨论。CI 中失败的测试是具体的。拉取请求中的警告是及时的。跨模板的趋势线能给团队一个可改进的对象。

问题始于团队把这些检查当成无障碍的证明，而不是基本卫生状况的证明。

自动化在哪些地方会失效

无障碍不仅是代码的属性。它是使用过程的属性。

工具可以告诉你一张图片是否有 alt 文本。它通常无法告诉你这段 alt 文本是否有用。同一张产品图片，在产品页上可能需要详细描述，在装饰性的主视觉中可能不需要描述，而在帮助文章中又可能需要完全不同的描述。正确答案取决于上下文。这就是为什么团队需要像一种务实的图片 alt 文本方法这样的编辑指南，而不只是一个 linter 规则。

同样的问题随处可见。

扫描器可以确认每个按钮都有无障碍名称。它并不总能判断这个名称是否合理。一个页面上有五个名为“提交”的按钮，可能通过基础规则，但对屏幕阅读器用户来说仍然很痛苦。一个模态框可能拥有正确的 ARIA 属性，却错误地困住焦点。一个自定义下拉菜单在静态标记中看起来合规，但用户一旦尝试用键盘操作就会失败。

自动化很难处理这样的问题：

• 焦点顺序是否符合视觉顺序和逻辑顺序？
• 每个任务是否都能只用键盘完成？
• 错误消息是否具体、及时，并与字段关联？
• 当文本被调整大小或页面缩放时，页面是否仍然可用？
• 对辅助技术来说，阅读顺序是否合理？
• 说明是否在不依赖颜色或位置的情况下也能被理解？
• 字幕、转录文本和标签是否真正传达了内容？
• 组件在不同状态下的行为是否可预测？

这些不是边缘情况。它们是无障碍的核心。

高分带来的虚假安全感

无障碍评分很有诱惑力，因为它把一个复杂的问题压缩成一个数字。仪表盘显示 98。报告里全是绿色勾选。发布看起来更安全了。

但这个分数只是在衡量工具能够衡量的内容。

这类似于性能测试。Lighthouse 报告可以揭示重要问题，但它不等同于观察一个真实用户在中端手机上艰难完成缓慢的结账流程。如果你的团队已经在使用性能审计，同样的思维也适用：仔细阅读报告，然后优先处理影响真实用户的发现。我们在如何阅读 Lighthouse 报告而不惊慌中写过这种区别。

无障碍报告也需要同样的克制。一份干净的自动化扫描结果是起点。它不是证书。

当团队只针对静态页面运行扫描时，风险尤其高。现代界面是有状态的：菜单会打开，抽屉会滑出，toast 会出现，校验消息会更新，选项卡会切换面板，筛选器会重写内容，身份认证会改变一切。许多严重的无障碍缺陷就存在于这些交互中。

如果你的扫描器只看到初始 DOM，它漏掉的就是产品本身。

最常被漏掉的类别

1. 键盘和焦点行为

键盘访问是说明自动化为何不充分的最清晰例子之一。

工具可以检测一个元素是否可聚焦。它可能发现正值 tabindex 或明显的焦点陷阱。但它无法可靠判断 Tab 顺序是否感觉连贯，执行操作后焦点是否移动到正确位置，或者被关闭的组件是否把焦点返回到触发器。

你需要有人在真实工作流中按 Tab、Shift+Tab、Enter、Space、Escape 和方向键一路操作。

这对自定义控件尤其重要。原生 HTML 元素天然携带了多年沉淀的无障碍行为。用 div 重建按钮、选择框、复选框、菜单和对话框，意味着你的团队现在拥有并负责这些行为。如果你正在审查交互组件，可以从一份简短的无障碍 Web 按钮检查清单开始，并把同样的纪律扩展到每一个自定义控件。

2. 有意义的名称和描述

自动化工具可以检测缺失。它们在检测质量方面要差得多。

一个名为“阅读更多”的链接在技术上可能有无障碍名称。一个标为 OK 的按钮可能有效。一个表单提示可能存在。但它们在上下文中有意义吗？往往没有。

无障碍名称应该告诉用户会发生什么，或该元素代表什么。这需要判断。它也需要结合界面进行测试，而不只是看代码。

3. 错误处理

表单中充满了扫描器只能部分发现的无障碍失败。

工具可能会标记未加标签的字段。它可能发现不了校验消息出现得太晚、消失得太快、没有被屏幕阅读器播报，或者在应该说“密码必须至少包含 12 个字符”时只说“输入无效”。

好的错误处理是交互设计。它需要手动测试，理想情况下还需要用户测试。

4. 视觉适应

WCAG 包含关于调整文本大小、重排、对比度、间距，以及不依赖单一感官线索的要求。其中一些可以自动检查，但真正的问题是，在条件改变后界面是否仍然可用。

试试 200% 缩放。试试浏览器文本大小调整。试试高对比度或 forced colors mode。试试窄视口宽度。试试减少动态效果。许多在默认设置下看起来精致的网站，一旦用户主张自己的偏好，就会很快崩坏。

5. 内容清晰度

没有任何自动化无障碍工具可以完整评估内容是否易于理解。

它可以标记缺失的标题或含糊的链接文本。它无法知道页面是否清楚解释了一个流程，标签是否符合用户预期，或者密集文案是否造成了本可避免的认知负担。

无障碍不只是与辅助技术兼容。它也关乎为处于压力中、使用不熟悉语言、面临注意力限制或正在处理复杂任务的人减少摩擦。

更好的测试工作流

一个平衡的无障碍工作流是分层的。

持续运行自动化检查

在开发、拉取请求、组件预览和 CI 中使用自动化测试。它们应该平常、快速且不可协商。新的缺失标签和无效 ARIA 不应该等到季度审计才被发现。

把这些失败当作 linting 失败来处理。目标不是英雄主义，而是防止回归。

加入手动键盘测试

对每一个有意义的用户流程，都在不使用鼠标的情况下测试。这包括导航、搜索、创建账户、结账、筛选、模态框、菜单和表单提交。

至少要验证：

• 每个交互元素都可到达
• 焦点始终可见
• 焦点顺序合乎逻辑
• 预期的按键有效
• Escape 可以关闭可关闭的覆盖层
• 组件打开和关闭后焦点得到管理
• 不存在键盘陷阱

这个单一习惯能发现自动化扫描漏掉的一大类问题。

至少使用一种屏幕阅读器测试

你不需要成为屏幕阅读器专家才能学到有用的东西。你确实需要保持谦逊。屏幕阅读器测试有学习曲线，初学者可能误判问题。

即便如此，使用 VoiceOver、NVDA 或 JAWS 进行基础测试，仍然可以发现损坏的名称、混乱的阅读顺序、未播报的更新，以及扫描器可能发现不了的地标问题。

把这与语义化 HTML 结合起来。你使用的原生元素越多，无障碍就越不脆弱。

审查内容和状态

检查空状态、加载状态、错误状态、禁用状态、成功消息和权限失败。无障碍 bug 经常隐藏在顺利路径之外。

也要审查实际文字。标签、标题、说明和错误消息都是界面的一部分。

在风险较高时纳入残障用户

对于关键流程，手动专家审查还不够。与残障参与者进行用户测试，能发现团队没有预料到的问题。这对公共服务、医疗健康、金融、教育，以及任何排除会造成严重后果的流程尤其重要。

自动化测试可以规模化。人的测试能够理解。

如何负责任地解读自动化结果

不要问：我们通过了吗？

问更好的问题：

• 这个工具能检测哪些问题类别？
• 它扫描了哪些模板和状态？
• 它是在交互之后运行，还是只在初始加载时运行？
• 违规项是按根因分组，还是被重复计数？
• 哪些失败会阻止用户完成任务？
• 哪些内容仍然需要手动审查？

这种框架会改变对话。自动化工具成为证据，而不是权威。

它也帮助团队避免无效忙碌。修复单个组件可能消除数百个重复违规。相反，一个只报告了一个问题的页面，仍然可能包含严重的键盘陷阱。数量不等于影响。

实用标准：自动化显而易见的问题，手动测试体验

最好的无障碍团队并不反对工具。他们反对幻想。

他们自动化机器能够可靠检测的内容。他们手动测试依赖行为和含义的内容。他们把 WCAG 等标准作为共同基线，而不是作为使用产品的替代品。

如果你当前的流程只是在发布前做一次自动化扫描，请按这个顺序改进：

1. 在开发早期加入自动化检查。
2. 手动对核心流程做键盘测试。
3. 审查名称、标签、错误和说明。
4. 使用屏幕阅读器测试常见组件。
5. 对高风险旅程引入专家测试和用户测试。

这不是一个完美流程。它是一个现实流程。而且它会发现远多于绿色无障碍评分所能发现的问题。