开篇小故事：一家新闻资讯 App 即将上线，小华是这个项目的主设计师，她带着整个团队在会议室里进行最后一轮可访问性审查。测试员是一位使用 VoiceOver 的盲人用户。屏幕亮着，但他没有看屏幕，他只是用手指在上面滑动，听着耳机里传出的读音。

前几秒还算正常，VoiceOver 报出了导航栏、搜索框、几条标题。然后他进入了首页的图文流——那是她最得意的设计，每张配图都精心挑选过，图文排版漂亮，视觉层次清晰。VoiceOver 开始逐一读出那些图片：「图片。图片。图片。图片。」

整整一排，每张图片读出来都是同一个词。那个词毫无信息量。她坐在那里，意识到这位用户接收到的首页，和她设计的首页完全是两个东西。

尽管设计做完之后，小华检查了对比度，检查了触控区域大小，检查了字体缩放，甚至翻了规范文档确认每条她能想到的要求。但确没有人告诉她「图片上需要文字描述」

一. 无障碍不只是少数人的问题

提到「无障碍设计」，大多数设计师脑海中浮现的，是那些坐轮椅的人、使用白手杖的人，或者因为某种永久性残障而需要辅助技术的人。这种想法也不能说有错，但它严重缩小了无障碍设计真正影响的受众范围。

微软研究院在 2016 年提出过一个影响深远的分类方式，他将障碍分为三种类型：永久性障碍、临时性障碍和情境性障碍。

永久性障碍是大多数人最先想到的那类，全盲、肢体瘫痪、认知障碍。临时性障碍是暂时的功能受限，骨折打石膏的人用不了惯用手，眼部手术后暂时看不清楚。而情境性障碍，是最被低估的一类：环境和情境制造出来的，不依赖个人身体状况的功能限制。

无障碍设计的受益者远比「残障用户」更广泛——每个人在某个时刻都可能受益

比如站在户外强光下盯着手机屏幕，任何人的视觉辨别能力都会大幅下降。抱着一个睡着的婴儿，任何人都只能单手操作手机，触控精度随之降低。在嘈杂的地铁里用第二语言阅读一份操作说明，认知负荷会比平时高得多。这些情况下，需要无障碍设计的，不是「残障用户」，而是任何一个处在这些情境中的人——包括你，包括任何使用你产品的用户。

也正是这个视角的转变，从根本上改变了无障碍设计的意义。它不再是一项面向少数人的慈善性工作，而是设计质量本身的组成部分。一个在强光下对比度不足的界面，不只是对低视力用户不友好，它对任何在强光下使用的人都不友好。一个点击区域太小的按钮，不只是对运动障碍用户造成困扰，它对任何在颠簸中操作手机的人都是麻烦。

理解了这一点，才能理解为什么 WCAG 的受众不是边缘用户，而是所有用户。

二. WCAG 的构建思路

WCAG 的全称是 Web Content Accessibility Guidelines，中文译作「网页内容无障碍指南」。它由万维网联盟（W3C）下设的无障碍工作组（WAI）负责制定和维护。现行版本是 WCAG 2.1，发布于 2018 年，WCAG 2.2 于 2023 年作为补充更新发布。

很多设计师第一次接触 WCAG 时，最大的困惑是：为什么文档那么厚、那么抽象？明明可以写成「图片必须有替代文字」「按钮点击区域不得小于 44 像素」这样的具体要求，为什么 WCAG 要分成原则、指导方针、成功标准这几层，搞得像哲学教材一样？

这背后的原因其实是清单的局限。清单的有效性依赖于它的完整性——清单写的情况，你能处理；清单没写的情况，你不知道怎么办。而技术和设计的情境是无限的。2000 年代写成的清单，不会预见到 2015 年的移动端触控、2020 年代的语音交互、未来还没出现的交互范式。任何时间点写出来的具体清单，都会在下一个技术变迁中出现漏洞。

框架的工作方式不同。框架不描述「你应该做什么」，而是描述「为什么这件事重要」——它指向人类的需求，而人类感知信息的方式、操作工具的方式、理解意义的方式，在几十年的尺度内不会发生根本性变化。框架的稳定性来自于它锚定的是人，而不是技术。

这就是 WCAG 选择框架结构的理由。它不是懒得写清单，而是故意不写清单。

