面向开发者的 Web 无障碍指南

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

无障碍简介

在为我们开发的 React 原生 UI 组件套件KendoReact实现无障碍合规性（符合 Section 508、WCAG 2.0 和 WAI-ARIA 标准）的过程中，我们深入了解了无障碍设计的基础和高级知识。本文旨在向各级工程师介绍 Web 无障碍设计，并分享我们的实践经验和最佳实践。

根据 W3C 的定义，无障碍设计是指网站、工具和技术的设计和开发应确保残障人士能够使用它们。更具体地说，人们能够：感知、理解、浏览网络、与网络互动，并为网络做出贡献。

无障碍设计的一个很好的例子是：用户能否在不看屏幕的情况下使用网站。如果您无法用眼睛浏览内容或使用鼠标进行交互，那么您花费数小时开发的所有功能和细节又该如何发挥作用呢？试想一下，如果您需要聆听屏幕阅读器描述用户界面，并且导航方式不再是传统的鼠标或键盘输入，那会是怎样一番景象？

为什么无障碍设计经常被忽视

尽管无障碍设施尚未普及的原因有很多（理想情况下它应该普及），但有三个原因尤为突出。

首先，很难对不了解的事物做出恰当的调整。大多数时候，我们并非缺乏动力，而是缺乏对残障人士如何阻碍他们使用我们网站的认知。这包括对残障类型及其应对方式的了解不足。我们对问题的来龙去脉并不完全了解。

其次，要让你的应用程序具备无障碍功能，需要付出大量努力。这包括从理解你需要遵循的标准的基本前提，到在应用程序中设计所需的特性和功能。当然，接下来还需要测试你的方法是否达到了预期效果——而很多测试只能手动完成。本文介绍的实践方法可以简化这项工作，但这仍然是一项艰巨的任务。

第三种论点是经济因素，无论对错，它都主导着现代决策：在大多数情况下，只有少数客户（或用户）会受到残疾的影响，这便成为推迟在下一个版本中实施这些无障碍改进的理由。对企业而言，将精力集中在惠及大多数人的功能上，远比为一小部分用户提供改进（而这些改进可能会让用户感觉应用程序实际上没有进步）更容易令人信服。

为什么无障碍设计很重要

伦理

残障人士每天都面临着诸多挑战。如果他们是您的客户或用户，让他们能够使用您的网络应用程序是基本的人道主义体现。

市场

数据显示，全球有10亿人患有某种形式的残疾，占所有互联网用户的20%。虽然这仍然是少数群体，但人数远超大多数人的想象。

合法的

随着该领域法律法规的不断发展，您的企业越来越有可能被法律要求提供无障碍服务。我们将在下一节详细讨论这一主题。

用户体验

无障碍指南旨在帮助用户更轻松地访问和使用您的网站。同时，大多数无障碍指南还能提升网站的易用性，并直接惠及所有用户，包括非残障人士。例如，清晰易读的文本不仅能帮助视力障碍人士，也能帮助所有用户。

工程

许多优秀的无障碍实践其实也是良好的工程和设计原则。通常情况下，缺乏无障碍性是因为代码编写得不好。对于我们这些力求精益求精的人来说，无障碍性仅仅是做好本职工作的问题。

名声

拥有比竞争对手更容易访问的网站是一项竞争优势，也有助于提升品牌好感度。

SEO

搜索引擎优化 (SEO) 和网页可访问性方面的良好实践存在一些重叠之处。例如，编写语义化的 HTML 并正确使用描述性属性（例如标签）、视频转录、图像字幕以及使用标题和标头标签，都能同时提升网站的 SEO 和可访问性。

立法

全球各地的立法正朝着使网络无障碍成为强制性功能的方向发展。在美国，无障碍功能由《美国残疾人法案》（ADA）涵盖。许多发达国家也有类似的法律，例如英国的《2010年平等法案》。实际上，这些法律意味着公共部门组织和企业必须依法遵守《网络内容无障碍指南》（WCAG）。

您不仅应该考虑客户和用户，如果您的组织拥有 50 名或以上员工，您还需要确保为所有残障人士提供便利。这意味着您的内部网络工具也必须具备无障碍功能。

