如何将无障碍功能纳入到团队的流程中。
提高网站的无障碍性是一项艰巨的任务。如果您是首次接触无障碍功能，可能会因为该主题的广度而不知该从何处着手。毕竟，为了适应各种各样的能力，就需要考虑相应多样的问题。
请注意，无障碍要靠团队一起努力才能实现。每个人都有自己的角色。本文概述了各个主要学科（项目经理、用户体验设计师和开发者）的标准，以便他们努力将无障碍设计最佳实践纳入到自己的流程中。
项目经理
任何项目经理的首要目标都是尽量在每个里程碑中纳入无障碍功能工作；确保无障碍功能工作与性能和用户体验等其他主题一样重要。以下是完成流程时需要注意的一些核对清单项。
- 为团队提供无障碍功能培训。
- 确定网站或应用中的关键用户历程。
- 尝试将无障碍核对清单纳入团队流程。
- 请尽可能通过用户研究来评估网站或应用。
无障碍功能培训
您可以通过许多优质的免费资源了解网站无障碍功能。 为团队留出时间来研究该主题，有助于在流程的早期就纳入无障碍功能。
Google 提供的一些资源包括：
Google 网络无障碍 - 为期数周的互动式培训课程。
无障碍功能基础知识 - 无障碍功能指南和最佳实践的书面文档。
Material 指南：无障碍设计 - 一组有关包容性设计的用户体验最佳实践。
确定关键用户历程
每个应用都有用户需要执行的一些主要操作。例如，如果您要构建一个电子商务应用，则需要让每位用户都能将商品添加到购物车。
某些操作可能次要一些，可能只会偶尔执行。例如，更改头像照片是一项不错的功能，但对于每种体验来说可能并不重要。
确定应用中的主要操作和次要操作有助于您确定后续无障碍功能工作优先级。之后，您可以将这些操作与无障碍核对清单结合使用，以跟踪进度并避免出现回归问题。
纳入无障碍功能核对清单
无障碍功能是一个非常广泛的话题，因此，列出需要考虑的重要方面清单有助于确保您涵盖了所有基础知识。
目前有许多无障碍功能核对清单，以下是一些行业示例：
有了核对清单，您就可以查看主要和次要操作，开始对仍需完成的工作进行分类。您可以对此流程进行精细的策略性规划，甚至可以构建主要和次要操作的矩阵，并确定这些流程中的每个步骤是否缺少任何无障碍功能位。
通过用户调研进行评估
与实际用户坐下来，观察他们尝试使用您的应用，这是最有效的方法。如果您要将无障碍功能改进到现有体验中，此过程可以帮助您快速确定需要改进的方面。如果您要着手开发一个新项目，那么在早期进行用户研究有助于避免花费过多时间开发难以使用或不实用的功能。
力求纳入尽可能多样化的用户群体的反馈。 考虑主要使用键盘导航或依赖辅助技术（例如屏幕阅读器或屏幕放大镜）的用户。
用户体验设计师
由于人们往往会根据自己的偏见进行设计，因此如果您没有残障，也没有残障同事，那么您可能无意中只会为部分用户设计产品。在设计过程中，问问自己“可能会依赖于此设计的用户有哪些类型？”下面列出了一些可尝试采用的做法，可让您的流程更加包容。
- 内容的色彩对比度足够高。
- 标签页顺序已定义。
- 控件具有无障碍标签。
- 您可以通过多种方式与界面互动。
内容具有良好的色彩对比度
大多数网站的主要目标是通过文字或图片向用户传达某些信息。不过，如果此类内容对比度较低，部分用户（尤其是视力障碍用户）可能难以阅读。这可能会对用户体验产生负面影响。为解决此问题，请尽量让所有文本和图片都有足够的色彩对比度。
对比度是通过比较前景色和背景色的亮度来衡量的。对于较小的文本（小于 18 磅或 14 磅粗体字的任何文本），建议对比度至少为 4.5:1。对于较大的文本，此比率可调整为 3:1。
在下图中，左侧的文本符合这些最低对比度要求，而右侧的文本对比度较低。
有很多工具可用于测量颜色对比度，例如 Google 的 Material Color Tool、Lea Verou 的 Contrast Ratio 应用和 Deque 的 aXe。
定义了标签页顺序
标签顺序是指用户按 Tab 键时元素获得焦点的顺序。对于主要使用键盘进行导航的用户，Tab 键是他们访问屏幕上所有内容的主要方式。您可以将其视为他们的鼠标光标。
理想情况下，标签页顺序应遵循阅读顺序，从页面顶部流向底部，并且更重要的内容应显示在顺序中靠前的位置。这样，使用键盘的用户便可以更高效地快速访问这些内容。
上面的模拟界面已编号，以显示标签页顺序。创建这样的模拟界面有助于确定预期的标签页顺序。然后，您可以与开发者和质量检查测试人员分享该模型，以确保其正确实现和测试。
控件具有可访问的标签
对于使用屏幕阅读器等辅助技术的用户，标签可提供原本仅以视觉形式提供的信息。例如，仅由放大镜图标组成的搜索按钮可以使用“搜索”这一无障碍标签，以帮助填补缺失的视觉提示。
以下是设计无障碍标签时要遵循的一些简单建议：
- 简洁明了 - 听长篇幅的描述可能会很乏味。
- 请勿添加控件类型或状态 - 如果控件代码编写正确，屏幕阅读器会自动读出此信息。
- 重点关注动作对应的动词 - 使用“搜索”，而非“放大镜”。
您可以考虑创建一个包含所有控件标签的模拟界面。您可以与开发团队和质量检查团队共享此信息，以便实现和测试。
多种与界面互动和了解界面的方式
我们很容易假设所有用户主要使用鼠标与网页互动。在设计时，请考虑用户会如何使用键盘与控件互动。
规划您的焦点状态！这意味着，确定当用户使用 Tab 键或按方向键将焦点移至控件时，控件将呈现什么样子。最好尽早规划这些状态，而不是在后期尝试将其强行塞入设计中。
最后，对于任何互动点，您都需要确保用户有多个方式来了解内容。尽量不要仅使用颜色来传达信息，因为有色觉障碍的用户可能会错过这些细微的提示。一个典型的示例是无效的文本字段。除了使用红色下划线来指明问题之外，不妨考虑添加一些辅助文本。这样，您就可以涵盖更多情况，并提高用户发现问题的可能性。
开发者
开发者需要将焦点管理和语义相结合，从而打造出可靠的用户体验。以下是开发者在处理网站或应用时可以注意的一些事项：
- 标签页顺序符合逻辑。
- 焦点得到妥善管理且可见。
- 交互式元素支持键盘。
- 系统会根据需要应用 ARIA 角色和属性。
- 元素已正确标记。
- 测试是自动进行的。
逻辑标签页顺序
input、button 和 select 等原生元素可免费加入 Tab 顺序，并且可通过键盘自动获得焦点。但并非所有元素都会收到相同的行为！具体而言，div 和 span 等通用元素不会选择启用标签页顺序。也就是说，如果您使用 div 创建交互式控件，则需要执行额外的工作才能使其支持键盘操作。
两个选项如下：
- 为控件提供
tabindex="0"。这至少可以使其可聚焦，但您可能需要执行额外的工作才能添加对按键操作的支持。 - 尽可能考虑为任何类似按钮的控件使用
button，而不是div或span。原生button元素非常易于设置样式，并且可免费获得键盘支持。
管理焦点
更改网页内容时，请务必通过移动焦点来引导用户的注意力。此方法非常适合在打开模态对话框时使用，这是一个典型的示例。如果依赖于键盘的用户按下按钮打开对话框，但焦点未移至对话框元素，那么他们唯一的操作方式就是按 Tab 键浏览整个网站，直到最终找到新控件。通过在新内容出现时立即将焦点移至该内容，您可以提高这些用户的体验效率。
对互动元素的键盘支持
如果您要构建轮播界面或下拉菜单等自定义控件，则需要执行一些额外的工作才能添加键盘支持。ARIA 编写实践指南是一本实用资源，其中介绍了各种界面模式以及它们应支持的键盘操作类型。
如需详细了解如何为元素添加键盘支持，请参阅 Google 的“无障碍功能基础知识”文档中的流动 tabindex 部分。
根据需要应用 ARIA 角色和属性
自定义控件不仅需要适当的键盘支持，还需要适当的语义。毕竟，从语义上讲，div 只是一个通用的分组容器。如果您使用 div 作为下拉菜单的基础，则需要依赖 ARIA 来添加其他语义，以便将控件类型传达给辅助技术。同样，ARIA 编写实践指南可以帮助您确定应使用哪些角色、状态和属性。另外，ARIA 指南中的许多说明还附有示例代码！
为元素添加标签
如需为原生输入标签，您可以使用 MDN 中所述的内置 <label> 元素。这不仅有助于您创建屏幕上的视觉提示，还会在无障碍树中为输入内容提供无障碍名称。然后，辅助技术（例如屏幕阅读器）会获取此名称，并将其读给用户。
很抱歉，<label> 不支持为自定义控件（例如使用自定义元素或简单的 div 和 span 创建的控件）提供无障碍名称。对于此类控件，您需要使用 aria-label 和 aria-labelledby 属性。
自动测试
有时偷懒也是一种好事，尤其是在测试方面。尽可能自动执行无障碍功能测试，以免您必须手动执行所有操作。目前，业界有许多出色的测试工具，可让您轻松快速地检查常见的无障碍功能问题：
aXe 由 Deque Systems 创建，可作为 Chrome 扩展程序和 Node 模块（适用于持续集成环境）使用。这段简短的 A11ycast 介绍了将 aXe 集成到开发流程中的几种不同方法。
Lighthouse 是 Google 的开源项目，用于审核渐进式 Web 应用的性能。除了检查您的 PWA 是否支持 Service Worker 和 Web 应用清单等内容外，Lighthouse 还会运行一系列最佳实践测试，包括无障碍问题测试。
总结
无障碍要靠团队一起努力才能实现。每个人都有自己的责任。本指南列出了一些关键要点，每个团队成员都可以利用这些要点快速掌握相关知识，并希望能够改进应用的整体体验。
如需详细了解无障碍功能，请务必查看我们的免费 Udacity 课程，并浏览 web.dev 上提供的无障碍功能文档。