WCAG（Web Content Accessibility Guidelines，网页内容无障碍指南）是一套由 W3C（World Wide Web Consortium，万维网联盟）旗下 WAI（Web Accessibility Initiative，Web 无障碍倡议）发布的国际通用无障碍标准。它回答的核心问题很朴素：网页与数字内容，怎样才能让更多残障用户（也包括临时受限的普通用户）顺利感知、理解与操作。
很多设计师第一次听到 WCAG，会下意识把它当成一门额外的学问。可你只要把视线从设计稿移到真实世界，就会发现它更像一条地基线，决定了产品到底能不能被用户顺利使用。
这是因为数字产品的可用性不是一个开关。你在办公室里用鼠标很顺利的访问网页，但它不代表所有人都能顺利的使用它。可用性更像一组条件，用户想完成一个任务，至少要经历三步。
- 用户得先拿到信息，看得见也好，听得清也好，总之信息得进来。
- 用户要完成操作，点选、输入、滑动、确认，动作要能做得出来。
- 用户要理解过程，知道当前发生了什么，下一步该做什么，错了要怎么改。
只要这三步里任何一步断掉，任务就会失败。断裂也不只发生在少数人身上。视力、听力、肢体动作、认知与语言能力的差异会放大断裂，同时普通用户也会在某些时刻面临暂时的受限。比如强光下看不清屏幕，地铁里听不见提示音，单手抱着孩子难以完成精细操作，网络卡顿导致反馈延迟。种种情况都会让一个原本顺畅的流程变得困难。
所以行业需要一套通用规则，让人在不同环境、用不同方式访问界面时，依然能把任务走完。更重要的是，这套规则不能停留在倡议，它必须能落地。设计与开发知道怎么做，测试与验收也能依据这套规则判断可用性是否达标。
WCAG 就是在这样的背景下被提出的。它是一套面向网页与数字内容的无障碍指南。它的语言确实偏工程化，但目的很明确，让可用性覆盖更多人，并且可以被检查、被验收。
1. POUR
无障碍牵涉的设计细节非常多。你只要随手列一列，就能发现它几乎覆盖了界面里的每一种信息与交互方式。文字怎么呈现，颜色怎么区分，图片怎么说明，声音提示是否有替代，键盘能不能走通，弹窗打开后焦点落在哪里，表单报错怎么表达，动效会不会让人不适，读屏读出来的文字顺序是否合理。任何一个点掰开揉碎，都无穷无尽需要写的内容。
WCAG 没有从这些零散问题入手。而是先问了一个更基础的问题：用户为什么会在任务里走不下去？
因为不管页面长什么样，用户完成任务的过程都是固定的。用户首先需要先得获取信息，然后才能操作，操作之后还得理解反馈，最后还要依赖正确的语义与结构，才能让辅助技术顺利解析。如果其中某一步断掉，流程就会中断。
所以 WCAG 先把这些中断按归因分成四类，并把它们写成四条最重要的原则—— POUR。POUR 是四个英文词的首字母缩写，对应四条原则：
- 可感知 （Perceivable）
- 可操作 （Operable）
- 可理解 （Understandable）
- 强健性 （Robust）
这四条原则是 WCAG 整套标准的规则总纲，相当于目录的第一层。后面更具体的要求和条款，都是围绕这四个方向展开的。
2. 四原则浅析
关于 WCAG 的四个原则，其实有许多内容可讲。这里我只做一层浅析，目的不是把每条细节讲完，而是先帮你在脑海中，构建一张清晰的地图。后面我们会为可感知、可操作、可理解、强健性 分别写专门的文章，把常见场景、典型错误、对应成功准则，以及设计与交付时的做法逐条讲清楚。
2.1 可感知
在无障碍里，最常见的一类失败发生在任务的起点。用户不是点错了，也不是不会用，而是压根没有接收到关键信息。信息一旦没进来，后面再好的交互都救不了，用户也不可能知道下一步该点哪里、该填什么。
这种失败通常不是因为页面缺了内容，而是因为页面把内容藏在单一的表达方式里。比如错误只用红色标出来，却不写清哪里错、怎么改。状态只靠轻微的动效或颜色变化，停下来之后几乎分辨不出差异。按钮只放一个图标，没有任何文字提示，让人只能猜它的用途。还有一种更常见的情况，页面把规则、价格、限制条件写进一张海报图里，正文却没有对应的文字信息。视觉条件良好的用户也许能凭经验补齐，但低视力、色弱或依赖读屏的用户往往拿不到这些信息。
可感知要解决的就是这个问题。界面必须用足够明确的方式把关键信息交到用户手里。颜色可以用来强调，但不能当成唯一信号。图标可以用来辅助，但需要清楚的名称或说明。图片可以用来承载氛围，但只要图片承担了信息，就要提供等价的文字表达，让不同能力、不同环境下的用户都能得到同样的内容。
2.2 可操作
可操作关注的是一件事：让用户能用不同的输入方式把流程走完，而不是只能靠鼠标或手势“刚好点中”。
很多界面默认用户能精准点击，默认鼠标随时可用，也默认滑动操作一定顺利。可一旦用户改用键盘、读屏手势或开关控制，问题就会立刻冒出来。弹窗打开后，焦点没有进入弹窗，键盘用户找不到确认按钮。轮播只能横向滑动，却没有可聚焦的上一项、下一项控制。列表里需要左滑才能出现删除或更多，但页面上没有等价的按钮入口。结果就是用户并不是不想操作，而是根本没有路可走。
可操作要保证的不是某一种交互技巧，而是完整的操作通路。界面要为不同输入方式提供可达的入口，让用户不管用什么方式，都能完成同一件事。
2.3 可理解
即便用户已经看到了页面上的信息，也能完成基本操作，任务仍然可能在下一步卡住。很多失败不是出在看不见或按不了，而是出在理解不上。用户不知道当前状态意味着什么，也不知道接下来该做哪一步。
这种卡住最常见有两类原因。
第一类原因是规则表达不清。表单报错只写格式不对，用户不知道是哪一项错了，也不知道应该改成什么样才算正确。系统提示失败，却不说明原因，也不给补救入口。用户只能反复尝试，越试越乱。
第二类原因是行为缺乏一致性或可预期性。同一个按钮在不同页面做着不同的事，有时是提交，有时是下一步，有时又变成保存。流程有时会突然跳转，但页面没有给出明确反馈，用户不知道自己刚才那一步是否生效，只能靠猜，或者干脆不敢继续。
可理解要解决的就是这种不确定感。界面需要把规则说清楚，把行为做得可预期。提示要具体到能指导行动，错误要指向具体位置，并告诉用户如何修复。关键操作要有明确反馈，让用户知道结果是什么，以及下一步该做什么。
2.4 强健性
最后一类问题往往最不容易被发现。页面在视觉上看起来完全正常，你用鼠标也能顺利操作，但换成读屏器、键盘导航，或者换一台设备、换一种辅助技术，体验就开始变形，有时甚至直接走不下去。
这类问题通常不是出在视觉层面，而是出在语义与结构。界面上看起来像按钮的元素，如果实现上并没有按钮的语义，读屏器就不会把它当作按钮来读，也不会提供按钮应有的操作方式。页面上的状态如果没有被正确表达出来，选中、展开、禁用这些变化对读屏用户来说就等同于没有发生。结构层级如果混乱，读屏读出来的顺序就会不符合内容逻辑，用户听到的是跳来跳去的一串信息，很难建立对页面的整体理解。
强健性要保证的是一致与可靠。界面不仅要让视觉用户用得顺，也要让辅助技术能稳定地解析出结构、角色与状态，让不同设备、不同读屏器在关键行为上表现一致。这样一来，用户不需要靠猜，也不会因为工具不同就突然撞墙。
POUR 的意义也在这里。它把无障碍失败按根因分成四类，让你先找到问题属于哪一类，再去谈对应的修复方式。只要分类清楚，后面的改动就会更有方向性。
3. 分层结构
POUR 的价值，在于先把问题放回它该在的位置。你在页面里发现一个卡点，不必立刻翻条款、也不必急着争论改法，而是先判断它卡在什么环节：关键信息有没有真正到达用户，这是可感知的问题；操作路径能不能顺利走通，这是可操作的问题；规则与反馈能不能让用户看明白，这是可理解的问题；界面的语义与结构是否可靠、辅助技术读出来是否一致，这是强健性的问题。完成这一步，团队至少能先把话说到同一处，不至于一开口就各说各话。
但归类只是把方向厘清，并不能直接把事情做完。项目一旦往前推，大家很快就会问到更具体、也更尖锐的问题：这一页做到什么程度才算合格，哪些必须当场修，哪些可以排期补；设计改完以后怎么测，验收时又凭什么判定通过。四个原则回答不了这些问题，不是它们无用，而是它们天生更抽象。它们能指路，却不足以当尺子。
所以 WCAG 才会继续向下展开，把原则落成一套可执行、可验证的结构。
- 最上面仍是原则，用来定方向；
- 往下一层是指南，提示每个方向通常要关注哪些面向；
- 再往下是成功准则，把要求写成可测试的合格线，这一层才是验收真正依赖的依据；
- 最后配套理解与技术参考，解释条款想解决什么问题、常见的失败形态是什么，并给出设计与实现中常用的达标做法。
有了这样的分层，讨论就不会停留在应该更无障碍这种空话上。团队先用 POUR 找准问题，再用成功准则钉住合格线，最后借助参考做法把修改落到设计稿与代码里。标准也就不再是一堆概念，而是一件能用起来的工具。
4. 指南
WCAG 指南最大价值就是它把四个大的方向拆成一组更清晰的目标，告诉你每个原则最需要守住的关键面向。它更像路标，先把路径指明，再带你走向后面的细则，而不是一开始就拿出尺子逼你量到最细。
在 WCAG 2.2 中，一共有 13 条指南，它们分别归在四个原则之下。指南本身不承担验收职责，但它会把后续的成功准则组织成一套更易理解的结构，让你看得清每条成功准则究竟要解决哪一类断裂。
可感知下面有四条指南
- 文本替代（Text Alternatives）
- 基于时间的媒体（Time-based Media）
- 可适配（Adaptable）
- 可区分（Distinguishable）
可操作下面有五条指南
- 键盘可访问（Keyboard Accessible）
- 充足时间（Enough Time）
- 癫痫与身体反应（Seizures and Physical Reactions）
- 可导航（Navigable）
- 输入方式（Input Modalities）
可理解下面有三条指南
- 可读（Readable）
- 可预期（Predictable）
- 输入辅助（Input Assistance）
强健性下面有一条指南
- 兼容（Compatible）
读到这里，你就能看出指南的承上启下。它把 POUR 的抽象方向，进一步落成可讨论、可拆解的一组目标。接下来，每条指南之下都会展开多条成功准则。成功准则才是可以测试、可以验收的硬条件，而 A、AA、AAA 这样的等级，也正是从成功准则这一层开始出现的。
5. 等级 A/AA/AAA
当 WCAG 进入到成功准则这一步，问题就从方向讨论变成了现实取舍。尽管成功准则写得足够具体，也写得足够多，但它们天然有轻重之分，并不适合被一把尺子来界定。
有些要求一旦缺位，用户会在流程里遇到困难。比如键盘走不通主流程，焦点找不着落点，弹窗关不掉，这些不是体验上的瑕疵，而是任务直接无法完成。也有一些要求即使没做到，流程表面上还能勉强跑完，但体验会明显变差，能够顺利完成的人也会变少。比如对比度不足、说明含糊、关键状态读屏读不出来，都会让用户在不确定里反复试探。还有一部分要求能进一步扩大覆盖面，却往往牵涉更高的实现与维护成本，并不是每个产品都能在同一阶段把它们全部当作硬性门槛。
与此同时，产品所处的场景也决定了取舍的边界。公共服务、金融、教育这类产品面对的人群更广，风险更高，容错空间自然更小。早期业务或内部工具则常常需要先把关键路径打通，再循序补齐细节。倘若把所有成功准则都当成同等强制，结果往往只有两种：要么项目负担不起，要么口号喊得响，落地却模糊。
因此，WCAG 必须提供一种分级方式，让团队能明确承诺做到哪一步，也让验收有清晰边界。A、AA、AAA 正是在这里发挥作用。它们不是给产品贴的头衔，而是贴在成功准则上的门槛标记，用来说明一条要求处在什么层级。
- A 是最低门槛，代表基本可用的底线。
- AA 建立在 A 之上，再补齐一批对主流场景影响很大的要求，因此常被选作项目目标。
- AAA 覆盖更全面，但对设计与实现的要求也更高，更多时候作为进一步提升的方向，并不一定要求全站都达到。
当然，这里还需要把继承关系说清。达到 AA，并不是只做 AA 那一部分，而是先满足所有适用的 A，再满足所有适用的 AA。AAA 亦然，它是在 A 与 AA 的基础上继续往上加。只要记住这一点，你就不会把等级当成虚名。等级负责界定轻重与目标边界，分层负责把原则落到可验收的条款；两者合在一起，WCAG 才既能指路，也能划线。
5. 小结
写到这里，你可以把 WCAG 看成一套把可用性落到“可检验、可验收”的方法。它先从真实的任务链条出发，提醒我们用户想把事做完，离不开信息到达、操作可达、过程可懂。任何一步断掉，体验就会中止，而这种断裂既会发生在残障用户身上，也会在强光、噪声、单手、网络卡顿这些日常情境里突然降临到普通人身上。
因此 WCAG 不止是一句倡议。它先用 POUR 把问题按根因分到四个方向，让团队能用同一张地图描述卡点。接着它用指南把方向拆成更清晰的目标，再用成功准则把目标落成可测试的合格线，最后配套理解与技术参考，给出失败形态与常用做法。A、AA、AAA 则解决另一件事，明确哪些是底线，哪些是主流目标，哪些是更高追求，让团队能在资源与风险之间做出清晰承诺。
如果你把这一套理解透，WCAG 就不再像一堆编号条款。它会变成一把工具，让你从发现问题、解释问题，到推动修改、完成验收，每一步都有依据，也更有把握。
有0人收藏了本文
