如何进行无障碍功能审查

Rob Dodson

确定您的网站或应用程序是否具有无障碍功能可能看起来是一项艰巨的任务。如果您是第一次接触无障碍功能，那么这个主题的广度可能会让您不知道从哪里开始。毕竟，为了适应各种不同的能力，意味着需要考虑各种不同的问题。

这篇文章将这些问题分解为一个逻辑的、循序渐进的过程，用于审查现有网站的无障碍功能。

从键盘开始

对于那些无法或选择不使用鼠标的用户来说，键盘导航是访问屏幕上一切内容的主要方式。这个受众群体包括有运动障碍的用户，例如重复性劳损 (RSI) 或瘫痪，以及屏幕阅读器用户。

为了获得良好的键盘体验，目标是拥有逻辑的 Tab 键顺序和清晰可辨的焦点样式。

  • 首先，在您的网站上使用 Tab 键进行浏览。元素获得焦点的顺序应遵循 DOM 顺序。如果您不确定哪些元素应获得焦点，请参阅无障碍功能学习课程中关于焦点的模块。最佳实践是，用户可以与之交互或提供输入的任何控件都应可聚焦并显示焦点指示器（例如焦点环）。

  • 自定义交互式控件应该是可聚焦的。如果您使用 JavaScript 将 <div> 变成一个精美的下拉菜单，它不会自动插入到 Tab 键顺序中。要使自定义控件可聚焦，请为其指定 tabindex="0"。tabindex 值大于 0 会更改 Tab 键顺序，并且可能会让屏幕阅读器用户感到困惑。

  • 仅使交互式内容可聚焦。向标题等非交互式元素添加 tabindex 会减慢可以看到屏幕的键盘用户的速度，并且对屏幕阅读器用户没有帮助，因为屏幕阅读器已经知道要宣布它们。

  • 如果您向页面添加新内容，请首先将用户的焦点定向到该内容，以便他们可以对其采取操作。有关示例，请参阅在页面级别管理焦点。

  • 设计您的网站，以便用户始终可以在需要时聚焦下一个元素。注意自动完成小部件和其他可能捕获键盘焦点的情况。当您希望用户与模态框而不是页面的其余部分进行交互时，可以暂时捕获焦点，但您应始终提供一种可通过键盘访问的方式来退出模态框。有关示例，请参阅模态框和键盘陷阱。

使您的焦点控制可用

如果您构建了自定义控件，请让您的用户仅使用键盘即可访问其所有功能。阅读在组件中管理焦点以了解改进键盘访问的技术。

管理屏幕外内容

许多网站都有屏幕外内容，这些内容存在于 DOM 中但不可见，例如响应式抽屉菜单中的链接或尚未显示的模态窗口内的按钮。将这些元素留在 DOM 中可能会造成令人困惑的键盘体验，尤其是对于屏幕阅读器而言，它们会宣布屏幕外内容，就好像它是页面的一部分。

有关处理这些元素的技巧，请参阅处理屏幕外内容。

使用屏幕阅读器进行测试

改进一般的键盘支持为下一步奠定了一些基础，下一步是检查页面是否具有正确的标签和语义，以及是否存在对屏幕阅读器导航的任何障碍。

如果您不熟悉辅助技术如何解释语义标记，请阅读内容结构。

  • 检查所有图像是否具有正确的 alt 文本。此实践的例外情况是，当图像主要用于演示目的并且不是内容的重要组成部分时。要表示屏幕阅读器应跳过图像，请将值设置为空字符串：alt=""。
  • 检查所有控件是否具有标签。对于自定义控件，这可能需要使用 aria-label 或 aria-labelledby。有关示例，请参阅ARIA 标签和关系。
  • 检查所有自定义控件是否具有适当的 role 以及任何必需的 ARIA 属性，这些属性用于传达其状态。例如，自定义复选框需要 role="checkbox" 和 aria-checked="true|false" 才能正确传达其状态。有关 ARIA 如何为自定义控件提供缺失语义的概述，请参阅ARIA 简介。
  • 使信息在页面中的流动有意义。由于屏幕阅读器按照 DOM 顺序导航页面，因此它们将以不合逻辑的顺序宣布您使用 CSS 在视觉上重新定位的任何元素。如果您需要某些内容更早地出现在页面中，请将其物理移动到 DOM 中更早的位置。
  • 目标是支持屏幕阅读器导航页面上的所有内容。确保网站的任何部分都不会永久隐藏或阻止屏幕阅读器访问。
    • 如果内容应该对屏幕阅读器隐藏，例如，如果它是屏幕外的或只是演示性的，请将该内容设置为 aria-hidden="true"。有关更深入的解释，请参阅隐藏内容。

熟悉屏幕阅读器

