跳转至

Deep Research: [17] WCAG 2.2：可访问性底线与可验收检查项

  • Source: https://www.w3.org/TR/WCAG22/
  • Note: ../notes/ref-017-wcag-2-2.md
  • Snapshot: ../sources/md/www-w3-org-tr-wcag22-a3b0aa493d7c.md

TL;DR

WCAG 2.2（Web Content Accessibility Guidelines）是全球通用的数字内容可访问性标准，它将好用转化为可测试的工程指标（如对比度、点击区域大小），是软件产品从可用迈向高质量的底线门槛。

核心观点

  1. POUR 四大原则：感知（Perceivable）、操作（Operable）、理解（Understandable）、鲁棒（Robust）构成了可访问性的地基，缺一不可。
  2. 客观验收而非主观审美：可访问性不是关于设计的品味争论，而是关于代码的合规性测试。例如：文字与背景对比度至少 4.5:1（AA 级），这是数学题，不是美术题。
  3. 键盘是交互的灵魂：真正的可访问性要求不仅能看，还能完全通过键盘（或模拟键盘的辅助设备）完成所有操作。WCAG 2.2 特别强化了焦点不可被遮挡的要求。
  4. 移动端友好即无障碍：WCAG 2.2 新增的点击目标大小（Target Size）最低 24x24 CSS 像素要求，直接改善了手指粗大或颤抖用户的体验，也造福了所有移动端用户。
  5. 认知减负：新标准强调减少用户的记忆负担，例如冗余输入（Redundant Entry）准则要求系统不应让用户重复输入已提供的信息，这对应了更好的表单设计体验。
  6. 语义化 HTML 胜过 ARIA：最稳健的实现方式是正确使用原生 HTML 标签（如 <button> 而非 <div onclick=...>），而非滥用 ARIA 属性进行修补。
  7. 自动化测试的局限性：虽然 AI 和自动化工具（如 Axe）能发现 30%-50% 的语法级错误，但操作逻辑是否闭环、替代文本是否准确仍需人工或高级 AI 代理进行语义判断。

可落地做法

1. 产品经理（PRD 阶段）

  • 定义标准：在非功能需求（NFR）中明确标注符合 WCAG 2.2 AA 标准。
  • 定义文案：为所有非文本内容（图标、状态图）提供简明的文本描述（Alt Text）需求。

2. 设计师（UI 阶段）

  • 色彩校验：设计系统中的所有前景色/背景色组合必须通过对比度校验（普通文本 4.5:1，大号文本 3:1）。
  • 焦点状态：设计每个交互组件的 Focus 状态，确保其不仅仅是浏览器默认的蓝框，且在视觉上不被遮挡。

3. 工程师（开发与 CI 阶段）

  • 语义化编码：使用语义化标签搭建骨架，确保屏幕阅读器能解析大纲结构（H1-H6）。
  • 自动化门禁：在 CI 流水线中集成 axe-core 或 pa11y，阻断明显的可访问性错误代码合入。
  • 键盘测试：开发完成后，丢掉鼠标，仅用 Tab、Space、Enter 和方向键尝试完成核心业务流程。

检查清单（WCAG 2.2 AA 核心速查）

此清单可作为完成定义（DoD）的一部分：

  • 可感知（Perceivable）

    • [ ] 非文本内容：所有有意义的图片、图表均有 alt 属性描述核心信息；装饰性图标把 alt 设为空字符串或隐藏。
    • [ ] 对比度：正文文本对比度 >= 4.5:1；大号文本（18pt+ / 14pt+ Bold）>= 3:1；UI 组件边框 >= 3:1。
    • [ ] 不依赖单一感官：不仅仅通过颜色（如红/绿）传达错误或状态，须配合图标或文字。

  • 可操作（Operable）

    • [ ] 键盘可达：所有链接、按钮、表单均可被键盘聚焦并激活。
    • [ ] 无键盘陷阱：焦点进入组件后，也能通过键盘移出。
    • [ ] 焦点可见且不被遮挡（2.2 新增）：当前聚焦元素有清晰可见的轮廓，且不被 Sticky Header/Footer 遮挡。
    • [ ] 点击目标大小（2.2 新增）：触控目标至少 24x24 CSS 像素，或有足够间距。

  • 可理解（Understandable）

    • [ ] 页面语言：<html> 标签正确设置了 lang 属性（如 zh-CN）。
    • [ ] 错误提示：表单报错时，通过文本清晰说明错误原因，并建议修改方式。
    • [ ] 标签在名字中（Label in Name）：按钮上的可见文字应包含在无障碍名称（aria-label）中，支持语音控制。

  • 鲁棒性（Robust）

    • [ ] HTML 解析：ID 唯一，标签正确闭合，无重复属性。
    • [ ] 状态通知：动态加载的内容变化（如搜索结果更新）能通知到辅助技术（使用 Live Regions）。

常见坑与对策

  • 坑 1：轮廓移除（outline: none）

    • 现象：为了美观，在 CSS Reset 中全局去除了聚焦轮廓，导致键盘用户迷路。
    • 对策：使用 :focus-visible 伪类，仅在键盘操作时显示明显轮廓，鼠标点击时保留默认样式。

  • 坑 2：虚假的按钮

    • 现象：使用 <div> 或 <span> 加点击事件模拟按钮，导致无法聚焦且无语义角色。
    • 对策：强制使用 <button>。若必须用非语义标签，需补全 role=button、tabindex=0 并处理 Enter/Space 键盘事件。

  • 坑 3：仅靠自动化工具

    • 现象：Lighthouse 跑分 100，但盲人用户依然无法下单。
    • 对策：自动化工具无法理解业务逻辑（如弹窗后焦点是否归位）。必须引入人工/AI 模拟操作走查。

可用于丰富《AI 辅助软件产品》的写作点

  • 第 3 章（PRD） - 非功能性需求

    • 建议：利用 AI 辅助生成验收标准（AC）。提示词：作为产品经理，请根据 WCAG 2.2 AA 标准，为这个‘用户登录’功能生成一份可访问性验收清单。

  • 第 6 章（UI 设计） - 生成式 UI

    • 建议：在 Prompt 中明确约束 AI 生成符合 WCAG 标准的代码。
    • Prompt 示例：生成一个 React 登录表单，使用 Tailwind CSS。要求：符合 WCAG 2.2 AA 标准，包含合适的 ARIA 标签，错误状态仅靠颜色无法区分时需增加图标提示，聚焦状态必须有高对比度轮廓。

  • 第 8 章（前端工程） - 自动化测试流水线

    • 建议：介绍如何配置 CI 工具（如 GitHub Actions + Cypress-axe），让 AI 写测试脚本来自动拦截对比度不足的代码提交。

  • 第 18 章（评估与质量） - 质量门禁

    • 建议：将可访问性定义为产品上线的熔断指标。如果 AI 生成的代码导致 Axe 扫描出 Critical 级问题，禁止自动部署。可以展示一个 AI 修复可访问性 Bug 的实战案例（由 AI 自动调整颜色 HEX 值以满足 4.5:1）。