CI/CD 开发生命周期中的自动和手动可访问性测试

每年仅在一次性手动审查中检查一次的可访问性几乎总是会很快被侵蚀——任何小的代码更新都可能会破坏已经修复的东西。解决方案：将可访问性测试作为自动化步骤构建到开发过程本身 (CI/CD) 中，以便在问题到达生产之前就发现问题。本文解释了如何操作。

为什么一次性检查还不够

每周（有时甚至每天）发布更新的开发团队不能依靠年度可访问性审核来维持持续的合规性。在没有考虑可访问性的情况下添加的新组件，或者意外降低对比度的 CSS 更改，都可能会破坏已经修复的可访问性 - 在用户或投诉揭露之前没有人注意到。同样的原则也适用于文档 - 请参阅我们的指南映射常见错误.

CI/CD 管道中的哪些自动化工具可以捕获

像 axe-core、Pa11y 或 Lighthouse CI 这样的工具可以在每个拉取请求或每次部署之前自动运行 - 在几秒钟内，它们会检查以下内容：颜色对比度、不正确或重复的 ARIA 标签、缺少替代文本、缺少表单标签以及不正确的标题顺序。如果检查失败，拉取请求将被自动阻止合并——就像常规代码审查或失败的单元测试一样。

仍然需要手动测试的地方

就像文档测试一样，CI/CD 管道中的自动化工具可以捕获明显的结构问题，但它们无法判断实际的用户体验：键盘导航是否有意义、屏幕阅读器是否在页面上“讲述一个连贯的故事”，或者自定义组件（如轮播或模态）是否真正可在实际使用中使用。这就是为什么值得将持续的自动检查与定期的手动审核（例如每季度一次）结合起来。

如何在实践中实施

1. 选择适合您的技术堆栈的测试工具（axe-core 适用于大多数 JavaScript 项目，Lighthouse CI 适用于基于浏览器的项目）。
2. 将其作为 CI 管道中的一个步骤运行 - 通常作为 GitHub Action、GitLab CI 作业或您使用的任何 CI/CD 工具中的等效步骤。
3. 在检查成为阻止者之前设置明确的故障阈值（例如：每个轴核心没有“关键”级问题）。
4. 也覆盖您的 PDF 文件：如果您的组织自动生成文档（发票、报告），请考虑为这些文件添加自动扫描，作为发布过程的一部分。