如何让网站符合 WCAG 2.2：分步指南

让你的网站符合 WCAG 2.2 是一个过程，而非一次性的修复。合规是一套可重复工作流程的结果：理解标准、衡量现状、按正确顺序修复正确的问题、用真实的辅助技术和真实用户进行验证、记录结果，并防止其退化。本指南将这套工作流程转化为一份具体的、分步的路线图，你的团队今天就可以开始使用——而无需求助于无障碍“覆盖层（overlay）”，它们只是在 DOM 中掩盖问题而非修复问题，并且屡次被列入诉讼案件。

第 1 步：理解 WCAG 2.2 究竟要求什么

在审计任何东西之前，先明确目标。Web 内容无障碍指南围绕四项原则组织，用首字母缩略词 POUR 概括：

Perceivable（可感知）——用户必须能够感知内容。想想图像的文本替代、媒体的字幕和文字稿，以及足够的颜色对比度。
Operable（可操作）——每项功能都必须无需鼠标即可使用。完整的键盘可操作性、可见的焦点指示器以及无键盘陷阱是核心要求。
Understandable（可理解）——内容和行为必须可预测。清晰的标签、一致的导航、有帮助的错误信息以及可读的语言都属于这里。
Robust（健壮）——标记必须能被当前和未来的辅助技术解析，这在实践中意味着有效的 HTML 以及正确使用 ARIA 的名称、角色和值。

每项原则都分解为可测试的成功标准，每条标准都被赋予一个符合性级别：A（基本）、AA（多数组织所追求的法律与实践基线）以及 AAA（增强）。当人们说 “WCAG 2.2 AA” 时，指的是符合每一条 A 级和 AA 级成功标准。WCAG 2.2 相比 2.1 新增了九条标准——包括焦点不被遮挡、拖动手势、目标尺寸（最小）以及无障碍身份验证——其中大多数都改善了键盘用户、低视力用户和运动障碍用户的体验。

了解为何这是目标会有所帮助。AA 符合性正是那些最可能适用于你的法律法规所引用的：先阅读关于作为技术标准的 WCAG 合规，然后看看它如何对应到 European Accessibility Act、适用于美国私营和公共实体的 ADA，以及适用于美国联邦机构及其供应商的 Section 508。如果术语在途中让你犯难，请在标签页中打开我们的无障碍术语表。

还有两个概念塑造着任何诚实的符合性声明。第一个是符合性范围：WCAG 符合性适用于完整页面，而非孤立组件，也适用于完整流程（例如整个结账流程）——如果某个多步骤任务中的一步失败，你就不能声称该页面符合标准。第二个是无障碍支持的技术：你只能依赖那些被你的用户所使用的辅助技术真正支持的功能使用方式。在实践中，这意味着用当前的屏幕阅读器和浏览器进行测试，而不是假设仅凭有效的标记就能保证可用的结果。在下文各步骤中确定工作范围时，请将两者牢记于心；它们决定了你能站得住脚地宣称已经实现了什么。

第 2 步：运行一次自动化基线扫描

无法衡量的东西就无法修复，所以先建立一条基线。自动化测试快速、可重复，并且擅长捕捉困扰大多数网站的那些大批量、机械性的缺陷：缺失的替代文本、低颜色对比度、空的链接和按钮、未加标签的表单字段、缺失的文档语言以及重复的 ID。

基于开源 axe-core 引擎构建的工具——包括 QualiBooth 的无障碍扫描软件——能在几分钟内生成一份按优先级排序的问题清单。如果你只想快速了解自己所处的状况，可以先对几个关键页面进行一次免费无障碍扫描。

让基线保持诚实的几条规则：

扫描有代表性的模板，而非整个网站。 测试你的首页、一个内容/文章模板、一个产品或类别页面、一个表单（注册、结账、联系）以及任何需要登录的仪表板。修复一个模板通常能修复数百个页面。
测试真实状态，而不仅是初始加载。 打开菜单、展开折叠面板、触发模态框，并提交带错误的表单。许多违规只在交互状态下才会出现。
记录数字。 按严重程度和按成功标准记录问题数量。这是你的前后对比基准，也是你修复待办事项的基础。

对上限要诚实：自动化工具只能可靠地检测到 30–40% 的 WCAG 问题。一次干净的自动扫描是必要的，但对于真正的符合性声明而言，它从来都不充分。

