5.3 无障碍

概述与动机

无障碍（accessibility，常简称为”a11y”）是一种构建软件的实践，使残障人士能够感知、理解、导航和使用它。这包括失明或低视力人士、失聪或听力受损人士、有运动障碍的人士、有认知或学习差异的人士，以及面临临时性或情境性限制的人，例如手臂骨折、强烈的阳光，或嘈杂的房间。大约五分之一的人有某种残障，而无障碍设计在某个时刻会让每一个人受益。这不是一项小众的照顾性举措，而是质量的底线。

对大型团队而言，无障碍必须内建到系统之中，而不能依赖个人的良好意愿。当众多团队向同一个产品交付功能时，一个无障碍性缺失的组件（一个没有标签的表单字段、一个只靠颜色区分的状态指示器、一个模态框中的键盘陷阱）就可能把残障用户挡在整个流程之外。把无障碍性内建到共享组件、设计令牌、测试流水线和完成定义之中，是使其在规模化场景下可靠的唯一方式。事后补救既昂贵又容易出错；从一开始就设计好，则既便宜又持久。

对政府机构而言，无障碍是一项法律要求和公民义务，而不是可有可无的加分项。公共服务必须服务于公众中的每一个人，而残障公民往往没有其他替代提供者可选：如果政府网站无法访问，他们就无法通过其他途径领取福利、办理执照或行使投票权。世界各地的法律和标准都使无障碍对公共机构成为强制要求，并且越来越多地也适用于私营部门。本章把无障碍同时当作三件事来对待：一项法律义务、一项伦理义务，以及单纯的优秀设计。

另见： 第 5.2 章（UI 设计与设计系统）、第 5.6 章（前端工程），以及第 5.1 章（UX 基础）。

关键原则

无障碍是一项基线质量属性，如同安全性和性能一样，而不是一项可选功能。
POUR 原则：界面必须是可感知的（Perceivable）、可操作的（Operable）、可理解的（Understandable）和健壮的（Robust）。
优先使用语义化 HTML；只在存在真正的空白时才使用 ARIA，绝不能用它取代原生元素。
任何能用鼠标操作的功能，都必须能仅靠键盘操作。
不要仅靠颜色、形状或位置来传达信息。
自动化工具只能发现一小部分问题；人工测试和辅助技术测试是必不可少的。
无障碍设计对每个人来说都是更好的设计（“路缘石效应”，即为残障人士而建的功能能让所有用户受益）。
要与残障人士一起设计和测试，而不只是为他们设计。

建议

依据 WCAG 进行设计和构建，瞄准当前标准

Web 内容无障碍指南（WCAG）是国际公认的参考标准。WCAG 2.1 和 2.2 依据四项 POUR 原则组织，并在 A、AA、AAA 三个合规等级上提供可测试的成功标准。要以 AA 级作为你的基线目标；大多数法律引用的正是这一级别。WCAG 2.2 新增了关于焦点可见性、目标尺寸和降低认知负荷的标准。WCAG 3.0 是正在兴起的后继版本，结构与之不同，目前仍在开发中。要密切关注它，但当前要依据 2.2 AA 进行构建。要把这些指南当作一个下限，而不是上限：通过每一条标准并不能保证一个真正可用的体验。

使用语义化 HTML 和正确的 ARIA

原生 HTML 元素（按钮、链接、表单控件、标题、列表、地标区域）自带内置的无障碍语义、键盘行为和辅助技术支持。要优先使用它们。只有在 HTML 无法表达的自定义控件上，才需要使用 ARIA（Accessible Rich Internet Applications，无障碍富互联网应用）角色、状态和属性，并遵循 ARIA 编写实践指南。ARIA 的第一条规则很简单：如果原生元素能胜任，就不要使用 ARIA。错误的 ARIA 比完全不用还糟：它会主动误导屏幕阅读器。要为页面提供逻辑清晰的标题结构、有意义的标签、图像的替代文本、媒体的字幕和文字记录，以及每个标签与其控件之间的程序化关联。

确保键盘和辅助技术的可操作性

每一个交互元素都必须能够仅靠键盘按逻辑顺序抵达并操作，并配有清晰可见的焦点指示器。要避免键盘陷阱。当内容发生变化时要刻意地管理焦点：对话框打开时把焦点移入其中，关闭时把焦点归还，并通过实时区域（live region）宣告动态更新。要用真实的辅助技术进行测试，包括桌面端和移动端的屏幕阅读器、屏幕放大、语音控制和开关访问设备。并且要尊重用户的偏好设置，例如减弱动效和增强对比度。

