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