4. 常见无障碍测试工具介绍

工具选对了，事半功倍。我这些年大大小小项目折腾下来，发现无障碍测试工具各怀绝技，没有一个能包打天下。所以这一章，我把主流工具挨个儿聊一遍——axe‑Core、Lighthouse、WAVE、Pa11y、Accessibility Insights。哪些适合本地开发，哪些适合CI管道，哪些只适合做辅助检查，你想想看，捋清楚了才能少走弯路。

4.1 为什么需要这么多工具？

说白了，每个工具的检测规则和侧重点不一样。有的专注静态分析，有的能跑动态流程，有的直接给你一个浏览器扩展点几下就行。我一个项目里通常会搭两到三个一起用。比如axe‑Core做主引擎，Lighthouse做性能+无障碍整体评分，Pa11y做CI里的回归扫描。嗯，各取所长。

4.2 核心工具逐个看

axe‑Core

axe‑Core是我最常用的引擎。它由Deque Labs开发，现在也是很多工具的内核。它支持的规则非常全，而且对开发者友好——错误信息里直接告诉你违反的是哪条WCAG标准，怎么修。我记得有一次，一个表单提交按钮缺少aria-label，axe直接报出“按钮没有可访问名称”，我两分钟就改好了。

亮点：它原生支持CI集成，npm安装后用命令行就能跑，输出JSON或HTML报告。在CI管道里用起来非常爽。

npm install -g @axe-core/cli
axe https://example.com --save report.json

Lighthouse

Lighthouse是Chrome开发者工具里自带的。它不只查无障碍，还会测性能、最佳实践、SEO。但无障碍部分用的内核其实就是axe的部分规则。我个人习惯用Lighthouse做快速初筛——跑一遍看看总分，心里有个数。但千万别只看分数，很多细节问题Lighthouse是漏掉的。

WAVE

WAVE是WebAIM出的，有浏览器扩展版，也有API。它的可视化方式很直观——直接在页面上盖颜色小图标，告诉你哪里有问题，哪里是ARIA用得不对。我在做快速原型验证时特别喜欢用它。不过WAVE的CI支持比较弱，API有调用次数限制，不适合自动化管道。

Pa11y

Pa11y是专为自动化场景设计的。它底层也可以用axe规则，还能配置多个引擎。我特别喜欢它的pa11y-ci，能对接多个URL或者sitemap，跑完之后出报告，还能和Jenkins、GitHub Actions联动。嗯，我前一个项目就用它在每次PR里跑一遍，如果新增了严重的无障碍违规，直接让流水线失败。

npm install -g pa11y-ci
pa11y-ci --sitemap https://example.com/sitemap.xml

Accessibility Insights

微软出品的工具，有浏览器扩展版和命令行版。它的特色是“快速评估”和“逐步指导”。对于新手尤其友好。我在做团队培训时经常推这个——因为它会一步步带你手动检查对比度、焦点顺序、键盘操作等等。但说实话，它的CI功能还在完善中，自动化扫描的覆盖面不如axe‑Core。

4.3 工具对比一览

下面这张表可以帮你快速决策：

4.4 工具在CI管道中的位置

下面这张图可以帮你理清这些工具在持续集成中的角色。你看，开发提交代码 → 触发CI → 并行运行多个工具 → 合并报告 → 决定是否阻断。

4.5 几个实用组合拳

根据我的经验，不同阶段推荐这样搭配：

• 本地开发阶段：axe‑Core 的浏览器扩展 + WAVE 扩展。快速发现问题，边写边改。
• PR/MR 检查：Pa11y 或 axe‑Core CLI 触发扫描，阻止新增严重违规进入主干。
• 定期全量扫描：Lighthouse CI 生成趋势报告，配合 Pa11y 抓所有页面。
• 上线前人工复核：Accessibility Insights 的逐步检查 + 屏幕阅读器实测。

一句话总结：工具选型看你的管道和团队。如果你还没开始，从 axe‑Core 入手。想加流水线扫描？上 Pa11y。想要直观的视觉引导？WAVE 和 Accessibility Insights 都很好用。别贪多，先跑起来，再逐步完善。