用自动化工具、人工评审和真实用户进行测试

自动化无障碍扫描工具很有价值，应当在每次变更时都在流水线中运行。但研究一致表明，它们只能发现真实问题中的少数部分，大约三分之一。其余的问题需要人工判断：键盘走查、屏幕阅读器测试、对比度检查，以及询问内容是否真的可以理解。最重要的是，要让残障人士参与到可用性测试中来。要把无障碍验收标准写入完成定义，使问题能够按每个用户故事被发现，而不是在上线前的一次审计中才被发现。

让无障碍成为组织性工作，而不是英雄式的个人努力

要把无障碍融入设计系统，使组件默认就是无障碍的。要提供培训，使设计师、工程师、内容作者和产品经理各自都清楚自己的职责所在。要建立无障碍标准、指定负责人或卓越中心，并建立整改流程。要发布无障碍声明，并为用户提供一种报告障碍的途径。并且要以无障碍为标准进行采购：要求供应商和第三方组件符合规范，并提供证据（例如一份无障碍合规报告）。

权衡：优点与缺点

方法	优点	缺点
从一开始就内建无障碍	最便宜、最持久，对每个人都更好	需要前期培训和纪律
事后补救 / 整改	推迟投入，能让快速上线不受阻	成本高得多、脆弱，在此期间存在法律风险
仅使用自动化测试	快速、廉价，能在 CI 中捕捉回归	遗漏约三分之二的问题；带来虚假的信心
人工加辅助技术测试	能发现真实的可用性障碍	较慢，需要熟练的测试人员和设备
与残障用户一起测试	获得关于真实体验的第一手真相	招募工作和成本；必须以尊重的方式进行

核心的权衡在于前期纪律与延后成本之间的取舍。从一开始就内建的无障碍性成本低廉，并能为每个人提升质量；在法律压力下事后补救的无障碍性则昂贵、不完整且令人焦虑。从长远来看，这与”速度”之间并不存在真正的权衡：无法访问的软件对你五分之一的用户来说根本无法使用。那是一个缺陷，而不是一种节省。

与团队讨论的问题