此外，如果您是为政府工作的承包商，除了上述规定外，您还需要在工作中遵守《康复法案》第 508 条的规定。根据法律规定，所有美国政府服务都必须遵守第 508 条。

这些法律不仅仅体现了良好的意愿。越来越多的律师事务所开始依据无障碍立法提起诉讼。《进步》杂志有一篇题为“无障碍与法律”的详细文章，可供进一步阅读。

残疾类型及无障碍最佳实践

残障主要分为四大类：听力障碍、视力障碍、运动障碍和认知障碍。每类残障又包含多种不同的情况。这些残障在网络交互中会造成不同的挑战，需要采用不同的方法来解决。接下来，我们将探讨一些针对每种残障类型的最佳实践。你会发现，这些实践大多与我们使用的底层技术无关，而是与软件设计有关。这意味着，参与开发过程的每个人都可以为提升无障碍体验做出贡献。

听力（听觉）障碍

听力障碍的程度从轻度听力损失到完全耳聋不等。帮助这些用户的最佳方法是避免仅仅依赖声音来传达关键信息。相反，应同时添加其他媒体作为辅助。例如，如果您使用视频，请确保其支持完整字幕。如果您使用音频，请提供文字稿。字幕和文字稿都应完整，不得遗漏任何关键语句。我们将在后面的段落中列出可读性指南。这些指南尤其适用于字幕和文字稿。此外，对于视频和音频，请确保将背景噪音降至最低，以便尽可能清晰地传达信息。

视觉障碍 - 低视力

为低视力人群提供便利的主要方法是确保界面清晰易读。用户界面元素需要大而清晰。然而，文本的处理则更为复杂，我们将在后面的段落中列出一些可读性指南。这些指南旨在帮助低视力人群。

对比度是另一个重要方面。用户界面中元素和颜色之间的高对比度有助于视力障碍人士。有一些工具可以检测对比度是否足以满足此类用户的需求。您可以在这里找到由 Web 无障碍倡议组织 (WAI) 推荐的工具。在当今大多数页面设计中，对比度确实存在问题。以下是一个符合 WCAG 标准的高对比度主题示例。这种高对比度与常规主题不兼容，您可能也不希望牺牲网站的视觉效果。一个不错的折衷方案是，将高对比度主题作为网站的一个选项，就像提供语言切换选项一样。

视觉障碍——失明

盲人使用屏幕阅读器。这些应用程序解析 HTML 代码，并用自然语言将其描述给用户。屏幕阅读器的开发有其特殊性，因此本文后续章节将专门讨论这些内容。此外，盲人使用的输入设备也与常人不同。使用鼠标需要视力，而盲人则需要完整的键盘支持。

视觉障碍——色盲

色盲并非单一病症，而是有多种类型。请注意，以下解释较为简化。绿色盲（也称绿色弱）是指难以感知绿色光，是最常见的色盲类型。红色盲（也称红色弱）是指难以感知红色光，较为少见。这两种色盲的视觉光谱较为相似，因此通常统称为红绿色盲。蓝色盲（也称蓝色弱）是指难以感知蓝色，非常罕见。

每种色觉障碍的严重程度也各不相同——从轻微的感知问题到完全无法感知某种颜色都有可能。当色觉部分受损时，我们使用前缀“-nomaly”；当完全无法感知某种颜色时，我们使用前缀“-nopia”。全色盲是指所有事物都呈现灰度，这种情况非常罕见。色觉障碍并非影响单一颜色，而是影响整个可见光谱。

你最初的想法可能是选择大多数色盲患者都能看到的颜色。但这并非理想之选，因为色盲的症状多种多样，不过橙色和蓝色在大多数情况下都适用。这也是为什么互联网如此偏爱蓝色的原因之一。

有些工具可以模拟色盲人士查看网站时的效果。您可以使用这些工具来检测是否存在问题，然后针对不同类型的色盲设计并添加可选主题。但这仍然需要用户能够找到并切换到相应的主题。

