如何审核无障碍功能

Rob Dodson

确定您的网站或应用是否可访问看起来是一项艰巨的任务。如果您是第一次接触无障碍功能，那么这个主题的广度可能会让您不知从何入手。毕竟，努力适应各种能力意味着需要考虑相应的多样性问题。

本博文将这些问题分解成了一个合乎逻辑的分步流程，用于审核现有网站是否提供无障碍功能。

使用键盘开始操作

对于不能或选择不使用鼠标的用户来说，键盘导航是浏览屏幕上的所有内容的主要方式。此受众群体包括有运动障碍（如重复性应力伤害 (RSI) 或瘫痪）的用户，以及屏幕阅读器用户。

为了提供良好的键盘体验，应采用符合逻辑的 Tab 键顺序和清晰可辨的焦点样式。

  • 首先，按 Tab 键浏览您的网站。元素的聚焦顺序应遵循 DOM 顺序。如果您不确定哪些元素应获得焦点，请参阅焦点基础知识，回顾相关知识。最佳实践是，用户可与或提供输入的任何控件都应可聚焦并显示焦点指示标志（例如焦点环）。

  • 自定义互动控件应可聚焦。如果您使用 JavaScript 将 <div> 转换为精美的下拉菜单，它不会自动插入到标签页顺序中。如需使某个自定义控件可聚焦，请为其提供 tabindex="0"。如果 tabindex 值大于 0，则会更改标签页顺序，并且可能会让屏幕阅读器用户感到困惑。

  • 仅将互动内容设为可聚焦。向标题等非互动元素添加 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 只能影响元素的语义，而不会影响元素的行为。您可以使用 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，请在报告中查找失败的无障碍功能测试。修正错误，提升网站的整体用户体验。

其他资源