无障碍方面的回归是否会像一个坏掉的测试那样使我们的构建失败？如果不会，为什么不会？ 自动化扫描工具只能发现大约三分之一的问题，但它们确实能发现的那些问题（缺失的标签、对比度不合格、没有标签的控件）在 CI 中被发现的成本很低，而在上线前的审计中被发现的成本则很高。把回归当作构建失败来对待，正是把无障碍从英雄式的个人努力转变为一种可靠的系统属性的关键，而这也是唯一在众多团队向同一个产品交付功能时依然有效的做法。要决定哪些检查项是阻断性的，哪些是建议性的，以及谁能够否决一次失败。请把你当前的扫描结果和你的完成定义带到会议中。如果无障碍标准没有被写入每个用户故事的完成定义，它们就会在截止日期收紧的那一刻被降低优先级。
我们对自定义控件的规则是什么，谁在其上线前评审 ARIA？ 原生 HTML 元素自带免费的键盘行为和辅助技术支持，而错误的 ARIA 比完全不用还糟，因为它会主动误导屏幕阅读器。要约定语义化 HTML 是默认选择，任何自定义控件（一个定制的下拉菜单、日期选择器或模态框）在合并之前都需要经过依据 ARIA 编写实践指南进行的键盘和屏幕阅读器走查。这一点对许多团队复用的交互组件尤其重要，因为一个带有键盘陷阱的坏模态框，就可能把残障用户挡在整个流程之外。请带来一份你的自定义控件清单，并询问哪些已经用真实的屏幕阅读器测试过。任何尚未测试过的，都是藏在共享代码中的隐患。
我们对无障碍覆盖层（accessibility overlay）的政策是什么，是否有人真的相信它们是一种真正的解决办法？ 覆盖层被宣传为一段能让网站合规的一行代码脚本，当法律压力来临、截止日期临近时，它们十分诱人。它们并不能带来真正的合规，还可能让辅助技术用户的体验变得更糟，而对政府机构而言，它们让底层的法律义务依然未被履行。要明确决定，你将把资源投入语义化标记、键盘支持和与残障人士一起进行的测试，而不是购买一个粉饰问题的小组件。请把一份覆盖层订阅的费用带来，与一次性把无障碍性内建到你的组件和流水线中的费用进行比较。及早明确这一点，能防止日后在恐慌中做出一个花了钱却什么都没解决的采购决定。
残障人士是我们设计和测试工作的一部分，还是我们仍在为一个自己想象出来的用户进行设计？ 自动化扫描工具、甚至专家审计都能告诉你标记是否合规；它们无法告诉你一个失明用户是否真的能完成你的结账流程，或者一个有认知障碍的人是否能理解你的错误信息。让残障参与者参与进来，是获得第一手真相的唯一来源，它会改变你所构建的东西，但也带来了一些真实的问题：如何公平地招募，如何为参与者的时间给予补偿，以及如何避免把一位参与者当作所有残障群体的代言人。请带来你当前的研究名单、你的招募和支付方式，以及过去一年中有多少项研究真正包含了残障参与者的一份诚实统计。对大型组织而言，一个拥有公平报酬、覆盖视觉、听力、运动和认知等不同需求的常设小组，才能把这件事从一次性的姿态变成一项可靠的输入；在政府机构中，让你所服务的公众参与进来，往往是法律和公民义务的一部分，而不是一项可选的锦上添花之举。
当我们购买或嵌入一个第三方组件时，我们是否要求提供无障碍证明，谁来核实它？ 一个大型产品中出货的许多内容并不是内部编写的：来自某个库的日期选择器、iframe 中的支付小组件、图表包，或者一整个 SaaS 模块。一个无障碍性缺失的嵌入式组件，无论你自己的代码有多干净，都可能使整个流程失败，而一旦它被接入进来，替换它的成本就很高。要决定把无障碍作为一项采购要求，要求供应商提供一份无障碍合规报告（例如一份 VPAT 之类说明产品相对于 WCAG 的达标情况的文档），并且要由懂技术的人去核实这份声明，而不是把它归档了事。请带来一份你的第三方组件清单，并询问哪些拥有最新且可信的合规证据。在企业和政府采购中，要把 WCAG 2.2 AA 合规性和整改权写入合同，因为签约前做出的承诺，远比上线后才发现的障碍更容易被执行。
我们的目标合规等级是什么，谁负责它，我们如何随着标准的演进保持它的时效性？ WCAG 2.2 AA 是当前的底线，大多数法律都引用它，但 2.2 新增了许多团队尚未采纳的标准，而 WCAG 3.0 正在到来，其结构也有所不同。如果没有指定的负责人，标准就会漂移：不同团队瞄准不同的版本，没有人追踪这一差距，合规性会在两次审计之间悄悄腐化。要决定你所依据构建的确切版本和等级、谁有权提高它，以及新标准如何进入设计系统和完成定义。请带来你当前所声明的目标、各团队实际达标情况的证据，以及一份采纳你尚未纳入的 2.2 标准的简短路线图。对大型组织或公共机构而言，一位无障碍负责人或卓越中心、一份已发布的无障碍声明，以及一份为下一个标准版本制定的书面计划，才能让你在面对监管者或法庭时用证据而不是良好意愿来作答。

行业视角

初创企业。 速度在这里对你有利，因为在代码库还很小的时候，无障碍是最便宜的。要从第一个冲刺开始，就在 CI 中加入一个自动化扫描工具，并在拉取请求检查清单中加入一次键盘走查，并依赖语义化 HTML，这样你就能免费获得键盘和屏幕阅读器支持。要跳过覆盖层和重量级工具；回报是，当客户的采购团队在销售过程中要求一份合规报告时，你能在几天之内作答，而不是手忙脚乱。

小型企业。 由于没有无障碍专家，预算也很紧张，应购买无障碍能力，而不是自己构建：选择一个已经合规并明确声明这一点的平台、主题或组件库，并优先选择发布了无障碍声明的供应商。要用免费工具自己覆盖那些高价值的基础项（）仅键盘检查、对比度检查工具，以及每个字段上清晰的标签，因为这些正是最常把客户排除在外的失败之处。要把一个错误或不可用的自动化流程当作流失的一位客户来对待，因为小型企业很少能提供辅助渠道作为退路。

