当无障碍显得过于庞大时，该从何入手

首先要明白的一点：你不必一次性把所有问题都解决

当各家机构第一次接触到 WCAG 2.2 时，往往会既真切地感到担忧，又不知所措。三个符合等级之下共有 78 条成功准则。配套的技术文档卷帙浩繁。自动化扫描会生成数百个问题的清单。让人感觉必须暂停一切、投入数月的开发时间，才敢开始考虑称自己的网站是无障碍的。

这种感受可以理解，却具有误导性。无障碍改进并不是一种非此即彼的状态——要么无障碍，要么不无障碍。它是一个连续的谱系，无论你现在处于何种状况，都有可能取得有意义的进展，哪怕你现在的状况是”我们以前从没考虑过这件事”。

这份指南的目标，就是帮助你迈出第一步。

为什么感到不知所措很正常

网页无障碍之所以让人觉得庞大，是因为它确实庞大。WCAG 涵盖视觉呈现（对比度、文本大小、间距）、听觉内容（字幕、文字稿）、交互（键盘导航、时限、动效）、语义（结构、标签、角色）以及认知考量（语言、一致性、错误补救）。它适用于桌面端、移动端和辅助技术。它涉及设计、内容、开发和测试。

但有一点改变了整个局面：大多数无障碍问题都集中在少数几种模式上。年复一年，WebAIM Million 报告（分析访问量排名前一百万的网站）都发现，同样的六个问题占了可自动检测的 WCAG 问题中的绝大多数：

1. 色彩对比度低
2. 图片缺少替代文本
3. 缺少表单输入框标签
4. 空链接（没有文本的链接）
5. 缺少文档语言
6. 空按钮（没有文本的按钮）

仅这六种模式，就出现在超过 95% 被测试的首页上。在你的网站上修复它们并不能让你完全无障碍，但它能消除那些影响最多残障用户的障碍。这是一个有意义的起点。

第 1 步：了解你当前的处境

在你能够为修复排定优先级之前，你需要知道自己所处的状况。一次免费的自动化扫描能在几分钟内让你了解这一点。

自动化工具并不是一套完整的无障碍解决方案——它们可靠地捕捉到的只有 WCAG 问题的 30–40%，因为大多数障碍需要人工判断才能发现。但它们非常擅长找出上面列出的那些常见、可自动检测的问题：对比度、缺失的替代文本、未标注的输入框，以及类似的结构性问题。

对你的网站进行一次免费扫描。看看返回的结果。被标记出的问题是真实存在的——对于那些常见模式而言，它们不会是误报——而它们就是一份具体的起始清单。

第 2 步：按影响排定优先级，而非按完整度

一旦你有了一份清单，就会忍不住想按顺序处理每一项。请克制这种冲动。相反，要按影响和频率的组合来排定优先级：

影响最大（优先修复）：

• 结账、注册或主要转化流程中的任何障碍——如果用户无法完成交易，那么这个无障碍问题正在让你损失生意
• 登录和身份验证障碍——无法登入的用户什么都用不了
• 导航——如果用户找不到页面，页面层面的无障碍就无关紧要了

影响较大（其次修复）：

• 核心内容页面：产品页面、信息页面，以及用户专门为获取内容而访问的页面
• 表单字段及其标签和错误信息——表单正是交互发生的地方
• 对比度问题——它们影响非常庞大的人群，而且通常是很直接的修复

重要但紧迫性较低（稍后修复）：

• 访问量低的存档内容和较旧的页面
• 边缘情况的交互，以及影响较小人群的 WCAG 准则
• AAA 级要求（它超出了法律标准）

在你访问量最高、转化率最高的页面变得无障碍之前，你并不需要先取得满分。先把那些页面做对。

第 3 步：为自动化遗漏之处补上人工测试

一旦你的自动化问题得到控制，下一层就是人工测试。这里正是你会发现以下问题的地方：

• 键盘导航问题——用户能否在不用鼠标的情况下用 Tab 键遍历你的整个网站？
• 焦点管理问题——模态框打开后，焦点是否移入了模态框？它关闭后，焦点是否返回了？
• 屏幕阅读器行为——你的自定义下拉菜单会朗读它的状态吗？你的轮播图会传达当前是哪一张幻灯片处于激活状态吗？
• 合乎逻辑的阅读顺序——如果你去掉 CSS，页面是否仍然说得通？

开始人工测试最快的方式是：

1. 拔掉鼠标，尝试仅用键盘（Tab、Shift+Tab、Enter、Space、Escape、方向键）完成你网站的主要用户旅程。记下所有出问题的地方。

2. 下载一款免费的屏幕阅读器（Windows 上的 NVDA 是免费的；VoiceOver 内置于 Mac 和 iOS 中）。浏览你最重要的页面。倾听被朗读出来的内容。它连贯吗？

3. 使用浏览器的无障碍工具——Chrome 和 Firefox 都有无障碍检查器，能为每一个元素展示无障碍树、ARIA 角色以及计算出的可访问名称。

这些测试需要花时间学习，但不花一分钱，而且它们会找出任何自动化工具都发现不了的问题。

第 4 步：把它融入你的工作流程

做无障碍最昂贵的方式，就是把它当作一次性的修复工作——修好网站、宣告胜利，然后眼睁睁看着新的障碍随着每一次新功能发布而不断累积。

可持续的无障碍意味着改变你的工作方式：

• 设计评审——设计是否满足对比度要求？交互状态是否可见？
• 开发——在可能的地方是否使用了原生 HTML 元素？表单字段是否有标签？自定义组件是否具有正确的 ARIA？
• 内容——每张图片是否都有恰当的替代文本？链接是否具有描述性？
• 测试——CI 是否会在无障碍回归时中断构建？在重大发布前是否有一个人工测试环节？

我们关于软件开发生命周期中的无障碍的指南，更深入地探讨了这在实践中是什么样子。我们的 CI/CD 集成服务让自动化这一层成为每次构建的一部分。

设定切合实际的期望

对于一个从未做过无障碍评审的网站而言，让每一个页面都达到 WCAG 2.1 AA 级符合，通常是一个历时数月的项目——对于庞大、复杂、有大量遗留代码的网站来说则更久。

这并不意味着你在接下来的两周里无法取得有意义的进展。修复我上面列出的六个最常见问题，就能让你的网站对一大批人群实质上更加无障碍，即便这还不足以让你在法律上合规。

我觉得最有用的思路是：以持续改进为目标，而不是把合规当作终点。每个冲刺周期，都解决一批已识别出的问题。在新功能上线前对它们运行自动化检查。每季度安排一次人工测试。制定一份能诚实反映你当前状况和路线图的无障碍声明。

以这种方式对待无障碍的机构，往往比那些一直等到能为一个完整的整改项目配齐资源才动手的机构，取得更快的整体进展。

今天从哪里开始

如果你还什么都没做：进行一次免费扫描。你会在两分钟内得到一份真实问题的真实清单，并按严重程度排好序。那就是你的起点。

如果你已经做过扫描，但还没进入人工测试：今天就在你的结账流程上试试仅用键盘的测试。如果你发现了障碍，你就找到了下一个优先事项。

如果你正在做人工测试，但还没把它整合进工作流程：阅读我们关于开发流程中的无障碍的指南，并在你当前的工作流程中找出一个可以加入无障碍检查的环节。

进步胜过完美。从某处开始吧。