如何审核无障碍功能

Rob Dodson

确定网站或应用是否可访问看起来就像 繁琐的工作。如果您是第一次使用无障碍功能， 话题的广泛性可能会让您感到困惑，不知道该从何处入手。毕竟， 努力适应不同能力的人群意味着 需要考虑的一系列问题。

本博文将这些问题详细划分为一个合乎逻辑的分步流程， 审核现有网站的无障碍功能。

从键盘开始

对于不能或选择不使用鼠标的用户，键盘导航是 是覆盖屏幕上的所有内容的主要方式此受众群体包括 有运动障碍的用户，如重复性压力损伤 (RSI) 或 以及屏幕阅读器用户

为了提供良好的键盘体验，应力求采用符合逻辑的 Tab 键顺序，并清晰地显示 可识别的焦点样式。

  • 首先在您的网站中按 Tab 键。元素的聚焦顺序 应遵循 DOM 顺序。如果您不确定应接收哪些元素 请参阅“了解无障碍功能”课程中有关焦点的单元。最佳 用户可以与任何控件交互或提供输入 应可聚焦，并显示聚焦指示器（例如聚焦环）。

  • 自定义的互动式控件应可聚焦。如果您使用 JavaScript 将 <div> 插入花式下拉菜单中，它不会自动插入 Tab 顺序。若要使自定义控件可聚焦，请为其提供 tabindex="0"。 大于 0 的 tabindex 值会更改制表符顺序，并且可能会让 屏幕阅读器用户。

  • 使仅互动式内容可聚焦。将 tabindex 添加到非 标题等互动元素会减慢可以看到 屏幕，并且对屏幕阅读器用户没有帮助，因为屏幕阅读器用户 已经知道要发出通知了

  • 如果您向网页添加新内容，请将用户的注意力吸引到相关内容上 以便采取行动请参阅 在网页一级管理焦点 获取示例。

  • 合理设计网站，确保用户在浏览网站时始终能够聚焦到下一个元素 。提防自动补全 widget 和其他可能会造成陷阱的上下文 键盘焦点。当您希望用户执行以下操作时，您可以暂时抓住焦点 与模态窗口而非页面的其余部分互动，但您应该始终 提供一种键盘可访问的模态转义方式。请参阅 模态窗口和键盘陷阱 示例。

使用焦点控件

如果您构建了自定义控件，请让用户使用其所有功能 只需使用键盘即可。已读 管理组件中的焦点 了解改进键盘操控方式的技巧。

管理屏幕外内容

许多网站都有屏幕外内容，这些内容存在于 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 用户，请观看这段视频 VoiceOver、 Mac OS 自带的屏幕阅读器。如果您使用的是 PC，请查看这个 NVDA 的视频， 一款支持捐款的开源屏幕阅读器，适用于 Windows。

aria-hidden 不会阻止键盘焦点

请务必注意，ARIA 只会影响内容的语义 element;不会影响元素的行为。您可以 使用 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 地标角色可指示辅助技术停用其 快捷键，并将所有按键操作传递到页面。也就是说， 通常，屏幕阅读器用户无法在页面中四处移动， 因此，您需要自行实现所有键盘处理。

使用屏幕阅读器查看标题和位置标记

屏幕阅读器（如“旁白”和 NVDA）提供了上下文菜单，以便用户跳转至 重要区域测试无障碍功能时，您可以使用 这些菜单可了解网页的概况并确定您的标题 以及所使用的地标。

要了解详情，请观看这些介绍 VoiceOver 和 NVDA。

实现流程自动化

手动测试网站的可访问性既繁琐又容易出错。 建议您采用自动化测试方式， 尽可能多。您可以使用浏览器扩展程序和命令行无障碍功能 测试套件

  • 网页是否通过了 aXe 或 WAVE 浏览器扩展程序？还有其他一些可用选项 可以有效补充任何手动测试流程 找出微小的问题，例如对比度不足和缺少 ARIA 属性。
    • 如果您希望使用命令行 axe-cli 提供 作为 aXe 浏览器扩展程序，但可以通过终端运行。
  • 为避免性能下降，尤其是在持续集成环境中， 纳入 axe-core 之类的库， 测试您的自动化测试套件Axe-core 是驱动 aXe Chrome 扩展程序，但使用的是命令行实用程序。
  • 如果您使用框架或库，它是否提供自己的无障碍功能 工具？例如， protractor-accessibility-plugin Angular。尽可能利用可用的工具。

使用 Lighthouse 测试 PWA

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

如果您已在使用 Lighthouse，请查找无障碍功能无法使用的情况 测试数据。请修正错误，以提升 。

其他资源