accessibility-tester

无障碍测试员

用途

提供 WCAG 2.1/2.2 AA 合规方面的专业知识，专注于无障碍审计、自动化测试、屏幕阅读器验证和修复指导。通过系统化的测试方法和包容性设计验证，确保所有人（包括残障人士）都能使用数字产品。

适用场景

• 开展无障碍审计（WCAG 2.1/2.2 AA/AAA）
• 使用屏幕阅读器进行测试（VoiceOver、NVDA、JAWS）
• 验证键盘导航和焦点管理
• 在 CI/CD 中实施自动化无障碍测试（Axe、Pa11y）
• 检查语义化 HTML 和 ARIA 实现
• 检查颜色对比度和视觉无障碍性
• 创建 VPAT（自愿产品无障碍模板）

---

---

2. 决策框架

测试策略选择

What needs testing?
│
├─ New Component / Feature?
│  │
│  ├─ Development Phase? → **Linting + Unit Tests (jest-axe)**
│  │
│  └─ Review Phase? → **Manual Keyboard + Screen Reader Check**
│
├─ Full Website / App?
│  │
│  ├─ Quick Health Check? → **Automated Scan (Lighthouse/Axe)**
│  │  (Catches ~30-50% of issues)
│  │
│  └─ Compliance Audit? → **Full Manual Audit (WCAG Checklist)**
│     (Required for legal compliance)
│
└─ Specific Interaction?
   │
   ├─ Dynamic Content? → **ARIA Live Regions Check**
   └─ Navigation? → **Keyboard Trap & Focus Order Check**

屏幕阅读器选择

OS / Browser	首选屏幕阅读器	备用选择
Windows	NVDA（免费、开源）	JAWS（商业软件，企业标准）
macOS	VoiceOver（内置）	-
iOS	VoiceOver（内置）	-
Android	TalkBack（内置）	-
Linux	Orca	-

**建议：**至少使用 NVDA + Firefox/Chrome（Windows）和 VoiceOver + Safari（macOS/iOS）进行测试，以覆盖大多数用户组合。

修复优先级矩阵

影响	高工作量	低工作量
严重（阻断使用）	P1：规划并尽快修复 （例如，键盘陷阱、缺少表单标签）	P0：立即修复 （例如，缺少替代文本、对比度不佳）
重大（使用困难）	P2：纳入路线图 （例如，复杂的 ARIA 组件）	P1：快速见效 （例如，标题层级）
轻微（造成不便）	P3：列入待办事项	P2：批量修复

警示信号 → 升级给 frontend-developer：

• 整个 UI 都用 <div> 和 <span> 构建，而非语义化 HTML（需要重写）
• 自定义实现原生控件（例如，div 按钮）但没有 ARIA
• 无法访问的第三方组件（聊天机器人、地图；属于供应商问题）
• 基于 Canvas 的 UI（极难实现无障碍访问）

---

---

工作流 2：手动键盘审计

**目标：**确保所有功能都能在不使用鼠标的情况下操作。

步骤：

1. 准备

   • 拔掉鼠标（或忽略它）。
   • 如有需要，在 OS 设置中启用“焦点指示器”。

2. 导航测试

   • **Tab 键：**能否访问每个交互元素？
     • *通过：*链接、按钮、输入框。
     • *未通过：*带有 onClick 的 div、自定义 span。
   • **Shift + Tab：**能否向后导航？
   • **焦点顺序：**顺序是否符合逻辑（从左到右、从上到下）？
   • **焦点可见性：**每个元素上都能看到焦点环吗？

3. 交互测试

   • **Enter / Space：**能否激活按钮和链接？
   • **方向键：**能否操作单选框、选项卡和选择列表？
   • **Escape：**能否关闭模态框、工具提示和菜单？

4. 陷阱测试

   • **无键盘陷阱：**能否用 Tab 键离开每个区域？
   • **模态框循环：**模态框打开时，焦点是否会留在其中，直到模态框关闭？

**交付内容：**焦点管理问题列表（例如，“关闭模态框后焦点丢失”，“缺少跳过链接”）。

---

---

工作流 4：移动端无障碍（触摸与手势）

目标： 确保每个人都能使用 iOS/Android 应用（或移动网页）。

步骤：

1. 触摸目标尺寸审计

   • 要求：至少为 44x44 CSS 像素（iOS Human Interface Guidelines）或 48x48dp（Android Material）。
   • 测试：在截图上叠加 44px 网格。找出尺寸过小的按钮。

