axe-core 可访问性测试引擎

问题：可访问性缺陷总在上线后才暴露

不少团队把可访问性检查留到部署之后：用户投诉、客服工单或年度合规审计才揭示按钮缺少可访问名称、文本对比度不足、焦点顺序混乱、表单错误提示不关联等问题。此时修复成本远高于开发期，且根因往往分散在多个组件里，靠人工逐页排查既慢又容易漏。更麻烦的是，这类缺陷不会导致功能报错，CI 流水线里完全看不到。

技能如何工作

这个技能把 axe-core —— Deque Systems 提供的行业标准可访问性测试引擎 —— 接入到现有自动化测试体系中，核心能力包括：

• 自动检测 Web 界面中的 WCAG 2.0、2.1 和 2.2 违规，覆盖常见的结构性、语义性和对比度规则。
• 以 axe.configure() 或本地化构建的方式运行，本地化文件放在 ./locales 目录中，命名遵循 <lang>.json 格式。
• 在测试系统的每个 iframe 内注入引擎脚本，从而对页面内嵌框架一并审计，而不只是顶层文档。

关键步骤很直接：下载引擎包，在测试 fixture 的每个 iframe 中包含对应的 JavaScript 文件，然后执行规则集，把违规项作为测试结果返回。

适用边界

• 自动化不替代手动审计：axe-core 擅长检测结构性违规，但键盘走查、屏幕阅读器实操、低视力用户的缩放体验仍需人工验证。
• 规则集需要裁剪：默认规则集可能包含与项目无关的检查，建议在 axe.configure() 中按团队规范启用或禁用规则，避免噪声淹没真实缺陷。
• 注入时机影响结果：脚本必须在目标 DOM 渲染完成后运行，否则审计结果可能遗漏动态加载的内容。