第 3 步：用人工审计补充自动化

剩下的 60–70% 的 WCAG 标准需要人的判断。这段替代文本是否真正传达了图像的含义，还是只是在描述像素？阅读和焦点顺序是否合乎逻辑？错误信息是否告诉用户如何恢复？自定义下拉菜单是否被正确播报，你能否仅用键盘到达并操作它？没有任何引擎能可靠地回答这些问题。

一次结构化的人工审计通常涵盖：

纯键盘操作——用 Tab 键遍历每个交互元素；确认有可见的焦点指示器、合乎逻辑的顺序、无陷阱，并且凡是能用鼠标做的，不用鼠标也能做。
语义结构——标题处于有意义的层级中，地标（landmark），列表标记为列表，表格带有正确的表头。
表单——程序化的标签、分组的字段、清晰的必填项指示，以及与其所描述的输入项相关联的错误信息。
动态内容——能正确捕获并恢复焦点的模态框、能播报更新的实时区域（live region），以及仅在原生 HTML 无法胜任时才使用的 ARIA。
内容质量——有意义的链接文本、真实情境中足够的对比度，以及不单纯依赖颜色或形状的内容。

我们的人工无障碍审计指南详细讲解了完整方法论，而应避免的常见无障碍问题则是一份关于审计人员最常发现的缺陷的快速清单。如果你更愿意让别人替你完成，QualiBooth 的无障碍咨询团队会依据 WCAG 2.2 AA 标准执行专业的人工审计。

第 4 步：排定优先级并修复

一长串违规会让人不知所措，直到你为它排好顺序。通过结合用户影响和覆盖面进行分诊：

阻断性问题优先。 任何使某一群用户无法完成某项任务的问题——键盘陷阱、无法使用的结账流程、未加标签的登录表单——无论存在多少个实例，都排在最前。
其次是高频的、全站性的问题。 页眉、页脚或设计系统组件中的对比度或焦点问题会在每个页面上成倍出现。修复一次就能带来最大的回报。
再次是页面特定的和内容方面的问题。 单个缺失的替代文本、单个标签错误的控件，或一处一次性的标题断层。

修复时，要修复源头，而非症状。优先使用原生 HTML 元素，而非用 ARIA 打补丁的 <div>；修正设计系统组件，而非使用它的每个页面；并在模板和共享组件中解决根本原因，使修复能够规模化。每完成一批后重新扫描，以便看到数量下降并避免引入回归。这也是把无障碍融入设计令牌（design token）的恰当时机——将对比安全的颜色、24×24 px 的最小目标尺寸以及可见的焦点样式设为默认值，让新工作从一开始就合规。

有几种修复模式反复出现，频繁到值得明确指出：

善用平台。 原生的 <button>、<a href>、<input>、<select> 和 <dialog> 自带键盘行为、焦点管理以及正确的无障碍名称，无需额外成本。仅在填补真正的空缺时才动用 ARIA——并记住 ARIA 的第一条规则：如果原生元素可用，就不要使用 ARIA。
以程序化方式命名。 每个控件都需要来自 <label>、aria-label 或 aria-labelledby 的无障碍名称——而不只是附近的视觉文本。仅有图标的按钮是最常见的违规者。
有意识地管理焦点。 当模态框打开时，将焦点移入其中，在其打开期间将焦点困在内部，并在关闭时将焦点返回触发元素。当内容在没有导航的情况下更新时，使用实时区域，让屏幕阅读器用户听到发生了什么变化。
不要仅用颜色或形状来编码含义。 将颜色与文本、图标或图案搭配使用，使信息对色盲和低视力用户依然有效。

在你日常的问题跟踪器中跟踪修复，并按成功标准打标签，这样无障碍工作就能与其他一切并列可见，而不是存在于一份会过时的独立电子表格中。

第 5 步：与辅助技术和残障人士一起测试

合规归根结底在于真实的人能否使用你的网站。这里有两层验证很重要，而且它们不可互换。

屏幕阅读器测试。 用人们实际使用的辅助技术来验证你的修复：Windows 上搭配 Chrome/Firefox 的 NVDA 或 JAWS，以及 macOS 和 iOS 上搭配 Safari 的 VoiceOver。留意名称是否准确、角色是否正确、状态变化是否被播报，以及阅读顺序是否合理。如果你的团队缺乏经验，一次屏幕阅读器评估能为你提供一次涵盖主要组合的专业检查。

