Deep Research: Web Content Accessibility Guidelines (WCAG) 2.2¶

Source: https://www.w3.org/TR/WCAG22/
Snapshot: ../../sources/md/www-w3-org-tr-wcag22-a3b0aa493d7c.md
Category: UX / UI & Design Systems (ux_ui)
Chapters: 04-prototype, 06-ui, 08-frontend, 05-validation

TL;DR¶

WCAG 2.2 是 W3C 发布的最新 Web 内容无障碍指南，它在 2.1 版本基础上增强了对认知障碍、低视力及移动端用户的支持（如点击目标尺寸、无障碍验证码等），是当前构建包容性强、合规且高可用 AI 产品 UI/UX 的全球事实标准。

核心观点¶

四大铁律（POUR 原则）：所有无障碍设计都建立在四个基石之上——可感知（信息不能只通过一种感官获取，如盲人需听屏幕阅读器）、可操作（不能只依赖鼠标，键盘必须能搞定一切）、可理解（操作逻辑一致，报错清晰）、鲁棒性（代码规范，兼容各种辅助技术）。
分级达标制（A/AA/AAA）：标准分为三个等级。A 级是底线（不做连基本使用都困难）；AA 级是行业通用的及格线，也是大多数法律法规要求的标准；AAA 级是卓越标准，通常只针对特殊场景。
2.2 版本的新增重点：重点填补了之前的短板，特别是针对认知障碍和精细动作障碍用户。新增了 9 条标准，比如要求点击区域不能太小（防止手抖点错）、登录不能只靠拼图或记密码（支持复制粘贴或生物识别）。
不再只谈残障：WCAG 的受益者不只是视障人士。老年人（视力下降）、强光下看手机的用户、在大屏设备上操作的用户，都能从高对比度、大点击热区的设计中受益。
焦点可见性至关重要：2.2 特别强调了键盘焦点不能被遮挡。用户用 Tab 键切换时，必须清晰地看到当前选中了哪个按钮或输入框，不能被悬浮窗挡住。
告别反人类验证码：新标准明确反对复杂的认知型验证码（如辨认红绿灯、计算题），提倡使用不需要计算或记忆的认证方式（如 2FA、OAuth、生物识别）。
防止误操作：对于拖拽操作（如看板卡片拖动），必须提供简单的单点点击替代方案，以适应无法精准控制鼠标的用户。
代码即无障碍：大部分无障碍问题（如屏幕阅读器读不出按钮含义）源于 HTML 结构不规范。写好语义化代码（用 <button> 而不是 <div onclick>）能解决 80% 的问题。
向后兼容：符合 WCAG 2.2 的内容自动符合 2.1 和 2.0。如果你的产品通过了 2.2 测试，就无需担心旧标准合规性。
移除了一条旧标准：WCAG 2.2 正式移除了 4.1.1 解析（Parsing）标准，因为现代浏览器容错性已经足够好，不再需要死扣 HTML 语法闭合等细节错误，给开发者减负。

可落地做法¶

面向产品经理 (PM)¶

需求阶段定义标准：在 PRD 中明确符合 WCAG 2.2 AA 级标准。这意味着必须考虑：登录流程是否过于复杂？是否有超时登出的风险？
认证流程设计：废除纯记忆或计算型验证码。如果必须有人机验证，确保提供语音验证或简单的勾选验证。
帮助入口一致性：如果在多个页面提供帮助或聊天机器人入口，确保它们在所有页面的位置是一致的（如固定在右下角）。

面向 UI/UX 设计师¶

色彩与对比度：使用插件（如 Stark）实时检查文本对比度（AA 级普通文本需 4.5:1）。
点击目标尺寸：确保所有可点击元素的点击热区至少为 24x24 CSS 像素（WCAG 2.2 新规），哪怕图标本身很小，热区要留够。
焦点状态设计：不要依赖浏览器默认的蓝色边框，设计一套清晰、高对比度的 :focus 状态，并确保它不会被 Sticky Header/Footer 遮挡。

面向前端开发 (Engineering)¶

语义化优先：严格使用语义化标签。如果是按钮就用 <button>，如果是链接就用 <a>。
键盘导航测试：开发完一个组件，扔掉鼠标，只用 Tab、Enter、Space 和方向键试一遍。如果卡住了，就是 Bug。
替代拖拽：如果实现了 Drag & Drop 功能，必须同时实现一套基于点击的选中-移动-放置逻辑。
元数据填充：为图片加 alt，为无文本的图标按钮加 aria-label。

面向 QA/评测¶