虽然学习屏幕阅读器可能看起来令人生畏，但它们实际上非常用户友好。一般来说，大多数开发人员只需掌握几个简单的键盘命令即可。

如果您使用的是 Mac，请查看此视频，了解 Mac OS 自带的屏幕阅读器 VoiceOver。如果您使用的是 PC，请查看此视频，了解 Windows 的捐赠支持的开源屏幕阅读器 NVDA。

aria-hidden 不会阻止键盘焦点

重要的是要理解 ARIA 只能影响元素的语义；它对元素的行为没有影响。您可以使用 aria-hidden="true" 使元素对屏幕阅读器隐藏，但这不会改变该元素的焦点行为。对于屏幕外交互式内容，对于屏幕外交互式内容，请使用 inert 属性以确保它真正从键盘流中移除。对于旧版浏览器，请将 aria-hidden="true" 与 tabindex="-1" 结合使用。

交互式元素应指示其用途和状态

提供关于控件将执行什么操作的视觉提示或示能性，有助于各种设备上的各种人员操作和导航您的网站。

  • 交互式元素（如链接和按钮）应与非交互式元素区分开来。当用户无法判断元素是否可点击时，他们很难导航网站或应用程序。有很多有效的方法来指示交互式元素。一种常见的做法是为链接添加下划线，以将其与周围的文本区分开来。
  • 与焦点要求类似，链接和按钮等交互式元素需要 hover 状态，以告知鼠标用户他们的指针何时悬停在可点击的内容上。但是，为了使这些元素可供其他输入方法访问，它们必须在没有 hover 状态的情况下也能区分。

利用标题和地标

标题和地标元素为您的页面提供语义结构，并大大提高辅助技术用户的导航效率。许多屏幕阅读器用户报告说，当他们第一次访问不熟悉的页面时，他们通常会尝试通过标题进行导航。

同样，屏幕阅读器还提供跳转到重要地标（如 <main> 和 <nav>）的功能。由于这些原因，重要的是要考虑如何使用页面的结构来引导用户的体验。

  • 使用 h1-h6 层次结构。将标题视为创建页面轮廓的工具。不要依赖标题的内置样式。相反，将它们视为大小相同，并为主要、次要和三级内容使用语义上合适的级别。然后使用 CSS 使标题与您的设计匹配。
  • 使用地标元素和角色，以便用户可以绕过重复内容。许多辅助技术提供快捷方式，以跳转到页面的特定部分，例如由 <main> 或 <nav> 元素定义的部分。这些元素具有隐式地标角色。您还可以使用 ARIA role 属性来显式定义页面上的区域，如 <div role="search"> 中所示。有关更多示例，请参阅语义和导航内容。
  • 除非您有使用经验，否则请避免使用 role="application"。application 地标角色告诉辅助技术禁用其快捷方式并将所有按键传递到页面。这意味着屏幕阅读器用户通常用于在页面上移动的键不再起作用，您需要自己实现所有键盘处理。

使用屏幕阅读器审查标题和地标

屏幕阅读器（如 VoiceOver 和 NVDA）提供了一个上下文菜单，用于跳到页面上的重要区域。在测试无障碍功能时，您可以使用这些菜单来概览页面，并确定您的标题级别是否合适以及正在使用哪些地标。

要了解更多信息，请参阅这些关于 VoiceOver 和 NVDA 基础知识的教学视频。

自动化流程

手动测试网站的无障碍功能可能很繁琐且容易出错。尽可能自动化测试是有益的。您可以使用浏览器扩展程序和命令行无障碍功能测试套件。

  • 页面是否通过了 aXe 或 WAVE 浏览器扩展程序的所有测试？还有其他选项可用，但这些扩展程序可以作为任何手动测试过程的有用补充，因为它们可以发现细微的问题，例如对比度不合格和 ARIA 属性缺失。
    • 如果您喜欢在命令行上工作，axe-cli 提供了与 aXe 浏览器扩展程序相同的功能，但可以从您的终端运行。
  • 为了避免回归，尤其是在持续集成环境中，请将像 axe-core 这样的库集成到您的自动化测试套件中。axe-core 是为 aXe Chrome 扩展程序提供支持的同一引擎，但它是一个命令行实用程序。
  • 如果您使用的是框架或库，它是否提供自己的无障碍功能工具？例如，Angular 的 protractor-accessibility-plugin。尽可能利用可用的工具。

使用 Lighthouse 测试 PWA

Lighthouse 是一款用于衡量您的渐进式 Web 应用 (PWA) 性能的工具。并且，它使用 axe-core 库来支持其无障碍功能测试。

如果您已经使用 Lighthouse，请在您的报告中查找失败的无障碍功能测试。修复错误以改善您网站的整体用户体验。

其他资源