网页可访问性测试

页面为什么「看起来正常」却不可用

一个登录表单在浏览器里渲染正确，但用 Tab 键走一遍就发现：焦点顺序和视觉顺序不一致，模态框打开后焦点没有被捕获，某个用 <span> 包起来的按钮根本无法用键盘激活。更隐蔽的是对比度问题——正文文字对比度只有 2.32:1，远低于 AA 要求的 4.5:1。这类缺陷不会让页面崩溃，却会让依赖屏幕阅读器或键盘的用户完全无法完成任务。

这个技能做了什么

它按照 WCAG 2.1 的四大原则——可感知、可操作、可理解、健壮——对网页或组件做审计，目标级别可选 AA 或 AAA，并明确要覆盖的辅助技术（NVDA、VoiceOver、TalkBack、纯键盘操作、放大工具）。

工作流程分六步：

• 确定范围：选定页面、组件或用户流程，指定符合级别和辅助技术。
• 自动化扫描：用 axe-core 或 Lighthouse 跑自动化检查，能捕获约 30-40% 的违规项——缺失的 alt 属性、对比度不足、表单没有 label、重复 ID、无效 ARIA 角色、文档缺少 lang 属性。每条违规都带 WCAG 条款编号、严重级别、受影响元素和 CSS 选择器路径。
• 键盘导航测试：只用 Tab、Shift+Tab、Enter、Space、Escape 和方向键走完所有交互流程，验证焦点顺序、焦点指示器（至少 2px 轮廓、3:1 对比度）、模态框焦点捕获，确认没有键盘陷阱。
• 屏幕阅读器验证：确认图片有有意义的 alt 文本（装饰性图片用 alt=""）、标题层级没有跳级、<nav> / <main> 等 landmark 存在、动态内容通过 aria-live 区域播报。
• 生成合规报告：按 WCAG 原则和条款分组，每条违规包含条款编号、严重级别、HTML 片段、失败原因和具体修复代码，附每原则的通过/失败统计表。
• 提供修复代码：每条违规都给出前后对比代码，按组件或页面区域分组。

适用边界与注意点

• 自动化只是起点：axe-core 只能发现约 30-40% 的问题，剩下的 60-70% 必须靠手工键盘测试、屏幕阅读器实测和认知负荷审查。
• ARIA 不是银弹：优先用语义化 HTML。<button> 不需要 role="button"，<nav> 不需要 role="navigation"。而且 ARIA 标记正确不代表播报正确，VoiceOver 和 NVDA 对同一份标记的解读可能不同，必须用真实屏幕阅读器测试。
• 先修严重问题：完全阻断访问的问题（键盘不可操作、功能性图片没有 alt）优先级高于装饰性元素的轻微对比度不足。
• 单页应用与动态内容：客户端路由不触发页面加载，屏幕阅读器感知不到内容变化，需要 aria-live="polite" 区域播报路由变更或把焦点移到新页面的 main；Toast 通知用 aria-live="assertive"。
• 复杂表格和自定义组件：合并单元格、嵌套表头需要显式 scope 和 aria-sort；滑块、日期选择器、组合框没有原生 HTML 等价物，必须严格遵循 WAI-ARIA Authoring Practices 1.2 的键盘交互模型。
• 第三方嵌入内容：iframe 内的可访问性无法修复，只能加描述性 title，并在关键流程中提供可访问的替代方案。
• 纳入 CI：在自动化测试里跑 axe-core 或 pa11y，让关键违规在到达生产环境前就阻断构建。