无障碍测试

为什么

何时使用

如何做

1. CI 自动测试（抓约 30%——机械问题）
   - Playwright 测试中 axe-core: 导航后每页跑
   - eslint-plugin-jsx-a11y: React 中 lint 时检查
   - Lighthouse CI: 构建管道中 a11y 审计
   - @axe-core/playwright 集成测试
   - 这些抓: 缺 alt、无标签、低对比、无效 ARIA、重复 ID

2. 手动键盘测试（抓约 40%——可操作问题）
   - 放下鼠标，用 Tab、Shift+Tab、Enter、Space、Escape、方向键导航
   - 能到每个交互元素吗？焦点顺序合理吗？
   - 焦点指示可见吗？能操作每 widget 吗？
   - 仅键盘能完成每任务（表单、结账、导航）吗？
   - 每页 10-30 分钟找 axe 不能的问题

3. 屏幕阅读器测试（抓约 30%——语义问题）
   - Windows 上 NVDA（免费）+ Chrome/Firefox
   - Mac 上 VoiceOver + Safari
   - Android 上 TalkBack、iOS 上 VoiceOver + Chrome
   - 按标题（H）、表单（F）、链接（K）、区域（R）导航
   - 能懂页结构吗？表单带标签宣读吗？
   - 动态变更宣读吗？错误清晰可恢复吗？

4. 残疾用户测试（金标准）
   - 招实际用辅助技术的用户（盲、运动障碍）
   - 观他们完成真实任务（注册、结账、搜索）
   - 他们体验揭示无开发者测试找的问题
   - 即使 3-5 用户也揭示主要障碍

5. 追踪和修发现
   - 每发现建工单带 WCAG 标准和测试方法
   - 按用户影响优先（阻任务 > 烦 > 美容）
   - 阻塞发布前修，其余追 backlog

示例

// 1. 自动: Playwright 中 axe-core（CI）
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("结账流程无 a11y 违规", async ({ page }) => {
  await page.goto("/checkout");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

// 2. 手动键盘测试（每发布前）
// 清单:
// [ ] Tab 过页——每交互元素可到？
// [ ] 每元素焦点指示可见？
// [ ] Tab 顺序跟视觉阅读顺序？
// [ ] 键盘能开/关模态？焦点返回触发器？
// [ ] 方向键能操作每下拉、标签、手风琴？
// [ ] 仅键盘能完成结账流程？

// 3. 屏幕阅读器测试（NVDA + Chrome）
// 清单:
// [ ] 按 H——标题结构合理（一个 h1、然后 h2）？
// [ ] 按 F——表单字段带标签宣读？
// [ ] 按 K——链接文本描述性（非"点这里"）？
// [ ] 带错误提交表单——错误宣读？
// [ ] 加购物车——购物车更新宣读（aria-live）？
// [ ] 导航到新页——新页宣读（焦点移）？

// 4. 用户测试脚本
// 任务: "注册账户并购买"
// 观察: 屏幕阅读器用户卡在哪？
// 常见发现: 表单错误未宣、提交焦点失、自定义下拉不可操作、标题顺序不合理

// 5. 追踪发现
// 工单: "WCAG 3.3.1: 注册表单错误未宣读（NVDA）"
// 优先: 阻塞（用户不能完成注册）
// 方法: 屏幕阅读器测试，2026-01-15

常见问题

• ⚠仅跑 axe-core 把零违规当"无障碍"——axe 抓 30% 问题，另 70%（键盘可操作、屏幕阅读器语义）需团队跳过的手动测试。
• ⚠用屏幕阅读器测一次觉太难不再做——首次屏幕阅读器测试压倒性，但即使 30 分钟也揭示主要障碍，随练习变易。
• ⚠项目末"有时间时"做 a11y 测试——那时标题结构、焦点顺序和对比已 baked 入设计，追溯改比从一开始为 a11y 设计难 10 倍。
• ⚠测试不涉残疾用户——开发者用屏幕阅读器测找一些问题，但真实用户揭示开发者因知应用应如何工作而不注意的障碍。

最佳实践

• ✓每 PR CI 跑 axe-core、每发布前手动键盘测试、重大功能屏幕阅读器测试——分层法抓每单法漏的。
• ✓设计阶段集成 a11y（对比、标题结构、焦点指示）而非末追溯——为 a11y 设计比后修便宜 10 倍。
• ✓每重大发布至少用真实残疾用户测一次——他们体验揭示无自动或开发者测试找的障碍，即使 3-5 用户也找主要问题。
• ✓a11y 发现当工单追踪带 WCAG 标准、测试方法和用户影响——这使工作可见、优先和可验证非事后想。