企业。 在规模化场景下，工作的重点是让无障碍成为跨众多团队的一项系统属性。要在设计系统中默认交付无障碍的组件，在 CI 中拦截回归，并设立一位负责人或卓越中心，配备整改流程，为设计师、工程师和内容作者提供培训。要把合规性作为一项指标随时间追踪，把 WCAG 合规性写入采购要求，并把第三方组件当作一个投资组合来管理，以免一个嵌入式小组件悄悄地使一条共享流程失败。

政府。 无障碍是一项法律强制要求和公民义务，因为残障公民往往没有其他替代提供者来领取福利、办理执照或行使投票权。要依据你所在司法辖区所引用的标准进行构建（例如 Section 508、EN 301 549，或映射到 WCAG 2.2 AA 的《欧洲无障碍法案》），发布一份无障碍声明并提供报告障碍的途径，并与你所服务的残障公众一起进行测试。要拒绝把覆盖层当作真正合规性的替代品，并要求供应商提供可信证据，并在合同中约定整改权。

示例

初创企业。 一家开发招聘工具的三人初创公司，从第一个冲刺开始，就在其构建流程中加入了一个无障碍扫描工具，并在拉取请求检查清单中加入了一次快速的键盘走查，其理由是保持无障碍比日后再修复要便宜。当一家中型客户的采购团队在销售周期中要求提供一份无障碍合规报告时，这家初创公司已经在使用语义化 HTML、为每个字段都添加了标签，并且到处都保留了可见的焦点，因此他们能在几天之内作答，而不是手忙脚乱。这份准备赢得了一笔交易，而一个在同一要求上失分的竞争对手则丢掉了这笔交易。

企业。 一家大型零售商面临一起集体诉讼，原因是失明客户无法用屏幕阅读器完成结账。除了和解金和律师费之外，该公司还不得不在法院监督的时间表下进行整改。此后，该公司把无障碍重新内建到其设计系统和 CI 流水线中，把屏幕阅读器测试加入了完成定义，并对团队进行了培训。重建后的无障碍结账流程也提高了转化率，并减少了所有人的客服联系次数：那些帮助屏幕阅读器用户的修复（清晰的标签、错误信息、逻辑顺序）帮助了所有用户。

政府。 一个公共福利机构在法律上被要求让其在线申请系统达到 WCAG 2.1 AA 标准。早期与失明及低视力用户、仅使用键盘的用户，以及有认知障碍的用户进行的测试发现，一个仅靠颜色区分的”必填字段”指示器、一个无法访问的日期选择器，以及未被宣告的验证错误，正在阻碍人们完成申请。通过语义化标记、可见焦点、实时区域错误宣告，以及通俗易懂语言的帮助信息来修复这些问题，让残障公民第一次能够自行完成申请。这减少了对现场人工帮助的依赖，并降低了服务成本，同时满足了法律强制要求。

商业论证：动机、投资回报率与总拥有成本

这项商业论证建立在市场覆盖面、法律风险、服务成本和质量之上。残障人士及其家庭掌握着可观的消费力；把他们排除在外，就是放弃这部分消费力。无障碍的服务减少了对昂贵的辅助渠道（电话和现场帮助）的需求，这是一项直接的运营节省，对政府机构而言尤其如此。并且由于无障碍方面的改进（清晰的标签、键盘支持、可读的内容、健壮的标记）对每一个人都有帮助，它们通常会提高整体的完成率和满意度。

在总拥有成本方面，采纳的成本是培训、工具，以及把无障碍内建到组件和流水线中的工作，如果你从一开始就这样做，这些成本都是有限的。不采纳的成本则是严重的，并且来自多个方向：法律责任（诉讼、和解、法院指令的整改、监管处罚）、在截止日期压力下进行事后补救所需的高得多的费用、声誉损害，以及通过更昂贵的渠道服务被排除用户所带来的持续成本。事后补救的成本通常是从一开始就设计好所需成本的好几倍。

要向管理层说明理由，应首先从适用的法律义务入手（对政府机构、以及越来越多的私营部门而言，这一点是不可协商的）。然后量化你所排除的潜在人群规模、这种排除所带来的辅助渠道成本，以及”路缘石效应”给所有用户带来的收益。要把无障碍定位为风险管理加质量，而不是慈善。

反模式与陷阱