最有效的解决方案是不要仅仅依赖颜色来传达关键信息。你可以运用形状、符号、动画和其他创意手段来巧妙地解决这个问题。

运动障碍

快速或重复性操作、需要按住按钮的操作、有时间限制的操作——所有这些操作对于行动不便的人来说都很困难，甚至可能导致身体疼痛。你需要避免这些操作，但这并非易事。以下示例说明了原因：假设你有一个滑块，需要按住按钮才能移动。你的解决方案可能是允许通过点击按键来移动滑块，但如果移动的步长太小，结果将是一个重复性操作，并没有多大改进。总的原则是，你需要设计一个网站，使用户能够仅使用键盘或仅使用鼠标都能方便地使用它。

与晕动病和感觉超负荷相关的认知障碍（例如——癫痫）

有几种模式会导致晕动症或感官超载。通常，这些是快速变化的效果，例如抖动、强光、快速闪烁（每秒三次或更快）。重复的运动模式，无论快慢，都可能造成同样的问题。页面上重复但缓慢的运动的一个很好的例子是飘落的雪花动画，我们经常在冬季假期看到这种动画。页面内容中使用闪烁过渡效果的突然变化也会造成问题；我们应该使用平滑的过渡效果。最佳实践是避免使用会造成问题的效果，但如果必须使用，则应允许用户禁用它们，作为一种折衷方案。

认知障碍 - 学习困难

简洁至上。简化你的场景，简化你的界面，避免杂乱无章。使用简单的语言，避免使用华丽的辞藻。始终提供清晰简洁的说明。信息量应遵循“恰到好处”的原则——信息太少不够用，信息太多又会让一些用户分心。避免设置时间限制，以免给用户带来不必要的压力。

认知障碍——阅读障碍

阅读障碍是一种影响阅读能力的障碍：患者可能会混淆字母，或者看到字母旋转或拥挤在一起。以下段落将列出一些提高可读性的指导原则，这些原则尤其适用于应对阅读障碍带来的挑战。

提高可读性的技巧

良好的可读性确保您的网站能够被多种残障人士访问：清晰易读的字幕和文字稿可以帮助听力障碍人士，而清晰易读的文本则有助于视力障碍或阅读障碍人士。一个经验法则是使用简洁明了的无衬线字体，并采用较大的字号。

空间很重要。例如，过长的文字难以阅读，因此每行字数限制在 70 个字符以内。字幕建议每行字数限制在 35 个字符以内。要留出足够的空间，让字符之间有足够的呼吸空间——1.5 倍行距即可。说到空间，全部大写的文本难以阅读，所以请使用大小写混合。阅读速度也很重要，因此不要让文本自动翻页，字幕也应保持每个单词在屏幕上至少显示 0.3 秒。

关键在于对比。背景图片通常会遮挡文字。好的字体会在字母周围添加边框以增强对比度，但更好的做法是完全避免使用背景图片，而是提供一个与文字形成鲜明对比的纯色背景。

IT 行业开发了一些非常棒的免费专业字体，这些字体都针对易读性进行了优化。您可以考虑使用其中一些。Opendyslexic和Inter就是很好的例子。

辅助技术简介

辅助技术是行业术语，涵盖所有旨在帮助残障人士的软件和硬件。输入设备包括口控杆、头控杆、大型轨迹球、专用键盘、语音识别软件等。输出设备包括屏幕放大镜、屏幕阅读器、盲文显示器、助听器、自然语言界面软件等等。其中一些设备增强了现有技术，另一些则提供了与计算机交互的替代方式。

大多数辅助技术都在操作系统层面运行，Web 开发人员无需进行任何额外操作即可使其正常运行。然而，屏幕阅读器的情况则略微复杂一些。屏幕阅读器的工作原理本质上是解析 HTML 代码，然后用自然语言进行描述和解释。语音描述的质量直接取决于代码的质量。因此，对于致力于提升网站可访问性的 Web 开发人员来说，屏幕阅读器自然是首要考虑因素。在接下来的段落中，我们将探讨一些针对屏幕阅读器优化 Web 资源的最佳实践。

针对屏幕阅读器进行优化

编写语义化的 HTML

