WCAG 2.2

WCAG 2.2对生成的UI的变化

WCAG 2.2是在2.1的基础上添加了九个针对移动设备、低视力和行动能力需求的成功标准。它于2023年10月成为W3C推荐标准；在审计过程中，请保持规范文本开放（w3.org/TR/WCAG22）。对于发布AI生成组件的团队，最重要的添加是焦点不被遮挡（2.4.11）、拖动动作（2.5.7）、最小目标大小（2.5.8）、一致的帮助（3.2.6）、冗余输入（3.3.7）和可访问的身份验证（3.3.8）。大多数产品组织的目标是达到AA级。WAI的基本页面仍然解释了这些规则存在的原因，超出了“通过扫描器”的范围（WAI无障碍基础） 。

生成器在这里失败，因为它们优化了视觉密度和点击演示的抛光度。它们缩小了图标的点击区域，发明了只能拖动的看板，堆叠了粘性Chrome覆盖了焦点字段，并撒上不匹配行为的ARIA角色。下面的清单是按照发布日通过的顺序排列的：可衡量的项目首先，判断项目其次。

发布前一步一步的工作流程

- 冻结生成的分支。不要在测量时继续重新生成。 - 运行自动化的无障碍扫描（axe、Lighthouse或您的CI门）并记录每个对比度/缺失名称/无效ARIA命中。 - 按照WCAG 2.2快速参考过滤器的Level AA并将2.2仅的标准标记为票据中的显式行。 - 在每个主要用户旅程（注册、支付、核心任务）上进行键盘仅的通过。 - 在图标按钮和对话框上进行屏幕阅读器的点检查（Windows上的NVDA或macOS上的VoiceOver）。 - 记录残余风险：扫描器无法看到的内容、您推迟的内容以及谁拥有后续跟进。

A11yGuard是为可衡量的第一遍通过而构建的。法律合规性和判断调用仍然需要一个人类QA所有者。如果您的产品在招聘或类似决策流程中使用AI，请阅读美国关于算法和残疾歧视的指导方针，以便UI排除不会被视为一个美观bug（ADA.gov AI指导） 。

可以计算的对比度，无法计算的对比度

文本对比度是最容易被忽略的失败：正文文本需要与其背景的对比度为 4.5:1；大文本需要 3:1（标准 1.4.3）。生成的主题通常会带有灰色对灰色的设计或占位符渐变，这些设计会失败。需要测量渲染的背景，包括图像和叠加层。

非文本对比度（1.4.11）是双胞胎规则：UI 组件边界、图标和焦点指示器必须达到 3:1 的对比度与相邻的颜色。仅使用细边框绘制的按钮或设置为低不透明度轮廓的焦点环，即使标签文本通过，也会失败。图表和仪表盘 UI 也会遇到同样的问题；Smashing Magazine 记录了如何在不需要装饰噪音的情况下重新设计图表的视觉设计以满足无障碍标准（图表设计的无障碍标准）。

检查清单 — 对比度

- 正文 ≥ 4.5:1 在每个主题中（包括暗黑模式） - 大文本 / 大数字 ≥ 3:1 - 焦点环 ≥ 3:1 与其后面的表面相比 - 仅图标的可用性 ≥ 3:1 当图标携带意义时 - 不仅仅依赖颜色来表示错误或成功状态（与文本或图标配对）

WCAG 2.2 之后的目标大小和拖拽

目标大小最小（2.5.8）要求交互目标的最小大小为 24×24 CSS 像素，在 Level AA 中，除了内联链接和某些间距情况的有限例外。AI 布局通常会产生 16 像素的图标按钮，没有任何内边距。这现在是一个符合性问题，而不是一个品味问题。内边距、最小宽度/高度或可见图标周围的较大点击区域都可以计算在内，如果指针目标符合大小要求。

拖拽动作（2.5.7）意味着任何拖拽交互 — 滑块拇指、看板卡、范围滚动条 — 需要一个单指针的替代方案，例如箭头按钮、数字输入或点击设置。如果用户无法在不拖拽的情况下完成任务，则该模式不符合。生成器喜欢拖拽演示，因为它们在 GIF 中看起来很交互；在同一个 PR 中发布替代控制。

检查清单 — 指针访问

- 每个图标按钮的点击区域 ≥ 24×24 CSS 像素 - 相邻的目标有足够的间距或共享一个符合的例外 - 每个拖拽手势都有一个在 UI 中记录的非拖拽路径 - 触摸目标在操作系统文本大小增加时仍然有效

焦点顺序、粘性Chrome和2.4.11

焦点不被遮挡（最小）要求当控件接收键盘焦点时，不被作者创建的内容完全隐藏。粘性头部、底部导航栏、Cookie横幅和浮动的"AI帮助"小部件通常是vibe-coded应用中的常见罪魁。使用这些层打开时，按Tab键遍历页面。如果焦点字段位于72px粘性栏下，修复滚动填充或堆叠，而不是用户的视力。