三. WCAG 的四层结构

WCAG 的内容可分为四层，从最抽象到最具体依次可分为：原则（Principle）、指导方针（Guideline）、成功标准（Success Criterion）、充分技术（Technique）。

下面我们用建筑规范打个比方，这四层的关系就会变得更清晰了。

最顶层的原则，相当于「建筑必须在火灾发生时保证人员能够安全撤离」。这是一个关于人的需求的陈述，它不告诉你怎么做，只告诉你为什么——人命要紧，出口必须可用。

第二层的指导方针，相当于「紧急出口必须有清晰的标识」。这把原则分解为可操作的设计方向，但仍然没有具体到尺寸和材质。

第三层的成功标准，相当于「出口标识必须在 15 米距离内清晰可见，文字高度不低于 200 毫米」。这层是可以被检查和验证的，审查人员可以拿卷尺测量，判断是否达标。WCAG 总共有 78 条这样的标准，每一条都可以被明确地判断为「通过」或「未通过」。

第四层的充分技术，相当于「推荐使用符合 ISO 7010 标准的绿色荧光疏散指示标志」。这层最具体，也最容易随时间更新。具体的技术实现方案会因为设备、平台、编程语言的变化而改变，WCAG 把这些放在规范之外，让它可以灵活更新。

理解了这四层，就理解了 WCAG 是怎么工作的：原则和指导方针几乎不变，成功标准在版本迭代中缓慢演进，充分技术则随着前端实践持续更新。

四. WCAG 的四个原则

WCAG 的四个原则分别是：可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、健壮性（Robust）。这四个词有各自的缩写首字母可以合写成 POUR，这也是很多人记住它们的方式。下面我们通过具体的案例说明，来带你了解这四条原则如何发挥作用

一个用户坐在屏幕前，打算完成某个任务。第一件事，他必须能够感知到屏幕上的信息。如果信息无法以他能接收的形式呈现出来，后面什么都不用谈了。这就是第一个原则：可感知。

感知到信息之后，他需要对界面施加操作——点击按钮、填写表单、滑动页面。如果这些操作无法完成，任务依然无法推进。这是第二个原则：可操作。

操作的过程中，他需要理解界面在告诉他什么，他的操作产生了什么结果，接下来应该怎么做。如果内容晦涩、行为不可预期，他即使能操作，也不知道该怎么操作、操作的是否正确。这是第三个原则：可理解。

前面三个原则，解决的是用户与界面之间的交互质量。但在现代数字产品中，用户不是直接接触视觉像素，而是通过浏览器、操作系统、辅助技术这一套技术栈来访问内容。如果底层的技术实现是损坏的，辅助技术无法正确解析，那么即使视觉设计完全满足前三个原则，使用屏幕阅读器的用户依然什么都得不到。这是第四个原则：健壮性。

这四个原则构成了一套产品使用的充分必要条件。去掉任何一个，体系都会出现漏洞：没有可感知，信息进不来；没有可操作，任务走不下去；没有可理解，用户不知道发生了什么；没有健壮性，整个前三条的努力对辅助技术用户都可能是无效的。

1. 可感知（Perceivable）：信息必须能被察觉

可感知原则的核心关切是：界面上的信息，能否以用户可接收的形式到达他们的感知系统？

这个问题看起来简单，但却覆盖了视觉、听觉和视觉辨别三个维度。设计师最熟悉的场景是视觉——盲人用户需要图片的文字替代、低视力用户需要足够的文字对比度。但可感知同样关注听觉场景：有听力障碍的用户看视频时能否获取语音信息？耳聋用户播放音频时是否有字幕提示？以及更微妙的视觉辨别场景：色盲用户能否区分只靠颜色区分的内容？缩放到 200% 时页面内容是否仍然可读？

一个常见的误解是，将可感知等同于「给图片加 alt 文字」。这个理解把一个宽泛的原则缩减成了一条具体的技术规则，使设计师在遇到非图片类的感知问题时没有了判断依据。我们来看三个典型的失败案例。

第一个是数据可视化图表没有任何文字替代。一张展示销售趋势的折线图，设计师精心配色、标注了关键节点，视觉上清晰易读。但使用屏幕阅读器的用户听到的，是「图片」两个字，什么信息都没有。