帮助屏幕阅读器正常工作的最佳实践是编写语义化的 HTML——也就是说，编写有效的 HTML，遵循最佳实践，并根据元素的预期用途使用它们。例如，如果某个元素看起来和行为都像一个按钮，那就把它做成一个按钮，而不是一个……

如果是标题，请使用标签，而不是内联 CSS。

HTML元素语义的正式定义可以在HTML的现行标准中找到。

当然，现实生活中事情并非如此简单。这就引出了接下来的章节。

遵循规范

与任何基础技术一样，互联网也有多个标准化机构。万维网联盟 (W3C)就是其中之一，而Web 无障碍倡议组织 (WAI ) 则是其组成部分。作为开发者，我们需要遵循由 WAI 制定的Web 内容无障碍指南 (WCAG)，它是 Web 无障碍的通用标准。

我们在讨论不同类型的残疾时提到的设计实践，在 WCAG 中有更详细的描述。需要注意的是，WCAG 是一个不断发展完善的动态标准。截至撰写本文时，最新版本为 2.1。

WAI 制定了Web 无障碍倡议 - 无障碍富互联网应用套件 (WAI-ARIA)，这是编写代码的技术标准。作为开发人员，我们需要遵循此规范，屏幕阅读器才能正常工作。为简洁起见，在接下来的段落中，我将把 WCAG 和 WAI-ARIA 统称为“规范”。

自动化测试

市面上有很多扫描器可以自动检查，涵盖我们必须遵守的许多合规性规则。例如，大多数自动化软件可以轻松扫描缺失的属性和元素、检查颜色对比度或验证 HTML 代码。一个好的做法是至少每季度对网站进行一次扫描。如果您非常重视合规性，还可以将此步骤纳入持续集成 (CI/CD) 流程。以下是一些优质扫描器，排名不分先后：

手动测试

遗憾的是，自动化只能涵盖整体情况的一小部分。要想获得有意义的结果，您必须手动测试您的网站。执行此类测试最实用的方法是闭上眼睛，仅使用键盘和屏幕阅读器，在您正在测试的网站上执行各种任务。

附注：就我个人而言，正是在这个时候，我才真正意识到无障碍测试有多么困难。

闭上眼睛后，你无法使用鼠标。在黑暗中进行键盘导航远比视觉输入困难得多。一旦你看不到屏幕，许多解决方案可能就无法像你预期的那样有效。你很可能会发现一些你之前没有考虑到的情况。简而言之，提供良好且有效的键盘导航非常困难。

听觉复杂性

市面上有很多屏幕阅读器，但它们通常很难理解。你可能很难听懂它们朗读的内容。这是因为屏幕阅读器并非只是简单地将屏幕内容转换成语音。它们的任务更复杂：它们需要足够详细地描述用户界面，以便你理解其结构。只有当你在简单的场景中提供简单的结构时，屏幕阅读器才能很好地理解。因此，你需要努力简化网站的信息架构。

不一致之处

每个屏幕阅读器对规范都有其独特的解读，并且在不同的浏览器上表现略有不同。你会遇到很多灰色地带，仅仅遵循规范并不足以让所有屏幕阅读器都提供有意义的输出。在这种情况下，你的实现需要做出一些妥协，使其能够在大多数阅读器和浏览器的组合中正常工作。

在实践中，我们发现了一些适用于测试目的的组合：

大白鲨

Jaws是市面上最古老的屏幕阅读器之一。这意味着它是目前最流行的工具之一。它拥有庞大的用户群，因此您需要确保您的应用程序支持它。但由于其历史悠久，Jaws 也需要支持许多遗留的使用场景。因此，它通常不太符合规范，并且难以使用。根据我们的实践经验，我们发现 Jaws 与 IE 浏览器配合使用效果最佳。

ChromeVox

ChromeVox是最新的阅读器（截至本文撰写之时），因此也是最符合规范的。由于它推出时间较短，所以目前还不太流行。它在 Chrome 浏览器上运行效果最佳。

英伟达

NVDA是另一款符合规范的新型阅读器。它非常流行，在Firefox浏览器上运行效果最佳。

手动测试结论