还要确认2.4.7（焦点可见）：每个交互元素显示可见的焦点指示器。生成器通常会删除轮廓"以获得美观"。恢复满足1.4.11的高对比度环。

检查清单 — 焦点

- 链接、按钮、输入框、自定义小部件上的可见焦点 - 焦点顺序与主流程的阅读顺序匹配 - 模态框捕获焦点并在关闭时返回给调用者 - 粘性/固定UI永远不会完全覆盖焦点控件（2.4.11） - 跳过链接在内容丰富的页面上存在并且可用

ARIA：语义HTML优先，ARIA次之

生成器发明不匹配行为的ARIA角色，或将role="button"添加到已经是链接的元素。更喜欢本地元素：<button>、<a>、<nav>、<main>、表单控件。ARIA填补空白；它不替换语义。不匹配的角色会让屏幕阅读器感到困惑，并可能隐藏真实操作。将每个生成的aria-*属性视为需要验证的声明。

当您真正需要自定义小部件时，按照ARIA Authoring Practices Guide中的已发布模式进行操作，并检查角色/状态与WAI-ARIA 1.2。从聊天答案中复制粘贴角色字符串而不支持键盘是如何使"可访问"标记变成不可访问行为的。

生成的气味 | 操作 | WCAG / 实践钩子 <div onClick>作为CTA | 用<button>或<a href>替换 | 名称、角色、键盘 图标按钮、空名称 | 添加可见文本或稳定的aria-label | 4.1.2 名称、角色、值 仅拖动板 | 添加移动按钮或菜单 | 2.5.7 拖动运动 16px图标点击区域 | 填充至≥24×24 CSS像素 | 2.5.8 目标大小 焦点在粘性头部下 | scroll-padding / 堆叠修复 | 2.4.11 焦点不被遮挡 装饰性role="button"在链接上 | 删除角色；保留本地链接 | APG / ARIA 1.2

为什么自动化检查只能捕捉到部分问题

行业惯例和供应商文档通常将自动化覆盖范围限定在大约30-40%的真实世界的无障碍问题范围内。工具可以找到缺失的alt文本、许多对比度失败和无效的ARIA。但是，它们无法完全判断焦点顺序是否与阅读顺序匹配、是否存在拖拽替代方案，或者图标按钮的名称是否可理解。这就是为什么干净的Lighthouse评分不能作为WCAG 2.2符合性的证明。将自动化的第一步与键盘测试和生成的标记的手动审查相结合。

不要把单一的百分比当作法律；把它当作规划假设：扫描器是必要的但不充分的。每次发布时都要为判断层预算人工时间。

团队在使用AI UI时常犯的错误

- 在手动修复后重新生成而不锁定令牌或原语，从而导致对比度和名称消失 - 信任演示录制（仅鼠标）作为键盘路径有效的证据 - 堆叠ARIA以使lint器保持沉默，而不是修复元素类型 - 发布从未在实时DOM上测量的营销渐变 - 将CI绿色构建称为"符合"销售甲板——这种语言夸大其词

决定标准：现在的AA还是稍后的AA

大多数B2B应用的阻塞器在AA级别发布：

- 主要操作的无障碍名称为空 - 默认主题下正文文本小于4.5:1 - 无键盘路径通过结账或核心任务 - 焦点完全被粘性UI隐藏在必填字段上 - 只有拖拽的关键操作，没有替代方案

仅在有所有者和日期的情况下推迟：次要装饰动画、非关键图表（已经存在数据表替代方案）、不阻塞任务的帮助小部件抛光。推迟并不意味着被遗忘。

这不是什么

此检查清单不是完整的WCAG审计，不是VPAT，也不是法律建议。它不声称A11yGuard（或任何工具）保证符合标准、ADA合规性，或自动扫描“永远不会错过”问题。我们不发布虚构的客户指标或之前/之后的转换提升。该产品自动执行可衡量的第一遍；您仍然需要人工QA进行判断标准和用于客户或监管机构的签署语言。

结束

打印表格，冻结分支，运行扫描器，然后进行键盘和命名传递。保持规范的WCAG文本和快速参考打开，同时您争论边缘情况。当模型重新生成屏幕时，重新运行相同的列表——在vibe-coded应用程序中，访问性债务是一个循环，而不是一次性的项目。

参考

- WCAG 2.2 - WCAG 2.2 快速参考 - WAI 无障碍基础 - ARIA 编写实践指南（APG） - WAI-ARIA 1.2 - Smashing Magazine — 无障碍标准和图表设计 - ADA.gov — 人工智能和残疾歧视指南

相关文章

- 对比和ARIA在vibe-coded应用中的使用 - 探索完整的AI微SaaS主题矩阵 →