网页无障碍检查清单：工作中设计师的 WCAG 2.2 指南
按工作发生位置组织的 WCAG 2.2 无障碍检查清单：Figma、浏览器、上线后。附设计师常见错误与标准的对应图。
大多数网页无障碍检查清单对设计师来说毫无用处。它们按 WCAG 成功标准编号排列，这是律师阅读规范的方式，不是任何人开发软件的方式。
设计师打开 Figma 时不会想着标准 1.4.3。他们打开 Figma，然后选一个文字颜色。真正有用的检查清单应该在决策发生的地方等着设计师，也就是说要分三份独立的清单：一份用于设计文件，一份用于浏览器，一份用于上线之后。任何其他组织方式，都会被跳过。
WCAG 2.2 实际要求什么
WCAG 2.2 是截至 2026 年当前的全球标准，它在 WCAG 2.1 基础上增加了九项新的成功标准，主要关注移动端、触控目标、认知负荷和身份验证。
对设计师重要的九项新标准其实很简短。焦点外观要求更严格（2.4.11、2.4.13）。拖拽手势现在需要有非拖拽的替代方案（2.5.7）。触控目标最小尺寸为 24x24 CSS 像素，除非目标周围有足够间距（2.5.8）。各页面的帮助内容位置需保持一致（3.2.6）。表单不能不必要地重复询问相同信息（3.3.7）。身份验证不能依赖认知测试（如记住密码），除非有替代方案（3.3.8、3.3.9）。
AA 级是全球大多数无障碍法律的要求，包括欧盟《欧洲无障碍法案》、美国 Section 508 以及英国《公共部门机构无障碍法规》。AAA 级更严格，主要保留给政府、医疗和教育领域。
按 WCAG 章节编号排列的检查清单是规范。按工作发生位置排列的检查清单才是工具。
唯一有效的检查清单格式
无障碍性在三个地方被决定：设计文件、浏览器中构建的界面，以及上线后的生产站点。
大约 70% 的无障碍问题是在 Figma 中做出的决策导致的，20% 来自实现阶段，10% 在上线后通过内容变更、第三方嵌入或用户生成内容渗入。任何不对应这三个阶段的检查清单都是在强迫设计师把规范语言翻译成工作流程语言，而翻译这一步正是条目被遗漏的地方。
本文余下内容就是这三份清单，按顺序排列。按顺序执行。设计阶段检查未通过的内容，不应进入构建阶段。构建阶段未通过的内容，不应上线。
设计阶段检查清单（在 Figma 中检查的内容）
大约 70% 的无障碍问题源于设计文件中的决策，这也意味着在那里修复成本最低。
| 检查项 | WCAG 2.2 标准 | 在 Figma 中如何验证 |
|---|---|---|
| 正文文字与背景的对比度达到 4.5:1 | 1.4.3 Contrast (Minimum) | Stark、Able 或 Figma 内置对比度检查器 |
| 大文字（18pt+ 或 14pt+ 粗体）达到 3:1 | 1.4.3 | 同上 |
| 非文字 UI（按钮、边框、图标、焦点环）达到 3:1 | 1.4.11 Non-text Contrast | 在画布上手动取色对比 |
| 触控目标至少 24x24 CSS px（推荐 48x48） | 2.5.8 Target Size (Minimum) | 直接测量框架尺寸 |
| 信息不仅靠颜色传达 | 1.4.1 Use of Color | 将框架转为灰度（Figma 插件或截图滤镜） |
| 每个图片框架在图层元数据中有 alt 文字 | 1.1.1 Non-text Content | Figma 无障碍面板或开发模式 |
| 标题按逻辑顺序使用（H1、H2、H3，而非 H1、H3、H2） | 1.3.1 Info and Relationships | 从上到下阅读标题树 |
| 每个交互元素都设计了焦点状态 | 2.4.7 Focus Visible、2.4.11 Focus Not Obscured | 每个交互组件都有焦点变体 |
| 链接文字脱离上下文也能理解 | 2.4.4 Link Purpose | 没有"点击此处"或"了解更多"之类的标签 |
| 表单标签可见，而非仅用占位符 | 3.3.2 Labels or Instructions | 每个字段在输入框外都有持续可见的标签 |
设计文件也是捕捉新 WCAG 2.2 移动端标准的地方。触控目标未通过 2.5.8 的情况，几乎总是因为设计师按桌面像素思考，目标是一个没有内边距的 16 像素图标。
关于对比度的深入探讨，请参见对比度规则与 APCA。设计阶段的色彩工作，是大多数网站在写下第一行代码之前就已经输掉审计的地方。
构建阶段检查清单（在浏览器中检查的内容）
浏览器是无障碍决策得到验证或暴露的地方，因为这是真实辅助技术第一次接触你作品的地方。
| 检查项 | WCAG 2.2 标准 | 在浏览器中如何验证 |
|---|---|---|
| 每个页面仅用键盘即可操作（Tab、Shift+Tab、Enter、空格键、方向键） | 2.1.1 Keyboard | 拔掉鼠标，用键盘导航页面 |
| 焦点顺序与视觉顺序一致（LTR 布局中从左到右、从上到下） | 2.4.3 Focus Order | 按 Tab 键并观察焦点环 |
| 焦点不会被固定头部、Cookie 横幅或弹窗遮挡 | 2.4.11 Focus Not Obscured (Minimum) | 按 Tab 键同时滚动页面，确认可见性 |
| 拖拽交互有点击或轻触的替代方式 | 2.5.7 Dragging Movements | 检查滑块、可排序列表、轮播图 |
| 跳转到内容的链接在第一次 Tab 时出现 | 2.4.1 Bypass Blocks | 页面加载后按一次 Tab 键 |
| 使用了 HTML 地标（header、nav、main、footer、aside） | 1.3.1、4.1.2 | 检查 DOM 大纲 |
| 表单错误通过语音播报，而非仅靠颜色区分 | 3.3.1、3.3.3、4.1.3 | 用屏幕阅读器提交错误的表单 |
| 屏幕阅读器正确播报标题、列表和按钮 | 4.1.2 Name, Role, Value | Windows 用 NVDA，Mac 用 VoiceOver，Android 用 TalkBack |
| 个人数据字段设置了 autocomplete 属性 | 1.3.5 Identify Input Purpose | 检查姓名、邮箱、地址字段的 autocomplete |
| 媒体有字幕、文字稿或音频描述 | 1.2.1 至 1.2.5 | 播放每个视频，检查轨道 |
自动化工具大约能捕捉其中 30%。其余的需要人工按 Tab 键并倾听屏幕阅读器。两者都重要，谁也不能替代谁。
2026 年最佳浏览器阶段工具组合很精简：axe DevTools 用于自动扫描，Lighthouse 用于页面级审计，再加一个真实的屏幕阅读器用于人工检查。三个工具，每页十分钟，几乎能捕捉真实审计会标记的一切。
上线后检查清单（在生产环境中检查的内容）
无障碍性不会随着上线而结束，因为内容、第三方嵌入和用户生成内容都会在设计师签字后才上线。
| 检查项 | WCAG 2.2 标准 | 在生产环境中如何验证 |
|---|---|---|
| CMS 编写的图片在编辑器层面强制要求 alt 文字 | 1.1.1 | 测试 CMS：作者能否在不填 alt 的情况下发布？ |
| 嵌入的第三方组件（聊天、地图、表单）可无障碍访问 | 不定 | 在含嵌入内容的页面上运行 axe |
| PDF 下载和文档已标记且可读 | 1.1.1、1.3.1、2.4.6 | 在 Acrobat 的无障碍检查器中打开 |
| 帮助、支持和联系链接在每个页面的位置一致 | 3.2.6 Consistent Help（WCAG 2.2 新增） | 跨模板进行视觉审计 |
| 表单在流程中不重复询问冗余信息 | 3.3.7 Redundant Entry（WCAG 2.2 新增） | 逐步完成多步骤表单 |
| 身份验证有无障碍替代方式（通行密钥、邮件链接、SSO） | 3.3.8、3.3.9 Accessible Authentication（WCAG 2.2 新增） | 在禁用密码管理器的情况下尝试注册和登录 |
| 动态内容（弹窗、提示、实时区域）有语音播报 | 4.1.3 Status Messages | 在开启屏幕阅读器的情况下逐一触发 |
| 用户将页面缩放至 200% 后，对比度和目标尺寸规则仍满足 | 1.4.4 Resize Text、1.4.10 Reflow | 将浏览器缩放至 200% 并检查 |
| 没有自动播放的媒体，或媒体有暂停控件 | 1.4.2 Audio Control、2.2.2 Pause, Stop, Hide | 冷加载页面 |
| Cookie 横幅不会困住键盘焦点 | 2.1.2 No Keyboard Trap | Tab 进入横幅，再 Tab 出来 |
上线后的清单是大多数团队失败的地方。设计是无障碍发布的。然后 CMS 作者往里塞未标记的 PDF、自动播放视频，还有一个启动按钮对比度只有 2:1 的聊天组件。无障碍性是一个系统属性，不是一个上线里程碑。
需要一个无需三个月整改周期就能通过 WCAG 2.2 的网站？Brainy 从第一个 Figma 框架开始就以无障碍设计为出发点。
设计师常见错误与 WCAG 标准的对应
每一个无障碍审计发现都能追溯到特定的 WCAG 成功标准，而大多数设计师都在对着相同的五个标准犯相同的五个错误。
| 设计师错误 | 实际问题 | 违反的 WCAG 2.2 标准 |
|---|---|---|
| 仅用占位符文字作为标签 | 用户一开始输入就失去了标签 | 3.3.2 Labels or Instructions |
| 仅图标的按钮，没有 aria-label 或提示 | 屏幕阅读器播报"按钮"但没有任何用途说明 | 4.1.2 Name, Role, Value |
| 错误信息仅靠红色边框或红色文字显示 | 色盲用户看不到错误 | 1.4.1 Use of Color、3.3.1 Error Identification |
| 为美观而移除焦点环 | 键盘用户看不到自己在哪里 | 2.4.7 Focus Visible |
| 触控目标小于 24x24 px 且无间距 | 移动用户频繁误触 | 2.5.8 Target Size (Minimum) |
| "低调"UI 对比度不足（占位符文字、禁用状态、辅助说明文字） | 在阳光下或视力受损的读者无法阅读 | 1.4.3 Contrast (Minimum)、1.4.11 Non-text Contrast |
| 弹窗困住焦点但无 ESC 关闭 | 键盘用户被困在弹窗内 | 2.1.2 No Keyboard Trap |
| 轮播图仅支持拖拽导航 | 运动障碍用户无法切换 | 2.5.7 Dragging Movements |
| 固定头部在 Tab 时遮住焦点元素 | 用户看到页面滚动，但失去了对当前位置的追踪 | 2.4.11 Focus Not Obscured |
| 仅用密码登录，没有 SSO 或邮件链接 | 认知负荷失败 | 3.3.8 Accessible Authentication |
这相同的十个错误构成了每份审计报告的绝大部分内容。修复这些问题，在任何顾问打开电子表格之前，你就已经完成了 WCAG 2.2 AA 的 80%。
无障碍基础也与良好的视觉层级紧密相连。对比度、目标尺寸和焦点状态都是层级决策。一个把层级做好的设计，默认就完成了无障碍检查清单的大部分，这就是为什么良好的色彩理论与无障碍设计之间的重叠几乎是完全的。
如何在不耗尽一周时间的情况下执行检查清单
检查清单只有在执行时间以分钟计而非以天计的情况下才有用，这意味着工具必须承担大部分工作。
工作节奏是三轮检查，每个阶段一轮，每轮在工作到达该阶段时执行。不是全部在最后做。不是其中一个在最后做。三轮独立的检查，每轮成本低廉，尽可能通过工具强制执行。
- 设计轮：每个页面 10 分钟。 对每组文字使用 Stark 或 Figma 的对比度检查器，将框架转为灰度测试仅靠颜色传达的信息，测量每个触控目标。在交接前执行，而非在评审时。
- 构建轮：每个模板 10 分钟。 axe DevTools 扫描、仅键盘导航测试，对访问量最大的页面进行一次屏幕阅读器检查。将 axe-core 集成到 CI，确保新代码无法在有回归问题的情况下合并。
- 上线轮：每月一次，而非每次发布。 在生产环境对全站运行 axe 或 pa11y 爬取，对文档库进行 PDF 审计，手动逐步完成表单和身份验证流程。
每个产品每月半天工作量，每次设计交接大约 15 分钟。超过这个量，团队就会停止执行。低于这个量，审计结果就会带着问题回来。
FAQ
WCAG 2.2 是法律要求吗？
在大多数主要市场，是的。《欧洲无障碍法案》于 2025 年 6 月生效，最低引用 WCAG 2.1，2.2 是当前的工作标准。美国 Section 508 引用 WCAG 2.0，但采购合同越来越多地要求 2.2。加拿大、英国、澳大利亚和日本都有类似要求，与 WCAG 2.1 或 2.2 挂钩。如果你向这些市场发布产品，2.2 AA 是安全目标。
我实际上需要了解哪些新的 WCAG 2.2 标准？
对设计师最重要的有四项。2.5.7 Dragging Movements 要求拖拽交互必须有非拖拽的替代方式。2.5.8 Target Size (Minimum) 要求触控目标至少 24x24 CSS 像素，且有足够间距。2.4.11 Focus Not Obscured 要求焦点元素在滚动和固定覆盖层出现时仍保持可见。3.3.8 Accessible Authentication 禁止在没有替代方案（SSO、通行密钥或邮件链接）的情况下依赖认知测试，如记住密码。
我需要为移动端准备单独的检查清单吗？
不需要。WCAG 2.2 明确涵盖移动端和触控，这就是为什么其许多新标准（目标尺寸、拖拽、焦点）都具备移动端意识。同一份三阶段检查清单适用于移动端 Web 和响应式设计。原生应用有额外的平台特定指南（Apple 的 HIG 和 Android Accessibility），但 WCAG 规则同样适用。
WCAG 2.2 中触控目标的最小尺寸是多少？
2.5.8 Target Size (Minimum) 规定最小尺寸为 24x24 CSS 像素，但如果目标周围有足够间距或与文字内联，则有例外。大多数设计师实际应该瞄准的目标是 48x48 CSS 像素，这与 Apple 和 Google 的平台建议一致，也能避免 WCAG 规范中的边界情况。
执行清单，而非靠猜
无障碍性不是合规任务。它是一个设计属性，在三个时刻构建，由工具强制执行，由人工检查。
那些无痛发布无障碍网站的团队，不是拥有最好审计师的团队。而是把检查移入设计阶段、构建阶段和上线阶段的团队，他们拒绝让任何一个阶段带着已知问题向前推进。
执行这三份清单。在十个常见错误叠加之前发现并修复它们。将浏览器阶段扫描自动化集成到 CI。每月审计上线后的漂移。WCAG 2.2 AA 就不再是一条终点线，而会成为团队工作方式的一个属性。
今天就选择你网站上的一个产品界面。对其 Figma 文件执行设计阶段检查清单。数一数需要修复的问题数量。那个数字，就是你没有早点执行这份清单的代价。
执行清单，而非靠猜。
需要一个无需三个月整改周期就能通过 WCAG 2.2 的网站？Brainy 从第一个 Figma 框架开始就以无障碍设计为出发点。
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
