axe、Lighthouse 以及 Playwright 的 @axe-core/playwright 集成这类自动化无障碍工具，大概只能发现真实场景中 30%--40% 的 WCAG 违规。
这个缺口很危险 —— 现在开发者本来就被各种工具搞得疲惫不堪，格式检查、安全扫描、CI 校验轮番抢注意力。
如果 AI 助手给了个修复方案，把无障碍检测跑绿了，大家很容易就直接接受往下走了 —— 修复看起来合理，构建过了，待办清单也少了一项。
但检测工具变绿，不等于问题真的解决了。
AI 给出的修复方案是基于模式生成的，结果可能只是满足了扫描工具的规则，并没有真正解决无障碍的核心诉求。
人工无障碍测试和场景判断依然必不可少：既要验证检出的问题不是误报、修复方案适配实际场景，还要补上自动化工具永远发现不了的那 60%--70% 的无障碍缺陷。
自动化无障碍测试覆盖率：研究数据怎么说
这不是在否定 axe（Deque 出品）、WAVE（WebAIM 出品），或是基于这些引擎的 Lighthouse、Playwright 集成这类工具。
厂商自己和独立研究都一致认为：任何自动化检测引擎，本身就存在结构性的覆盖上限。不同来源数据略有差异，但结论完全一致：
Deque 得出 57.38% 这个数字，用的是更贴近真实业务的测算方式，不是理论值。他们抽取了大量真实站点，统计 axe-core 能发现其中多少已经被确认的无障碍缺陷。
好消息是，实际场景里自动化工具发现的问题占比，比理论估算要高。但即便按这个乐观数据，也还有 43% 的缺口 —— 说明自动化和人工测试结合才是完整方案。
引导式人工无障碍审核 —— 也叫半自动化测试，Deque 平台里叫智能引导测试（IGT）—— 介于全人工和全自动之间，能缩小覆盖缺口。有估算显示这种方式覆盖率能到 80%。
这类引导式审核一般是增值服务，用 AI 和机器学习筛选出自动化能处理的部分，再给出结构化清单，引导测试人员完成剩下需要人工判断的检查项。
自动化无障碍工具能可靠检测什么
讲局限性之前，先肯定自动化工具的长处，这样才知道怎么用它补充无障碍测试。
自动化工具能稳定检出规则明确的结构性问题：
• 图片缺少 alt 属性
• 表单缺少标签
• 静态文本颜色对比度不足
• <html> 标签缺少 lang 属性
• 页面缺少文档标题
• ARIA 角色和属性值无效
这些都是结构性检查 —— 只需要读取 DOM 就能判断，不用理解意图和场景。也刚好是重构代码的时候很容易不小心改坏的地方。
回归防护是自动化检测在 CI 流水线里的核心价值。
无障碍缺陷不会像功能 bug 那样主动报错。
改 UI 删掉了 aria-label、打乱了焦点顺序、去掉了地标区域，没有专门检查的话，既不会抛错，视觉测试也发现不了。
Playwright 无障碍扫描能在发布前拦住这些悄悄引入的回归问题 —— 定期人工审核周期之间，这类问题必然会漏掉。
规模化批量覆盖是另一个优势。
每次 CI 运行，Playwright 无障碍扫描都能覆盖测试套件里的每个页面。
完整的人工审核要花好几个小时，实际也不会频繁做。
自动化检测替代不了人工审核，但它的覆盖速度和规模，是任何人工无障碍审核都比不了的。
核心不是把自动化和人工测试对立起来。两者各有对方做不到的价值。
自动化检测是常驻的基础防线；人工审核是更深层的定期排查，补上自动化结构性检测不了的部分。
自动化无障碍检测覆盖不到的问题
1. 链接文本语义模糊
"了解更多""点击这里""查看全部""了解更多" 这类链接，自动化检测全都会通过，不会报错。结构上完全没问题 —— 都是合法的锚点元素，也有文本内容。
问题出在语境上。
屏幕阅读器用户经常按 Tab 键逐个浏览链接，脱离了上下文段落，根本不知道每个链接跳去哪。
连续听到三个 "了解更多"，完全不知道分别指向什么。
自动化工具判断不了链接文本有没有实际意义，只能判断有没有文本。
满页 "了解更多" 的页面，和链接文本描述完整的页面，在 axe 里得分一样高。
💡 修复方案： 写脱离上下文也能看懂的描述性链接文本，比如 "了解更多 Playwright 无障碍测试"，而不是 "了解更多"。 如果设计限制做不到，就用 aria-label 补充完整语境：aria-label="了解更多 Playwright 无障碍测试"。 |
🔍 静态检测修复方案： React 项目可以用 eslint-plugin-jsx-a11y，自带 anchor-ambiguous-text 规则。 其他技术栈比如 Vue、纯 HTML 也有对应的 ESLint 无障碍插件，但可能需要自定义规则来做这个检查 —— 本文后面的 Playwright 测试方案是跨框架的替代方案。 |
后面我会给一个 Playwright 测试写法，在 UI 测试里就能检出这个问题 —— 尤其是链接文本动态生成、静态分析覆盖不到的时候特别好用。
2. 缺少跳转导航链接
<main>、<nav> 这类地标元素，能满足 axe 的跳转区块检查（WCAG 2.4.1）。技术上规则是满足了 —— 确实有跳过重复内容的机制。
但只用键盘、不用屏幕阅读器的用户，还是得按 Tab 把头部所有元素都过一遍才能到主内容。
地标能帮屏幕阅读器用户在区域间跳转，但帮不了键盘用户每次加载页面都跳过一长串 12 项的导航菜单。
跳转链接 —— 页面第一个可聚焦元素，默认隐藏，按一下直接跳到 #main-content —— 才能同时覆盖两类用户。只靠地标做不到。
💡 修复方案： 就算地标结构没问题，每个页面的第一个可聚焦元素也得加跳转链接。 |
下面这张截图展示了它在本站的实际效果。
只用键盘的用户访问页面时，第一个可聚焦元素就是「跳转到主内容」链接，激活后直接跳到正文区域，不用按 9 次 Tab 键遍历所有头部元素（图中红色划掉的部分）和社交链接，才能到达页面主内容（图中绿色高亮部分）。
3. aria-labelledby 和 aria-label —— 都能通过检测，但效果天差地别
aria-labelledby 和 aria-label 都能完美通过自动化检测。
工具只会校验有没有、格式对不对，不会判断哪种方式更适配你的场景。
aria-label 的文本是不可见的 —— 只存在于无障碍树里。这会带来两个问题：
• 对同时用辅助技术的视力正常用户，屏幕阅读器播报的内容和他们看到的可能不一致
• 翻译工具经常漏翻 aria-label 属性，导致非英语用户拿到的无障碍名称没翻译
页面上已经有可见的标题或标签时，用 aria-labelledby 指向对应元素几乎永远是更优选择 —— 它复用可见文本，两边的表述自动保持同步。
💡 修复方案： 有可见文本元素可以做标签时，优先用 aria-labelledby。只在没有可见文本的场景下才用 aria-label。 |
4. 动态控件的静态 ARIA 标签
一个切换按钮写死 aria-label="切换为深色模式"，不管当前状态是什么，自动化检测都能通过。
标签存在、格式也对 —— 但如果页面已经是深色模式了，这个标签就是错的，应该是 "切换为浅色模式"。
自动化工具只检查有没有、格式对不对，不检查内容准不准确、状态变化后对不对。有状态控件上的静态标签，扫描工具根本发现不了。
💡 修复方案： 把 aria-label 绑定成动态值，跟随当前状态变化：:aria-label="isDark ? 'Switch to light mode' : 'Switch to dark mode'" |
后面我会给一个 Playwright 测试示例，验证交互后切换按钮的 aria-label 有没有更新 —— 在发布前拦住过时的标签。
5. 质量差的替代文本和 ARIA 标签，自动化工具检测不出来
axe-core 只校验属性有没有、格式对不对，不校验内容质量好不好。
aria-label="nav"、aria-label="section 1"、alt="image" 都能通过自动化检测。给不能聚焦的 <div> 加个 role="button" 也能过。
屏幕阅读器听到 "image" 或者 "section 1"，和没加属性没什么区别 —— 有时候反而更糟，因为加了属性会让开发者以为问题已经解决了。
地标区域也有同样的坑：加了 aria-label 就满足规则了，但写得烂的标签和没写一样没用。
自动化工具不会去问 "这个标签真的能帮到看不见页面的人吗？" 这个问题只能人来判断。
图片 alt 文本也是同理。
公司 logo 写 alt="logo" 也能过 axe —— 但完全没传达有效信息。
正确的 alt 文本要看场景，自动化判断不了：
两种写法 axe 都能过，但只有一种在对应场景下传达了正确信息。
💡 修复方案： 加任何 ARIA 属性之前，先问自己：对看不见视觉内容的用户来说，这个属性有没有传达有效信息？ 如果没有，那这个属性不是修复，是噪音。alt 文本也同理 —— 描述图片在页面里的作用，不只是描述图片画了什么。 |