当阅读器与浏览器兼容性良好时，您可以确信用户主要会在该浏览器上使用它，尽管这并非绝对，而且可能的情况有很多。然而，考虑到我们通常资源有限，一个好的做法是只关注上述常用组合并经常测试，而不是覆盖所有可能的阅读器和浏览器组合，尽管测试频率可能较低。

为了用数据佐证我们的说法，这里有一个权威的屏幕阅读器用户调查链接，该调查揭示了用户对屏幕阅读器的接受情况。

第三方检测是最后一步。

建议您邀请残障人士参与测试，或从客户那里收集无障碍访问方面的反馈。最佳实践是，在您完成内部手动和自动化测试的充分准备工作之后，再进行此类测试。我们有责任首先确保用户体验不会完全中断。只有这样，您才能获得真正有意义的用户反馈。

贵组织的最佳工作实践

教育

解决任何问题的第一步，都是要意识到问题的存在。因此，建议您投入资源，对团队进行相关培训。无论我们多么渴望做正确的事情，如果不知道如何才能让网站更易于访问，我们就无法在这方面取得进展。

此外，无障碍设计并非某个人的责任——从工程师、设计师到管理人员，所有参与 Web 应用开发的人员都必须将其纳入考量。本文的主要目的也是为了向其他工程师普及相关知识并分享经验。

文档

正如前文所述，无障碍设计并非一门精确的科学。您常常会发现自己身处灰色地带，找不到明确的解决方案。在这种情况下，最佳实践是记录您的方法。在文档中，您可以阐述当前实施方案背后的原因，并引用您选择遵循的 WCAG 规则。这份文档有助于您的团队共享知识，提高网站的一致性，并减少灰色地带。如果您需要在法庭上为自己的决定辩护，这份文档也能为您的案件提供有力支持。

KendoReact是Kendo UI套件中的一款 JavaScript UI 库。在 Progress，我们鼓励团队间共享代码和知识，确保当一个团队在某个领域取得卓越成就时，其他团队也能迅速跟上。在无障碍设计方面，文档是我们跨团队共享知识的重要组成部分。

可用性和可访问性并非同一概念。

可用性和可访问性有很多共同之处。本文讨论的大多数可访问性实践都将使所有用户受益。但可用性和可访问性并非同一概念。您可能在可用性方面投入了大量精力，但这并不意味着您也自动兼顾了可访问性。请注意，可访问性需要单独关注。

以下是我们推荐的关于可用性的阅读材料：

美国政府提供基于研究的网页设计和可用性指南。
杰夫·拉斯金的《人机交互》被认为是该主题的奠基之作。
史蒂夫·克鲁格的《别让我思考》是一本精彩的短篇小说。

正如我们之前讨论过的，无障碍设计存在诸多灰色地带。有时，无障碍解决方案可能与可用性解决方案相冲突。在这种情况下，最佳实践是不要牺牲可用性，因为可用性通常面向更广泛的用户群体。相反，我们需要发挥创造力，找到解决问题的办法。

使用辅助工具

网页无障碍设计并非易事。实现良好效果的关键在于使用无障碍工具。例如，如果您想要一个简单的博客或网站，WordPress 会自动处理无障碍问题。我们开发的 KendoReact UI 组件库也旨在为您提供同样的帮助。我们的 UI 组件从一开始就以无障碍为核心进行设计和构建，因此您无需承担大部分繁重的无障碍工作。

结论

这是我们关于网页可访问性系列文章的最后一篇，总结了KendoReact团队在开发 React UI 组件库的可访问性方面的经验。我们撰写本文的主要目的是帮助大家提高对这一主题的认识。我们希望已经成功阐述了可访问性的重要性，并为您提供了一些实用有效的思路，帮助您高效地应对构建可访问网站时遇到的挑战。欢迎在下方评论区分享您在这方面的经验。

愿无障碍的力量与你同在。

文章来源：https://dev.to/telerik/web-accessibility-guidebook-for-developers-2ep8

分享

面向开发者的 Web 无障碍指南 DEV 全球展示挑战赛，由 Mux 呈现：展示你的项目！