把无障碍当作上线前的一项打钩任务：只在最后进行一次审计，而不是持续的实践，这必然导致昂贵的最后关头返工。
“div 汤”（div soup）：在通用元素上绑定点击处理程序的非语义化标记，对辅助技术不可见。
ARIA 滥用：把 ARIA 强行安在已经损坏的标记上，这比纯朴素标记更容易误导屏幕阅读器。
仅靠颜色传达信息：仅通过颜色显示状态，对色盲用户不可见。
不可见的焦点：出于美观考虑移除了焦点轮廓，使键盘用户陷入困境。
键盘陷阱：会困住焦点或使焦点丢失的模态框和控件。
对自动化扫描心存侥幸：通过了扫描工具的检查，就假定产品是无障碍的。
无障碍覆盖层：号称”一行代码修复”的第三方小组件，并不能带来真正的合规，反而可能让体验变得更糟。
把残障用户排除在研究之外：为一个想象出来的残障用户进行设计，而不是与真实的残障用户一起测试。

成熟度模型

第 1 级：启动。 没有无障碍方面的实践。只有当用户投诉或诉讼到来时，问题才会被发现，响应是被动的。标记是非语义化且未经测试的，没有人对这个问题负责。

第 2 级：发展。 存在一定的意识，一些团队也据此行动：这里在构建中加入一个自动化扫描工具，那里做一次键盘走查，在一次大发布前进行一次上线前审计。实践是基础性的，且在各团队间不一致，无障碍仍然是后期阶段的一项检查清单事项，并且经常在进度压力下被降低优先级。

第 3 级：标准化。 WCAG 2.2 AA 是已记录的标准，并在整个组织范围内强制执行。无障碍被内建到设计系统中，使组件默认就是无障碍的，经过自动和人工两种方式的测试，并被写入完成定义。团队接受过培训，存在一位负责人或卓越中心，整改流程也已被明确定义。

第 4 级：管理。 无障碍性依据基线被度量并用数据加以控制。该组织随时间追踪合规性指标（扫描通过率、按严重程度分类的未解决障碍数量、关键流程的屏幕阅读器测试覆盖率，以及整改所需时间），在仪表盘上按团队进行报告，并把回归当作构建失败、而不是建议性警告来对待。目标依据基线设定，进度得到复核，因此一个正在退步的团队会在审计发现之前就变得可见。

第 5 级：编排。 无障碍在整个组织范围内被持续改进和集成。残障人士以常态化的方式参与到研究和测试中，无障碍也被嵌入到采购、设计令牌和 CI 之中。该组织随着标准的演进而适应（采纳新的 WCAG 标准并为 WCAG 3.0 做准备），并影响供应商和合作伙伴，使整个供应链都合规。

讨论提纲

当截止日期收紧时，你如何防止无障碍被降低优先级？
对于你的风险状况而言，自动化测试、人工测试和用户测试的正确组合是什么？
无障碍合规性应当如何被写入供应商合同和采购要求？
你如何处理 WCAG 合规性与残障人士真正可用性之间的差距？
团队应当如何在今天依据 2.2 进行构建的同时，为 WCAG 3.0 做准备？
你如何公平且尊重地招募残障参与者并为其研究工作提供补偿？

关键要点

无障碍是一项基线质量属性，对政府机构而言，也是一项法律要求。
要以 WCAG 2.2 AA 作为下限进行设计；把 POUR 原则当作一种思维模型。
优先使用语义化 HTML；只在存在真正的空白时才正确地使用 ARIA。
自动化工具只能发现大约三分之一的问题；人工测试和辅助技术测试是必不可少的。
要与残障人士一起测试，而不只是为他们测试。
从一开始就内建无障碍既便宜又持久；事后补救则昂贵且脆弱。
无障碍设计对每个人来说都是更好的设计：路缘石效应是真实存在的。

参考文献与延伸阅读

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 and supporting Understanding/Techniques documents
W3C, WAI-ARIA Authoring Practices Guide
W3C Web Accessibility Initiative (WAI), introductory and tutorial materials
Laura Kalbag, Accessibility for Everyone
Sarah Horton and Whitney Quesenbery, A Web for Everyone
Regine Gilbert, Inclusive Design for a Digital World
U.S. Section 508 standards and Section508.gov guidance
European standard EN 301 549 and the European Accessibility Act
Government accessibility guidance (e.g., UK GDS accessibility manual)
WebAIM, research and articles including the annual accessibility analyses