无障碍测试

无障碍测试卡在哪里

很多团队在交付前才开始考虑无障碍，结果发现缺陷集中在组件层和流程层：pa11y 或 axe-core 从未接入构建，CI 里没有相关检查，手动核对 WCAG 2.2 AAA 全靠人记忆，评估结论散落在聊天里，也没有面向用户的无障碍声明页面。等到法务或监管要求落地时，往往需要推翻已有结构来补救。

自动化与手动流程结合

这个技能把自动化检查与手动核对放进同一套流程：

• 自动化层：将 pa11y / pa11y CLI 与 axe-core runner 设为开发依赖，在每次构建新产物时运行，并对独立功能与组件进行隔离测试，避免页面其余部分干扰结果；检查接入现有 CI 流水线，让回归在合并前暴露。
• 手动层：对每个组件逐条核对 WCAG 2.2 Level AAA，生成含编号、名称、描述与状态（pass / fail / not applicable / untested）的表格，可沉淀为模板复用；可用 Playwright 等浏览器工具替代部分过去依赖真实用户的判断，无法可靠结论处留下带评估说明的 todo。
• 输出层：每次评估输出简短书面报告，记录问题与建议修复；如果完整架构调整才是正确选择，就不推荐速成修补，尤其是涉及 ARIA 模式的场景。

法规合规与适用边界

按欧盟无障碍法案及德国 BFSG 等本地法规，需要面向公众提供无障碍说明页面，涵盖服务名称与描述、提供方联系方式、适用法律名称、评估所用工具与代理、逐准则合规状态（通俗语言）、监管机构联系方式、最近评估日期及未通过项的计划修复日期。法规还要求主动告知监管机构，需起草邮件并调研监管机构邮箱。该页面应出现在每个页面、靠近隐私政策等链接处，即使服务可能不直接受该法约束，也建议实现。

需注意：pa11y、axe-core、Playwright 这类工具只能覆盖可程序化判定的部分；语义结构、焦点顺序合理性、真实键盘与读屏体验仍需人工判断。表格中的 untested 项不应被当作 pass 提交。