与残障用户进行的可用性测试。 满足每一条成功标准是底线，而非上限——一个网站可能在技术上合规，却仍然令人沮丧难用。最可靠的信号来自残障人士进行的审计，他们用自己的辅助技术和习惯进行测试，并揭示出清单会遗漏的障碍。这正是符合标准字面要求与提供真正的数字无障碍之间的区别。

第 6 步：记录符合性（声明与 VPAT/ACR）

一旦完成修复和验证，就记录结果。文档正是把“我们努力过了”转化为站得住脚、可传达的声明的东西。

无障碍声明。 一个公开页面，说明你的符合性目标（例如 WCAG 2.2 AA）、描述你所做的工作、列出任何已知限制，并为用户提供一种报告问题的途径。许多法规（包括 EAA）都期望有这样一个页面。
VPAT / Accessibility Conformance Report。 一份填写完成的 Voluntary Product Accessibility Template 会成为 ACR——采购团队和企业买家作为证据所要求的标准文件。我们的什么是 VPAT/ACR 指南解释了该文档，而 VPAT 报告服务会生成一份准确的、有审计支撑的报告，供你交付给客户和法务团队。

撰写这些文件时，要依据你实际审计结果的证据，而非愿景。一份夸大符合性的 VPAT 是一项负债，而非资产。

第 7 步：随时间维持合规

网站一发生变化，无障碍就会退化——一个新组件、一个重新设计的表单、一个第三方小部件或一次内容编辑，都可能悄无声息地重新引入障碍。合规是你要维持的一种状态，而不是只需通过一次的里程碑。

把无障碍融入你的软件生命周期：

左移（Shift left）。 通过 CI/CD 无障碍集成为你的流水线添加自动化检查，使违规在拉取请求（pull request）时、在发布之前就被捕获——这是修复成本最低的地方。
监测生产环境。 安排周期性无障碍审计，以捕捉发布前检查无法发现的回归和内容漂移。
赋能你的团队。 为设计师、开发者和内容作者配备无障碍工具包和共享标准，让无障碍成为每个人的默认习惯，而不是专家的事后补救。
大规模治理。 对于大型或多站点组织，像 Agora 这样的平台能在各团队间集中管理跟踪、报告与修复。

让合规努力脱轨的错误

陷入停滞的团队通常都是出于可预见的原因。当心这些：

只信任自动化。 一份全绿的自动化报告只覆盖三分之一的标准。把它当作符合性的证明，是最常见——也是法律风险最高——的错误。
购买覆盖层。 覆盖层和“无障碍小部件”承诺通过注入覆盖页面的 JavaScript 实现即时合规。它们并不修复底层代码，常常干扰用户自己的辅助技术，并且已被越来越多的投诉点名。它们是通往风险的捷径，而非通往合规的捷径。
修复页面而非系统。 修复单个页面却让设计系统保持破损，意味着每个新页面都会重新引入相同的缺陷。先修复共享组件和模板。
把它当作一次性项目。 没有 CI/CD 检查和周期性审计，一个合规的网站会在几个发布周期内偏离符合性。
跳过真实用户。 没有可用性测试的技术合规，仍可能让残障用户无法完成核心任务。

避免这些错误，能防止你的投入在项目“上线”那一刻就白白流失。

把一切整合起来

通往 WCAG 2.2 AA 的现实路径是这样的：学习 POUR 原则和 AA 目标，运行自动化基线扫描，叠加一次人工审计，按影响和覆盖面进行修复，与屏幕阅读器和残障用户一起验证，在声明和 VPAT 中记录你的符合性，然后用 CI/CD 检查和周期性审计保持其健康。每一步都在前一步的基础上累加——而其中没有任何一步依赖于一个掩盖真实代码的覆盖层。

从小处着手，积累势头：本周扫描少数几个模板，修复你设计系统的对比度和焦点样式，并在流水线中加入一项自动化检查。从那里开始，上面的路线图会带你走完剩下的路。当你准备好加速时，可以了解我们的定价、申请演示，或就一份针对你技术栈量身定制的修复计划与专家交流。