正确的做法是在图片替代文字中提供图表的文字摘要，或者在图表附近附上数据表格。可感知的要求不是禁止图形，而是要求图形承载的信息必须有可替代的文字形式。

第二个是错误状态只用红色来传达。表单提交失败后，有问题的字段被标红了——这对大多数用户清晰易懂。但对于红绿色盲用户，「红色」和「正常颜色」之间没有视觉差异。他们看到的表单，和正常状态一样。颜色作为唯一的信息载体，会让一部分用户完全失去信息。可感知的要求是，不能用颜色作为传达信息的唯一手段——图标、文字说明、下划线，至少要有一种不依赖颜色感知的方式。

第三个是无字幕的视频教程。一段产品演示视频，画面清晰，配音流畅，但没有字幕。对于有听力障碍的用户，这段视频的音频内容是完全缺失的。对于在嘈杂公共场合中无法开音量的用户，同样如此。字幕不是可选的附加功能，而是将音频信息转化为文字形式的可感知要求。

这些失败案例对应的，是 WCAG 成功标准中的几个关键条目。1.1.1 要求所有非文字内容都有文字替代；1.4.3 要求文字与背景之间的对比度达到一定比例（正文不低于 4.5:1，大文字不低于 3:1）；1.4.1 要求颜色不能作为传达信息的唯一方式。这些标准背后都指向同一个原则：可感知--信息必须能够被察觉。

2. 可操作（Operable）：界面必须能被使用

感知到信息只是起点，用户还需要能够完成操作。可操作原则关注的是：界面提供的所有功能，能否通过用户实际可用的输入方式来完成？

鼠标和触控屏只是两种输入方式，不是操作的全部。键盘操作是整个可操作原则的核心之一，因为键盘是辅助技术的通用入口——屏幕阅读器通过键盘事件导航，开关控制设备模拟键盘输入，声控软件也通过键盘命令与操作系统交互。一个不支持键盘操作的界面，等于对所有依赖辅助技术的用户关上了门。

但键盘操作的重要性不止于此。有运动障碍的用户可能无法精确控制鼠标，只能依靠键盘。有手部震颤的用户在操作鼠标时，小的点击目标会变得极难命中。一个双手抱着文件夹的人，可能只能用一根手指操作键盘。可操作的要求，覆盖了比「辅助技术用户」宽泛得多的人群。

触控场景下，点击区域的大小是可操作性的核心问题。苹果的人机界面指南推荐触控目标的最小尺寸是 44×44 点（pt），这个数值来自于手指触控的物理精度。手指尖的接触面积大约是 44×44 像素这个量级，更小的点击区域意味着用户必须极其精确地瞄准才能命中，轻微的手部抖动就会造成误触或错过。这对任何人都是体验问题，对有运动障碍的用户则是操作障碍。

时间限制是另一个常被忽视的可操作性问题。很多 Web 应用有会话超时机制：用户一段时间没有操作，系统自动退出。对于大多数用户，这只是一个小麻烦。但对于操作速度慢的用户——因为运动障碍，或者因为阅读困难，或者仅仅因为需要更多时间来决策——一个没有警告的超时意味着他们在漫长的操作过程中，会突然发现自己被踢出去了，而且可能丢失了已经填写的内容。

焦点指示器是设计师最容易忽视的可访问性特性。按钮或链接被聚焦时，浏览器默认会显示一个轮廓线，俗称 focus ring。这个样式在很多设计师看来不够美观，于是被移除了。但焦点指示器是键盘用户和辅助技术用户唯一知道「当前光标在哪里」的方式。去掉它，等于让这些用户在完全看不见自己位置的情况下操作界面。接下来，我们列举三个典型失败案例：

第一个是只能用拖拽的排序功能。设计师做了一个漂亮的卡片拖拽排序，允许用户重新排列列表顺序。这个交互在鼠标操作下感觉很流畅，但对于键盘用户来说，没有任何方法完成排序——因为拖拽依赖鼠标按住和移动这两个连续动作，键盘无法模拟。可操作的要求是，所有功能都必须有不依赖特定设备的完成路径，拖拽排序需要同时提供键盘可操作的替代方式（比如「上移/下移」按钮）。

第二个是没有警告的会话超时。用户在填写一个复杂表单，由于阅读和思考耗时较长，二十分钟后系统会话过期，直接跳转到登录页面，所有填写内容消失。可操作的要求是，时间限制必须提前警告，并给用户机会延长时间或者保存进度。

