无障碍测试

你在排查什么

当页面只能鼠标驱动、对比度不足或缺少替代文本时，键盘用户和屏幕阅读器用户会被直接挡在核心流程之外。问题在于，这些问题很少以报错形式出现：自动化扫描器通常只能发现 30%～40% 的 WCAG 违规，剩下的 60%～70% 藏在键盘焦点顺序、动态内容播报和自定义组件的交互模型里，只能靠人工验证。更麻烦的是，同一个 ARIA 标记在 NVDA 和 VoiceOver 下的播报结果可能完全不同，跑一遍 DOM 校验并不等于真正可用。

技能如何工作

给定 URL、一段 HTML 或 React/Vue 组件，以及目标级别（WCAG 2.1 AA 或 AAA），技能按以下流程执行：

1. 界定审计范围：确认要审计的页面、组件或用户流程，并指定需要考虑的辅助技术（NVDA、VoiceOver、TalkBack、纯键盘操作、放大工具）。
2. 自动扫描：用 axe-core 或 Lighthouse 跑首轮检查，捕获缺失的 alt 属性、对比度不足、缺少表单标签、重复 ID、无效 ARIA 角色等问题，每条记录 WCAG 条款号（如 1.4.3 Contrast Minimum）、严重级别和 CSS 选择器路径。
3. 键盘导航测试：用 Tab、Shift+Tab、Enter、Space、Escape 和方向键走完每条交互流程，验证焦点顺序与视觉顺序一致、焦点指示器可见、模态框正确困住焦点、不存在键盘陷阱。
4. 屏幕阅读器验证：确认图片替代文本是否合理、标题层级是否连续、landmark 是否齐全、动态更新是否通过 aria-live 区域播报。
5. 生成合规报告：按 WCAG 四项原则（可感知、可操作、可理解、健壮）组织，给出条款号、严重级别、受影响元素的 HTML 片段、失败原因和修复说明，并附通过/失败汇总表。
6. 提供修复代码：每条违规都给出改动前后的代码对比，按组件或页面区域分组，方便开发者系统处理。

适用边界与注意点

• 自动化只是起点：axe-core 抓到的问题之外，仍需人工键盘测试和屏幕阅读器实测。
• 语义 HTML 优先于 ARIA：<button> 不需要 role="button"，<nav> 不需要 role="navigation"；ARIA 是对语义 HTML 不足场景的修补，不是替代品。
• 优先修严重问题：先处理完全阻断访问的违规（键盘不可操作、功能性图片无替代文本），再处理装饰性元素的轻微对比度差距。
• SPA 与动态内容：客户端路由跳转不会触发页面加载，需用 aria-live="polite" 区域播报路由变化，或将焦点程序化移动到新页面的 <main>；JS 注入的内容同理，需包裹在 aria-live 区域中或显式管理焦点。
• 复杂组件：滑块、日期选择器、组合框等没有原生 HTML 对应物，需严格按 WAI-ARIA Authoring Practices 1.2 实现完整键盘交互模型。
• 第三方内容：无法修复 iframe 内部的无障碍问题，只能在 <iframe> 上补 title 属性、记录问题，并在嵌入内容对流程关键时提供可访问的替代方案。
• 建议纳入 CI：在自动化测试中运行 axe-core 或 pa11y，让新的严重违规在进入生产前就被拦住。