自动化 + 人工双重验收：
- Step 1：使用 Lighthouse 或 Axe DevTools 跑自动化扫描（能发现约 30-50% 的语法级错误）。
- Step 2：人工测试键盘逻辑（Tab 顺序、焦点是否可见）。
- Step 3：使用屏幕阅读器（Mac VoiceOver 或 Windows NVDA）闭眼测试核心流程。

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

感知 (Perceivable)¶

[ ] 文本替代：所有图片都有 alt 属性，装饰性图片把 alt 设为空字符串。
[ ] 视频字幕：视频内容提供同步字幕 (Captions) 或听录稿 (Transcript)。
[ ] 对比度：普通文字与背景对比度 >= 4.5:1，大号文字 >= 3:1。
[ ] 不依赖单一感官：报错不只靠变红，要配合文字说明或图标；操作提示不只靠声音。

操作 (Operable)¶

[ ] 全键盘操作：所有功能均可仅通过键盘完成。
[ ] 无键盘陷阱：焦点进得去，也出得来。
[ ] 焦点可见性 (新)：焦点指示器清晰可见，且不被页面的悬浮元素遮挡。
[ ] 点击目标 (新)：点击热区至少 24x24 CSS 像素（除非它是行内链接）。
[ ] 拖拽替代 (新)：拖拽功能有对应的单点点击操作方案。

理解 (Understandable)¶

[ ] 语言设置：html 标签正确设置了 lang 属性，例如 lang=zh-CN。
[ ] 一致性：导航栏、搜索框在不同页面位置一致。
[ ] 帮助入口 (新)：如果提供帮助，位置在全站保持一致。
[ ] 防错与纠错：表单提交前可检查，报错信息明确指出哪个字段错了并提供建议。
[ ] 冗余输入 (新)：同样的信息（如收货地址）不需要用户重复输入，支持自动填充或选择。

鲁棒 (Robust)¶

[ ] 组件名称：自定义组件（如 AI 对话框）有正确的 name、role 和 value，能被辅助技术识别。
[ ] 状态通知：AI 生成内容时，使用 aria-live 通知屏幕阅读器内容更新。

常见坑与对策¶

坑：以为装个无障碍插件就万事大吉
- 现象：网站右下角挂一个无障碍工具条（调整字体、颜色），就宣称合规。
- 对策：这些 Overlay 工具通常无法修复代码层面的语义错误，甚至会干扰屏幕阅读器。必须从代码底层解决 ARIA 和语义化问题。
坑：轮播图（Carousel）是无障碍噩梦
- 现象：自动播放、键盘无法暂停、焦点乱跳。
- 对策：尽量避免使用轮播图。如果必须用，必须提供暂停按钮，且支持键盘左右键切换。
坑：display: none 滥用
- 现象：为了视觉隐藏某个元素，用了 display: none，导致屏幕阅读器也读不到了。
- 对策：如果是想给盲人用户提供额外信息（如在新窗口打开），请使用 CSS sr-only 类（通过 clip 属性隐藏），而不是 display: none。
坑：忽略了 AI 生成内容的动态性
- 现象：ChatGPT 式的流式输出，屏幕阅读器完全沉默，或者每出一个字就读一次，吵死人。
- 对策：合理使用 aria-live，例如 aria-live=polite。对于 AI 正在生成的状态，提示正在生成；生成完毕后，确保焦点可以轻松移动到新内容上。

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

第 06 章 UI 设计 (Generative UI)：
- 在讲解 AI 生成 UI 时，强调 Design Tokens 必须内置 WCAG 对比度检查算法。AI 生成的配色方案如果对比度不达标，应被视为编译错误。
- 引入默认可访问的理念：AI 生成的组件库应默认包含 ARIA 标签和键盘支持，而不是作为后期补丁。
第 08 章前端开发 (AI Coding)：
- 在 AI 编码工作流中加入 Accessibility Linter 环节。AI 写的代码往往喜欢堆砌 div，需要通过 Prompt 工程或后处理脚本强制其使用语义化标签，例如 main、nav、article。
- 案例：如何让 AI 自动修复 alt 文本缺失问题（利用多模态模型理解图片内容并生成描述）。
第 11 章用户体验 (User)：
- AI 产品的包容性：AI Agent 的交互往往极其复杂，如何确保视障用户也能命令Agent？讨论 Voice UI 与 Chat UI 的无障碍优势（天然文本化）。
- 认知负荷管理：利用 WCAG 2.2 关于认知障碍的指导，设计 AI 的输出模式。不要一次性输出大段难懂的文本，利用 AI 进行易读性转换（Plain Language）。
第 20 章治理 (Governance)：
- 合规风险：随着《欧洲无障碍法案》(EAA) 2025 年生效，不合规的软件产品将面临法律风险。AI 辅助开发必须将 WCAG 2.2 AA 级作为发布门禁(Quality Gate) 的一部分。