写出比 Lighthouse 报告更全面的 Playwright 测试
解决这些缺口的办法，不是放弃自动化测试。
而是写出比默认 axe 检测、Chrome Lighthouse 无障碍报告里的绿圈更进一步的测试。
标准的AxeBuilder扫描是起点，不是终点。
这些测试模式能覆盖默认扫描漏掉的缺陷。
默认 axe 扫描（基础基线）
悬停状态对比度
标准扫描会漏掉只在悬停时出现的对比度问题。先触发状态，再扫描。
聚焦状态对比度
同理 —— 扫描前先触发聚焦，让 axe 校验聚焦态样式。
深色模式对比度
对比度问题可能只在浅色或深色模式下出现。
跳转链接 —— 首个可聚焦元素
验证跳转链接存在、是键盘第一个到达的元素、激活后确实把焦点移到主内容。
唯一地标标签
检出重复的地标名称（最佳实践是地标名称全局唯一）
模糊链接文本
检查那些结构校验能过、但语境不达标的常见问题文案。
有状态控件的动态 aria-label
验证切换按钮的无障碍名称，反映的是它将要执行的动作，而不是交互后才变化。
浅色模式下的切换按钮应该写 "切换为深色模式"。
点击之后，变成 "切换为浅色模式"。
页面已经是浅色模式时，标签还写 "切换为浅色模式" 就是错误 / 误导。
通用 alt 文本
检出那种为了过 linter 随便写、完全没意义的 alt 文本。
人工无障碍测试，补充自动化检测
有些无障碍缺陷，光靠自动化测试永远发现不了。
标签有没有意义还是只是有字、焦点顺序对真实用户来说合不合理、屏幕阅读器播报内容顺不顺 —— 这些都得人来判断。
定期无障碍审核的时候，可以用这个清单，做自动化结构性做不了的检查：
☐ 全程只用 Tab 键遍历页面，不用鼠标 —— 焦点顺序合理吗？ ☐ 第一个可聚焦元素是跳转链接吗？ ☐ 所有地标区域都有标签、互不重复吗？ ☐ 所有链接脱离上下文读出来也通顺吗？ ☐ 动态控件状态变了之后，无障碍名称会更新吗？ ☐ aria-labelledby引用的是可见、准确的文本吗？ ☐ 用真实屏幕阅读器测试 ——NVDA（免费，Windows）、JAWS，或者 VoiceOver（macOS 和 iOS 自带） ☐ 用地标、标题、链接导航 —— 不只是从头到尾线性读 |
按照真实用户的导航方式用屏幕阅读器。
屏幕阅读器用户不一定从头读到尾，他们可能在标题、地标、链接之间跳来定位。
如果这么导航不顺，那不管自动化扫描得多少分，页面都不算无障碍。
总结
Lighthouse、axe、基于 axe-core 的 Playwright 测试这类自动化无障碍工具，是底线，不是上限。
用它们快速排查结构性问题，每次 CI 构建都跑无障碍测试防回归，再写出超出默认扫描的测试，覆盖基础检测漏掉的状态和场景。
和破坏可见行为的功能 bug 不一样，很多无障碍缺陷对视力正常的开发者来说是不可见的。
过时的aria-label、少了地标、焦点顺序错了，都没有视觉痕迹，不专门检查就不会有测试失败。
把它们想成扫地机器人。它们能自动打扫大面积，清掉人工打扫间隔积的灰，但边角还是得自己手动扫。
把自动化工具当成覆盖底线和防回归的保障，把你的人工测试时间，花在需要人工判断、真实用户导航的无障碍问题上。
E n d
