我们如何在 CI 中实现无障碍 VPAT 的自动化 我们如何在 CI 中实现无障碍 VPAT 的自动化

无障碍审计更新极快。一次代码合并就可能改变一切。

我们解决了这个问题。我们将无障碍报告转化为了持续构建产物 (build artifact)。

我们的流水线使用三个层级来发现错误：

  • 静态检查：我们在 Storybook 中使用 axe-core 进行基准测试。
  • 交互式测试：我们使用自定义的 Vitest 助手来测试键盘规则。
  • 手动审计：我们将屏幕阅读器的结果存储为 JSON 文件。

我们的 CI 流水线会合并这些结果。

如果测试失败，PR 就会失败。如果所有测试都通过，系统就会生成一个新的 PDF。该 PDF 会随发布版本一同交付。

我们尝试过一种方法，但失败了。

我们尝试使用 LLM 来替代手动审计。我们立即停止了这一尝试。AI 的结果波动太大。对于 CI 门禁 (gate) 来说，你需要稳定的结果。

在这里阅读完整的技术细节：

来源：https://dev.to/yassine_lakhdar_d0226709a/how-we-automated-our-accessibility-vpats-in-ci-46jk

文章内容： 一个开发团队已将其无障碍 VPAT（自愿性产品无障碍模板）的创建过程直接集成到了其持续集成 (CI) 流水线中，将过去定期的手动报告转变为随每次发布一同交付的构建产物。新的工作流会在引入无障碍回归 (accessibility regressions) 时拦截 Pull Request，并在构建成功时自动生成 PDF 合规文档，从而确保每一次代码变更都符合无障碍标准。

为什么自动化至关重要

新代码上线的那一刻，无障碍审计就过时了。一次合并可能会引入缺失的 alt 文本、错误的焦点顺序或屏幕阅读器问题，从而使之前发布的 VPAT 失效。手动维护合规性意味着在每次变更后都要重新运行审计，这是一个成本高昂且容易出错的过程，且往往跟不上开发速度。通过将检查嵌入 CI，团队可以获得即时反馈，保持合规性的实时性，并避免因发布无法使用的软件而带来的法律和声誉风险。

三层测试方法

  1. 静态检查 – 流水线运行 axe-core，这是一个开源库，用于扫描在 Storybook 中渲染的组件，查找已知的违规项，例如缺失的地标 (landmarks) 或对比度不足。这些测试可以在任何交互发生之前捕捉到问题。

  2. 交互式检查 – 自定义 Vitest 助手执行键盘导航规则测试，验证焦点移动是否符合逻辑，以及交互元素是否响应标准的键盘事件。这一层超越了静态分析，以确保真实的可用性。

  3. 手动审计产物 – 屏幕阅读器测试的结果被保存为 JSON 文件。开发人员在探索性测试期间记录观察结果，并将 JSON 文件与代码一同提交。CI 任务将这些产物与自动化结果合并，为 VPAT 提供单一的事实来源 (single source of truth)。

当当前两个层级中的任何测试失败时，Pull Request 就会被拦截，防止变更进入生产环境。如果所有测试都通过，流水线会将合并后的数据组装成一个 PDF 并随发布版本附带，无需额外工作即可交付最新的 VPAT。

什么方法行不通

团队尝试使用大语言模型 (LLM) 来自动生成手动审计部分。AI 生成的结果波动太大，导致 CI 门禁变得不可靠。对于“通过/失败”这种二元检查来说，一致性至关重要，因此该实验被放弃，转而采用基于 JSON 的手动审计产物。

下一步关注点

目前，这种三层 CI 模型提供了一条务实的路径，可以保持 VPAT 的实时性，减少手动开销，并确保无障碍性在每一次代码变更中都处于核心地位。