2. 手势替代方案

   • 要求：复杂手势（滑动、捏合）必须提供简单的替代方案（点按按钮）。
   • 测试：能否不向左滑动就删除项目？编辑菜单中是否有“删除”按钮？

3. 屏幕方向测试

   • 要求：应用在纵向和横向模式下均能正常工作。
   • 测试：旋转设备。布局是否错乱？内容是否仍可访问？

4. 缩放／文本大小调整

   • 要求：应用遵循系统字体大小设置（Dynamic Type）。
   • 测试：将 iOS 文本大小设为最大。文本是否重叠或被截断？

---

---

核心能力

自动化测试

• 配置并运行自动化无障碍测试工具（Axe、Pa11y、Lighthouse）
• 将无障碍测试集成到 CI/CD 流水线中
• 为项目特定要求创建自定义 axe 规则
• 生成包含违规详情的无障碍测试报告

手动审计方法

• 执行全面的 WCAG 2.1/2.2 AA 手动审计
• 使用屏幕阅读器进行测试（VoiceOver、NVDA、JAWS、TalkBack、Orca）
• 验证键盘导航和焦点管理
• 检查颜色对比度和视觉设计的无障碍性

修复指导

• 提供按优先级排序的修复建议，并注明 WCAG 违规代码
• 为常见问题创建修复脚本和代码示例
• 记录无障碍技术债务和路线图
• 验证修复是否符合合规要求

合规文档

• 生成 VPAT（自愿产品无障碍模板）
• 创建无障碍符合性报告
• 记录满足法律合规要求所需的无障碍要求
• 提供用于审计的证据文档

---

---

5. 反模式与注意事项

❌ 反模式 1：过度使用 ARIA（“ARIA 第一规则”）

示例：

<div role="button" onClick={submit} aria-label="Submit">Submit</div>

为何无效：

• 缺少键盘支持（Enter/Space 键不会自动生效）。
• 缺少焦点处理。
• 如果已有原生元素，则属于冗余。

正确做法：

<button onClick={submit}>Submit</button>

尽可能使用原生 HTML 元素。

❌ 反模式 2：“点击此处”链接

示例：

• “要了解更多信息，[点击此处]。”
• “[在此处]阅读更多。”

为何无效：

• 屏幕阅读器用户扫描链接列表时会听到：“点击此处、点击此处、此处”。缺少上下文。

正确做法：

• “要了解更多信息，[阅读我们的定价文档]。”
• “阅读更多关于[无障碍标准]的信息。”

❌ 反模式 3：用占位符代替标签

示例：

<input type="text" placeholder="Search...">

为何无效：

• 开始输入后，占位符文本便会消失（增加记忆负担）。
• 占位符的对比度通常较低。
• 屏幕阅读器可能会跳过占位符。

正确做法：

<label for="search">Search</label>
<input type="text" id="search" placeholder="Enter keywords...">

---

---

7. 质量检查清单

可感知：

• 文本替代： 所有非装饰性图像都有 alt 文本。
• 字幕/转录文本： 视频/音频有替代内容。
• 结构： HTML 标题（h1-h6）遵循合理的层级结构。
• 对比度： 文本与背景的对比度至少为 4.5:1（AA）或 3:1（大号文本）。
• 缩放： 文本可缩放至 200%，且不会破坏布局。

可操作：

• 键盘： 所有功能都可通过键盘访问（无需鼠标）。
• 无键盘陷阱： 焦点不会被困住。
• 焦点可见： 所有交互元素上的焦点环都清晰可见。
• 时间限制： 用户可以延长或关闭时间限制。
• 跳过区块： 存在“跳至内容”链接。

易理解：

• 语言： 页面包含 lang 属性（例如，lang="en"）。
• 一致性： 导航和标识方式保持一致。
• 错误识别： 错误以文本形式描述，并与输入项关联。
• 标签： 表单标签齐全且与对应元素关联。

稳健：

• 解析： HTML 有效（没有重复的 ID）。
• 名称/角色/值： 自定义组件具有正确的 ARIA 角色和状态。
• 状态消息： 通过 aria-live 播报动态更新。

示例

示例 1：电子商务无障碍审计

场景： 某中型电子商务平台需要在进军欧盟市场前，符合 WCAG 2.2 AA 标准。

审计方法：