第三个是无法暂停的自动轮播广告图。首页有一个每隔三秒自动切换的图片轮播。对于有视觉注意力问题或认知障碍的用户，持续移动的元素会制造干扰，难以集中注意力阅读页面上的其他内容。可操作的要求是，任何自动播放的动画、视频或轮播都必须可以暂停或停止。

这些案例对应的成功标准包括：2.1.1 要求所有功能都可以通过键盘完成；2.4.3 要求焦点顺序合理、聚焦状态清晰可见；2.5.3 要求触控目标的大小足够完成操作。

3. 可理解（Understandable）：内容和行为必须讲清楚

前两个原则处理的是「信息能否到达用户」和「用户能否施加操作」。可理解原则处理的是更深一层的问题：用户接收到信息之后，能否理解它的含义？完成操作之后，能否理解发生了什么？

这个原则覆盖两个维度：语言清晰度和行为可预期性。

语言清晰度的问题，在大多数面向专业用户的工具里尤其突出。「Error 403 Forbidden」是一个技术上完全准确的描述，但对于不了解 HTTP 状态码的用户，它等于什么都没说。这个错误是暂时的还是永久的？是我没有权限，还是页面不存在，还是系统出了问题？我应该刷新、联系管理员，还是根本就进错了片场？一条错误信息如果只告诉用户「出错了」，而没有告诉用户「哪里出错、出了什么错、怎么修正」，它在可理解层面就是失败的。

一个好的错误提示需要同时做到三件事：定位（哪个字段或哪个操作出了问题）、描述（出了什么问题，用用户能理解的语言描述）、指导（怎么修正，越具体越好）。「密码长度不足，至少需要 8 位字符」满足这三点；「请修正您的输入」一个都没满足。

行为可预期性同样重要。用户在使用界面时会建立心理模型——他们预期某种操作会产生某种结果。当实际结果偏离预期，就产生了认知混乱。导航在不同页面上有不同的排列方式，用户每次都要重新适应；下拉菜单在某些页面打开需要点击，在另一些页面悬停就打开，用户不知道规则是什么。这些不一致，每次都会消耗用户的认知资源，对认知障碍用户尤其有害。

可理解原则还关注一个设计师经常忽视的问题：表单错误处理中用户数据的保留。当用户填写了一个长表单并提交，发现有字段填写错误，界面应该保留所有正确填写的内容，只标出有问题的字段。但很多表单在提交失败后会清空所有内容，让用户从头再来。这不只是体验糟糕，对于认知障碍用户来说，失去已经费力填写的内容可能意味着他们放弃整个任务。以下是三个典型失败案例：

第一个是通用错误代码。「Error 403」没有任何解释。用户不知道发生了什么，不知道问题出在自己身上还是系统，也不知道下一步该做什么。这不是可感知的问题（信息呈现出来了），也不是可操作的问题（按钮都能点），而是可理解的问题——信息无法被解读。

第二个是表单提交失败后清空数据。用户花了十五分钟填完一份复杂表单，因为邮箱格式错误提交失败，界面将所有字段重置为空白。用户需要从头再填。数据丢失不是技术故障，而是设计决策——可以选择保留数据，但没有选择保留。

第三个是不一致的导航行为。同一个产品中，有些页面的顶部导航是固定菜单，有些页面的导航需要点击汉堡按钮才出现，还有些页面导航只在滚动到顶部时可见。每次进入新页面，用户都需要重新找导航在哪里。可理解的要求是，跨页面反复出现的导航组件必须保持一致的位置和行为。

对应的成功标准：3.3.1 要求在用户输入错误时标识出具体的错误位置和描述；3.3.3 要求在条件允许时提供具体的修正建议；3.2.4 要求在同一网站中，具有相同功能的组件以一致的方式标识和呈现。

4. 健壮性（Robust）：技术必须能被辅助工具解析

健壮性在四个原则中的位置有些特别。前三个原则都在讨论用户体验质量——信息是否可见、操作是否可行、内容是否可理解。健壮性讨论的则是一个不同层次的问题：底层技术实现是否正确，辅助技术是否能够读取和处理这些内容。

