自动化可访问性工具分诊

大理论

可访问性质量不能靠一个分数或一个插件判断。不同工具负责不同层级：组件开发期、页面 smoke test、发布前审计、人工辅助复核和任务流验证。Agent 应把它们编排成分诊流程，而不是在报告里堆工具名称。

小知识点

1. axe-core 是规则引擎，适合嵌入 Playwright、Jest、Cypress、Storybook 和浏览器插件生态。
2. Storybook a11y 把 axe 检查前移到组件状态和设计系统预览，但只能覆盖已写出的 story 状态。
3. Pa11y 适合命令行跑 URL/本地预览页 smoke test，适合作为 CI 轻门禁。
4. Lighthouse accessibility category 适合页面级健康信号，但分数不是完整 WCAG 覆盖。
5. Accessibility Insights 和 WAVE 更适合浏览器里的人工辅助审计，帮助确认 tab stop、结构、可访问名称、对比和真实状态。
6. 自动工具通常无法完全判断文案是否合适、交互是否符合任务、焦点顺序是否符合业务含义、读屏体验是否清楚。

设计判断

如果工具报告只停留在“有 12 个 violation”，它没有进入产品流程；当每个问题都绑定 URL/story、状态、规则、影响、selector、用户任务、截图、修复建议、负责人和复测方式时，才是可执行分诊。

实现建议

建立 a11y triage record：工具名与版本、运行时间、URL/story、viewport、登录/数据状态、rule id、impact、selector、失败截图或 DOM 片段、用户任务影响、修复 owner、修复 PR、人工复测结果。CI 中让严重规则阻断，低风险问题进入 backlog；发布前补键盘路径、读屏抽查、高对比和 reduced-motion 手动检查。

反例/风险

只追 Lighthouse 分数、只在首页跑一次工具、组件没有 story 状态、忽略 axe 的 incomplete/manual review、把 WAVE 当自动合规证明、修复后不复测同一 URL/状态。

案例分析

axe-core 官方定位为 accessibility testing engine；Storybook a11y 文档明确其 addon 由 axe-core 驱动并作为 QA 第一线；Pa11y 提供 CLI/Node 自动测试；Lighthouse 覆盖 accessibility/performance/best practices；Accessibility Insights 和 WAVE 则把自动检测和人工评估结合。可学习点是：工具链要按开发阶段分层，最终输出应是产品缺陷记录，而不是孤立报告。

来源链接

axe-core: https://github.com/dequelabs/axe-core Storybook accessibility testing: https://storybook.js.org/docs/8/writing-tests/accessibility-testing Pa11y: https://github.com/pa11y/pa11y Lighthouse: https://github.com/GoogleChrome/lighthouse Accessibility Insights for Web: https://github.com/microsoft/accessibility-insights-web WAVE: https://wave.webaim.org/