原文：Web Accessibility Guidebook for Developers by Nikola Shekerev (KendoReact team 的 QA 工程师)
基于无障碍规范 (Section 508, WCAG 2.0 and WAI-ARIA)，在为 KendoReact (一套 React 的原生 UI 组件) 做无障碍优化期间，我们讨论了不少无障碍话题，有基础入门的也有高阶深入的。在这篇文章中，我们希望可以将 KendoReact 的 Web 无障碍优化之路，以及探索到的最佳实践方案分享给各位。
根据 W3C 的定义，有生理缺陷的人也能轻松使用，更确切地说是能够感受、理解、操作产品(比如网站、工具…各种现代技术)，就可以被称为"无障碍"(accessibility)。
闭着眼睛使用你的产品，测试看看它是否是"无障碍"的。在无法用眼看无法用鼠标，仅仅通过屏幕阅读软件对界面 的描述去操作你的产品时，人们还能顺利地使用那些呕心沥血做出来的功能吗？
为什么总是无人在意无障碍
大家都在聊无障碍的重要性，但事实上大部分人仅仅是在"谈论"而已，为什么现实中没什么人在实践无障碍呢？主要有以下三种原因。
首先，你真的很难对残疾人的生理不便感同身受，要处理自己无法体会的情况，确实很难。大多数时候我们缺乏的不是动力，而是所谓的"常识''：生理缺陷到底是怎么阻碍人们使用我们的站点。这个问题包含两个方便：哪些生理缺陷会影响用户使用产品；以及如何调整产品以实现无障碍。对这两个问题的细节我们还不了解。
其次，实现无障碍的工作量不小。开发者需要先了解标准，参照标准进行开发。开发完成了？很好，下一步是测试，有大量的手工测试在等着你。后面我们将分享一些实践经验，有了这些经验开发者可能轻松一些，但总体上来看还是有很多工作要做的。
第三点，营收压力决定了设计导向。很好理解，在商业项目中不太可能为了少数用户而延迟交付，关注大部分用户的需求才是核心要义，所以无障碍优化往往会被推到下一个、再下一个…版本。
为什么无障碍很重要
伦理意义
生理缺陷者的日常生活相对不便。至少在互联网中，将服务平等的提供给你的用户是最基本的尊重。
市场
10亿网民中有20%的人或多或少都有一些障碍，从比例来看的确算少数，但10亿的五分之一也不容忽视。
法律
随着法律体系的不断完善，未来会有明确的法律条例约束互联网应用的无障碍体验。这一点在后文会展开描述。
用户体验
遵循无障碍指南可以让用户更好地使用你的站点，无障碍的优化还能提高可用性，这是对所有用户都是有利的。比如提高文字的可读性，也有利于视觉正常的用户的体验。
工程
总体来看，有着良好无障碍体验的产品往往也有良好的设计和工程化。如果一份代码已经不忍直视了，那也不用对这个产品的无障碍抱有什么期待。对于想要成为匠人的我们而言，做好无障碍只不过是职责内的的一部分而已。
口碑
无障碍体验比你的对手要好，这无疑是一个颇有竞争力的优势。能大大提升品牌口碑。
SEO
其实 SEO 和无障碍优化是有重叠的。比如具有良好语义化的 HTML 结构对 SEO 和无障碍都有帮助，所以要正确的使用标签属性，正确对待 label、video transcription、image captioning，还有 title 和 header 标签。
立法
世界各地的法律都在往规范化无障碍体验的方向迈进，未来无障碍会成为一个产品的标配。美国的无障碍推进由 ADA 负责，许多发达国家都有类似的法律，比如应该有 2010 年平等法案。目前，根据这些法律，政府相关的公共组织或者经营都必须按照 WCAG 规定实现无障碍。
无障碍优化的对象不仅仅是你的用户。如果你所在的组织人数超过50人，也许你的团队中也有生理缺陷的人，所以即使是内部工具也做好无障碍。
美国专用：另外，如果你在为政府部门工作，除了上面需要注意的，还要确保遵守了 Section 508 of the Rehabilitation Act。法律规定，所有美国政府服务都需要遵守这一条规定。
这些法律可不只是善意的摆设。越来越多的法律被付诸行动，更详细的进度可以查看无障碍与法律这篇文章。
生理障碍的类型，以及无障碍的最佳实践
听觉、视觉、行动和认知
，大部分生理障碍集中在这四个方面。不同类型包含多种情况，它们或多或少都影响了人们使用互联网，所以需要网站或者应用开发者为这些用户做好无障碍优化。让我们分别探索它们的最佳实践吧。你将会发现这些实践基本和底层技术无关，更多的是我们如何设计自己的产品。这也意味着，在创造这个产品的过程里，团队中的每一个人都可以贡献一份自己的力量。
听觉障碍
从轻微的听力受损到完全听不到都能算听觉障碍。要提高这类用户的用户体验，就要保证你的产品不只依靠声音来传递信息，提供音频的同时还需要提供别的媒介。比如，当你使用视频时，确保它有完整的字幕。如果你用的是音频，也别忘了文本描述。字幕和描述都要完整，不要遗漏了信息。后文中，我们将会罗列出可读性指南，开发者可以根据这份指南参照自己的字幕和文本是否合理。除此以外，还要注意音视频中的噪音影响，保证受众可以准确地接收到消息。
视觉障碍 — 视力低下
优化低视力人群的用户体验最重要的方法是，提供一个可读的界面。UI 元素要足够大且清晰。文字的情况更复杂一些，详情可以看后文的可读性指南。这份指南意在指导开发者优化低视力人群的使用体验。
对比度是另一个重要的方面。界面元素的颜色有着高对比度有助于低视力用户阅读。你可以在这里找到 WAI (Web Accessibility Initiative) 推荐使用的工具，用于检查对比度是否合理。现在大量页面设计的对比度都大有问题，毕竟视觉政策的用户会觉得高对比度的主题"辣眼睛"。既不想牺牲产品设计又想满足视障用户的需求，折中方案就是，提供切换主题的入口，就和语言切换类似。视觉障碍 — 盲人
盲人使用读屏软件。这类软件的原理是解析 HTML 结构，然后用自然语言向用户描述解析结果。针对屏幕阅读器的开发有其特殊之处，我们会重点在后文中讲解。另外，失明用户所使用的输入设备也有所不同。一般不会使用需要"看"的鼠标，盲人更多使用的是键盘。
视觉障碍 — 色彩障碍
即是是色盲也分有各种各样不同情况。请注意，接下去所说的只是这种疾病的冰山一角。绿色弱最常见，这种缺陷会导致患者看不到绿色。类似的，红色弱认不出红色，相对绿色弱的患者数量要少。这两种情况的可见光谱上比较相近，以"红绿色盲"广为人知。蓝色弱指的是无法辨别蓝色，这种情况相当罕见。
上述每种情况中还有轻重之分，从轻微的知觉问题到完全看不到相应的颜色。如果是缺少部分知觉，我们使用前缀 'nomaly'；如果是完全无法看到颜色，用 'nopia' 做前缀。完全的色盲相当少见，患有这种缺陷的人眼里只有不同深浅的灰色。颜色感知的变化影响的整个视觉光谱，而不仅仅是一种颜色。
你的初衷可能是选择一种大部分有色彩障碍的人都能识别到的颜色。但由于有各种色弱，且每种色弱的情况有轻有重，要选出这样一种颜色相当困难。不过橘色和蓝色还算能满足大部分情况。这就是为什么互联网产品里蓝色如此常见。
有很多工具可以模拟有色彩障碍的人使用你的站点时的体验。你可以用这些工具感受一下，如果需要的话，可以为色彩障碍用户设计一套主题。
更好的解决方式 — 不只用颜色传递关键信息。还可以用形状、符号、动画等等媒介来表达。
运动障碍
需要快速或者重复执行某个动作，比如长按一个按钮或者在规定时间内完成某项操作，这些对于有运动障碍的人来说都比较困难，如果他们强行做到这些动作，可能会造成生理不适。你最好尽可能地避免采用这些动作，不过这不是件容易的事情。比如在滑动滑块的时候，你可能需要按住一个按钮来保证它持续滑动。想到了运动障碍的人们，于是你改变方案，换成每轻触一次按键滑块滑动一点距离，但毫无疑问，这样"改进"成了重复的动作，同样为运动障碍的人们带来负担。所以在这方面，我们的建议是，你需要保证你的产品无论使用鼠标操作还是用键盘都是很好操作的。
认知障碍 — 与晕动症和感官超载相关（比如癫痫）
有很多情况会诱导晕动症或者感官超载，特别是一些高速、刺激的事物，比如摇晃、强光、闪光(一秒闪三次以上)。重复的移动、极快的速度都可能刺激到患者。一个典型的温和的重复模式是"不断掉落的节日氛围雪花"。在页面上使用华丽的变化和急剧的过渡效果也会造成问题。总之就是要温和。如果你一定要用快速变化的效果，别忘了加一个开关，允许用户关掉它。
认知障碍 — 学习障碍
关键是要足够简单。简化你的场景、你的界面。尽可能用简单的描述，不要用那些华丽的词藻。用精准的语言描述清晰的指令。你的描述要遵守"金发姑娘原则" (Goldilocks principle) — 缺少信息不是好事，但过多的描述反而迷惑用户。也不要增加倒计时之类的时间限制，这样会增加用户的负担。
认知障碍 — 阅读困难
阅读困难是一种生理缺陷，患有这种缺陷的人难以阅读，当他们看着文字的时候会觉得文字在旋转扭曲或者全部挤在一起。后文中我们将会提出对阅读性文字的指导，这部分内容可以很好地指导开发者开发出对阅读困难人群也友好的产品。
可读性小技巧
保持良好的可读性可以至少保证一部分生理不便的用户可以使用你的站点：可读的字幕和文本分别能帮助到有听力障碍的人们和视力不佳或者阅读障碍的人。还有一条经验之谈 — 大字号用线条干脆利落的无衬线字体。
空隙很重要。举个例子，长长的一行文字是很难阅读的，70个字符是单行的上限。对字幕来说，35个单词足够了。过窄的行间距会使读者喘不过气来，1.5倍的行距看上去还不错。全是大写字幕的单词也不容易阅读。在类似字幕这种会自动播放的场景里，还需要考虑文字滚动的速度，可以按照0.3秒读一个单词的速度来估算更新字幕的时间。
还有一个关键点—对比度。背景图片通常会影响阅读文字，这种情况下最好在文字周围加一层边框，以提高和背景的对比。当然如果非要在文字后面加背景，用纯色高对比度的更容易看清楚文字内容。
现在已经有不少字体提高了可读性，比如 Opendyslexic、Inter。
辅助技术简介
"辅助技术"是一个专业的产业，它指的是辅助残疾人使用的软硬件。常见的输入设备有嘴棒、头棒、大轨迹球、专用键盘、语音识别软件；输出设备上有屏幕放大镜、屏幕阅读器、盲文显示器、助听器、带有自然语言界面的软件等等。这其中有些是提高现有技术的无障碍性，有些则是提供了另一种使用计算机的方式。
大多数辅助技术在操作系统层面上已经实现了，web 开发者基本不用做什么事情。但是，对屏幕阅读器来说，要做的事可能更复杂一些。屏幕阅读器的原理是解析 HTML，然后将这个结构用自然语言描述出来，可想而知，屏幕阅读器读出来什么东西取决于代码写的怎么样。所以当 web 开发者在做网站的无障碍时，屏幕阅读器的阅读效果应该是第一考虑因素。接下来我们会聊到这一方面的最佳实践。
为屏幕阅读器做优化
编写语义化的 HTML
要说怎么做对屏幕阅读器最友好，那无疑是优化 HTML 标签的语义 — 使用有效的 HTML 标签、遵循最佳实践、根据不同的场景使用不同的 HTML 元素。比如如果某个元素无论是行为还是视觉表现都是"按钮"，那理所应该选择
而不是
；如果要表现一个标题，应该用
而不是仅仅用 CSS 让它看起来是一个标题。
HTML 元素的语义化正式定义可以参考标准。
说起来好像不难，但现实生活会告诉你，这实践起来不容易。好了，让我们进入下一节。
遵循规范
和任何基础技术一样，互联网也有多个制定标准的组织。W3C ( World Wide Web Consortium) 就是其中一个，WAI (Web Accessibility Initiative)) 属于 W3C。我们作为开发者需要遵循 WAI 制定的 WCAG ( Web Content Accessibility Guidelines)，这份规范定义了互联网上主要的无障碍标准。
上文里我们讨论到的不同生理缺陷，在 WCAG 中有更详细的描述。WCAG 是一份不断更新不断进步的标准，在撰写此文时，WCAG 的版本号为 2.1。
WAI 还开发了一套 WAI-ARIA ( Web Accessibility Initiative - Accessible Rich Internet Applications Suite )，这项技术标准指导了应该如何编写我们的代码。开发者需要遵循这份标准才能让屏幕阅读器正确地工作。简洁起见，后文中我会用"规范"来指代 WCAG 和 WAI-ARIA。
自动测试
有很多自动化检查工具检验我们的站点是否按照规范实施了。它们通常具有这些功能：元素是否遗漏了无障碍属性；页面的颜色对比度；HTML 标签的合法性。我们建议每个季度都做一次全盘的扫描。当然，如果你对这方面要求非常高，你可以将这一步检查放到 CI 或者 CD 过程里。下面罗列的是一些扫描工具，排名不分先后：
手工测试
自动测试只能覆盖很小一部分，如果你想要得到真正有意义的结果，还是需要手动测试你的站点。最好的检查方法就是 — 闭上你的眼睛只用键盘和屏幕阅读器操作你的站点。
边注：个人看法，这是我感受到做无障碍测试是一件多么困难的事情。
引导
当你紧闭双眼时，你无法使用鼠标。在黑暗中通过键盘指引你的操作可比用视觉输入困难得多。闭着眼的操作往往不如你的预期。这样检查可以发现一些被遗漏的场景。说了这么多，我想表达的是 — 提供有效的、真正起作用的键盘输入引导非常难。
听觉的复杂性
市场上有多种多样屏幕阅读器，但讲真，大多数都不大好用。使用者常常迷惑于阅读器读出来的内容。之所以会这样是因为阅读器不仅仅将文字读出来，它们还会尽可能先将界面描述出来，让使用者的脑海里有界面的大致结构。可想而知，只有在界面结构简单，使用场景单纯的情况下，阅读器才能完美运作。所以对开发者而言，最好能尽可能地简化站点结构。
矛盾
每款屏幕阅读器的表述略有不同，在不同的浏览器下表现也并不一致。你将遇到很多"灰色地带"，即使完全遵照规范实现，屏幕阅读器的表现也可能不如预期。在这种情况下，你也许要向市场占有率高的浏览器和屏幕阅读器妥协。
在实践中，我们发现以下组合值得考虑：
Jaws
Jaws 是目前市场上最资深的屏幕阅读器产品。同时也是最广泛被使用的产品之一。你需要确保它可以正常地在你的产品上工作。但 Jaws 历史太久了，以致于它并没有跟随规范更新，我们发现最适合 Jaws 的平台是 IE。
ChromeVox
撰写此文时，ChromeVox 是最新的屏幕阅读器，因此也是最贴合规范实现的。不过它才刚刚起步，使用者并不多，支持度最好的平台自然是 Chrome。
NVDA
NVDA 也是一款比较新的屏幕阅读器，对规范实现良好，它在火狐上广泛使用，表现也优秀。
关于手工测试的总结
当你在测试时发现在某个浏览上屏幕阅读器能良好运作，你也能多少放心些 — 至少满足了这部分使用者的需求。鉴于日常工作时我们所拥有的的资源有限，我的建议是优先测试上述的最佳组合，如有必要再做更大范围的测试。