我们通过一个直观案例进行讲解。设计师设计了一个自定义下拉选择器，视觉效果精美，动画流畅，完全符合品牌风格。交互文档写清了状态变化和操作逻辑。开发团队用普通的无语义容器元素实现了整个组件。视觉上，一切正常；鼠标操作，完全没问题。但屏幕阅读器打开页面，遇到这个下拉选择器时，读出来的是：什么都没有。因为屏幕阅读器不是在看视觉像素，而是在读 HTML 的语义结构，而一个没有语义的容器没有任何角色信息——它不是一个选择器控件，辅助技术看不见它。

健壮性要求的是 HTML 的语义角色必须正确传递。按钮就是按钮，不是被设计成按钮样子的装饰性容器。下拉菜单必须告诉辅助技术它是一个菜单，当前选中了什么，有多少选项。文本输入框必须和它的标签建立关联，这样屏幕阅读器才知道这个输入框是让用户填什么的。

健壮性不只是开发的责任，它有一部分是设计决策的结果。当设计师选择使用自定义组件而不是原生控件，当设计师要求开发实现一个非标准的交互模式，这个决策就在健壮性层面埋下了风险。如果设计规范中没有明确要求「自定义组件必须具备正确的语义角色」，开发很可能不会主动添加这些看不见的属性。

健壮性和前三个原则的关系是：它是前三个原则能否生效的技术前提。可感知要求图片有替代文字——但如果 HTML 结构让屏幕阅读器找不到这个替代文字，可感知等于白做了。可操作要求按钮可以键盘触发——但如果辅助技术识别不到这个元素是一个按钮，键盘焦点就不会停在它上面，用户根本到不了这里。健壮性写在 WCAG 四个原则的最后，但它在逻辑上是其他三个原则能够成立的基础。

五. 四个原则之间的关系

单独理解每一个原则都相对容易，难的是理解它们如何协作，以及出了问题时如何定位是哪个环节出了问题。

可感知、可操作、可理解，构成一条序列性的链条。用户必须先感知信息，才能决定操作；完成操作后，必须理解反馈，才能决定下一步。这条链条是单向的，任何一个环节断裂，后续环节都无法启动。颜色对比度不足（可感知失败）意味着用户根本看不到那个按钮，可操作问题压根没有讨论的机会。

健壮性的位置则不同。它不是链条的一环，而是链条运行的地基。它是那个让辅助技术能够「读懂」界面的技术基础。如果地基不稳，可感知、可操作、可理解三个原则在辅助技术眼中都可能坍塌。

四个原则之间也存在交叉。一个只用颜色传达信息的错误状态，同时违反了可感知（色盲用户无法察觉颜色变化）和可理解（即使察觉到，含义也不明确）。这种交叉不是问题，而是提示：当某个设计决策出现问题，往往不是恰好踩了一条规则，而是在多个层面上同时影响了用户体验。

WCAG 框架可以作为一个诊断工具使用。当你在复审中发现问题时，不妨先问：这是哪条链断了？用户是无法感知，还是无法操作，还是无法理解，还是辅助技术根本解析不了？定位到原则层级，再向下找对应的指导方针和成功标准，比直接在七八十条标准里逐一对照要高效得多。

六. 合规是底线，不是终点

WCAG 的成功标准分为三个合规等级：A（最低）、AA（中间）、AAA（最高）。绝大多数机构和法规要求达到的是 AA 级。达到 AA，意味着你满足了规定的最低门槛，不代表你的产品对辅助技术对用户来说好用。

一个图片的替代文字写「图片」，技术上是有替代文字，1.1.1 这条标准没有被违反。但「图片」二字没有任何信息量，用屏幕阅读器的用户只听到「图片」，和什么都没有的效果几乎一样。规范通过了，体验依然是糟糕的。

表单错误提示只写「请修正错误」，没有具体说明哪里出错，技术上也可能通过一些成功标准的字面要求，但可理解层面的实际效果远低于「密码至少 8 位」这样的具体描述。

WCAG 的原则指向的是人类需求，而成功标准是为了让那些需求可量化、可验证而设立的最低门槛。两者之间有差距。通过了成功标准，只是证明你没有在这个点上制造明确的障碍，不等于你在这个点上提供了真正好的体验。

我们要把 WCAG 当作地板，而不是天花板。地板是必须站上去的，但好的设计只发生在地板之上很高的地方。