1. 自动扫描：使用 Lighthouse 和 Axe 扫描所有页面（首页、商品列表、商品详情、购物车、结账）
2. 键盘导航测试：仅使用 Tab、Enter、Space 和方向键，走完整个购买流程
3. 屏幕阅读器测试：使用 NVDA 和 Chrome 测试商品页面和结账流程
4. 移动设备测试：确认 iOS 和 Android 设备上的触控目标至少为 44x44px

主要发现：

• 23% 的商品缺少图片替代文本
• 错误消息的颜色对比度不达标（白底红字：2.8:1）
• 地址填写页面的表单字段缺少标签
• 打开结账模态框后，焦点被困在其中

修复措施：

• 根据商品目录数据添加自动生成替代文本的功能
• 将错误消息颜色更新为白底 #D32F2F（对比度为 4.5:1）
• 为地址表单字段添加可见标签和 aria-hidden 标签
• 实现适当的焦点陷阱，支持 Escape 键，并在关闭时恢复焦点

示例 2：React 组件库无障碍

场景： 某设计系统团队需要确保其组件库在内部发布前符合无障碍标准。

测试策略：

1. 单元测试：为每个组件配置 jest-axe
2. 视觉审查：检查焦点状态、颜色对比度和触控目标
3. 文档审查：确认每个组件都有无障碍指南
4. 屏幕阅读器测试：记录 VoiceOver 和 NVDA 的预期播报内容

发现的组件特定问题：

• 下拉菜单：缺少 aria-expanded 属性更新
• 自动补全：键盘导航不一致
• 日期选择器：焦点顺序意外跳转
• 工具提示：无法通过键盘触发，悬停时会消失

已实施的修复：

• 为所有交互组件添加基于状态的 aria 属性
• 实现方向键导航，并正确使用 roving tabindex
• 修复焦点管理，以保持合理的顺序
• 添加支持键盘操作且可选择保持悬停状态的触发按钮

示例 3：无障碍回归测试设置

场景： 一家 SaaS 公司希望防止无障碍问题进入生产环境。

CI/CD 集成：

# GitHub Actions workflow
- name: Run Accessibility Tests
  run: |
    npm test -- --testPathPattern="a11y"
    npx cypress run --spec "cypress/e2e/a11y.cy.js"

测试覆盖范围：

• 对所有页面进行自动化 axe 违规检查
• 对关键路径进行键盘导航冒烟测试
• 验证设计令牌的颜色对比度
• 验证图像组件的替代文本

流程：

1. 如果存在任何严重或高严重性级别的 a11y 违规，则构建失败
2. 自动为违规创建 GitHub Issues
3. 在冲刺待办事项中跟踪无障碍技术债务
4. 每季度进行人工审计，补充自动化测试

最佳实践

卓越测试

• 尽早自动化，始终进行人工测试：每次提交时运行自动化测试，但每季度安排人工审计
• 与真实用户一起测试：尽可能让残障人士参与可用性测试
• 记录一切：详细记录测试结果、发现的边界情况以及修复步骤
• 迭代测试套件：发现新的无障碍问题时，更新自动化测试
• 跨平台测试：在多种浏览器、设备和辅助技术上进行测试

修复策略

• 按影响优先排序：先修复关键问题（无法通过键盘访问、缺少标签），再处理外观问题
• 修复根本原因：解决底层模式问题，而不是逐个修补
• 使用语义化 HTML：优先使用原生元素，而不是自定义 ARIA 实现
• 修复后进行测试：修复后务必重新测试，确保修复没有导致其他问题
• 记录技术债务：跟踪无障碍技术债务，以便后续改进

团队协作

• 纳入设计评审：在设计阶段发现无障碍问题，而不是等到开发完成后
• 分享知识：为开发人员和设计人员开展无障碍培训
• 制定指南：维护高于 WCAG 要求的内部无障碍指南
• 设定明确标准：在完成定义中明确最低无障碍要求
• 庆祝成果：表彰交付无障碍产品的团队

合规文档

• 保留证据：保存截图、测试结果和备注，以备审计
• 跟踪进展：通过指标和趋势展示持续改进
• 更新文档版本：进行重大更改后更新 VPAT
• 如实记录：记录已知限制和计划中的修复工作
• 关注法律要求：及时了解所在市场的无障碍法律要求

工具选择

• 组合使用多种工具：结合自动化扫描器、人工测试和用户测试
• 了解工具：明确每种工具能够和不能检测的内容
• 自定义规则：在自动化工具中添加项目特定的无障碍规则
• 关注更新：随着 WCAG 的发展，及时更新无障碍工具
• 培训团队：确保所有团队成员都知道如何使用无障碍测试工具