ARIA 和 HTML

大多数开发者都熟悉现代 Web 的标准标记语言 超文本标记语言 (HTML)。但是,您可能不太熟悉 无障碍富互联网应用 (ARIA)(正式名称为 WAI-ARIA):它是什么、如何使用它,以及何时(以及何时)使用它。

HTML 和 ARIA 在使数字产品具有无障碍功能方面发挥着重要作用,尤其是在辅助技术 (AT)(如屏幕阅读器)方面。两者都用于将内容转换为替代格式,例如盲文或文本转语音 (TTS)。

回顾 ARIA 的简短历史、它的重要性以及何时以及如何最好地使用它。

ARIA 简介

ARIA 最初由 Web 无障碍倡议 (WAI) 小组于 2008 年开发,该小组是管理和规范互联网的总体万维网联盟 (W3C) 的一个子集。

ARIA 不是真正的编程语言,而是一组可以添加到 HTML 元素中以提高其无障碍功能的属性。这些属性使用现代浏览器中发现的无障碍功能 API 将角色、状态和属性传达给辅助技术。这种通信通过无障碍功能树进行。

WAI-ARIA,无障碍富互联网应用套件,定义了一种使 Web 内容和 Web 应用程序对残疾人士更友好的方法。它尤其有助于使用 HTML、JavaScript 和相关技术开发的动态内容和高级用户界面控件。”

WAI 小组

无障碍功能树

ARIA 修改不正确或不完整的代码,通过更改、公开和增强无障碍功能树的某些部分,为使用 AT 的用户创造更好的体验。

无障碍功能树由浏览器创建,并基于标准文档对象模型 (DOM) 树。与 DOM 树一样,无障碍功能树包含表示所有标记元素、属性和文本节点的对象。平台特定的无障碍功能 API 也使用无障碍功能树来提供辅助技术可以理解的表示形式。

The ARIA augmented accessibility tree.

ARIA 本身不会改变元素的功能或视觉外观。这意味着只有 AT 用户才会注意到使用 ARIA 的数字产品和不使用 ARIA 的数字产品之间的差异。这也意味着开发者独自负责进行适当的代码和样式更改,以使元素尽可能地具有无障碍功能。

ARIA 的三个主要功能是角色、属性和状态/值。

角色定义元素在页面或应用上的内容或作用。

<div role="button">Self-destruct</div>

属性表达与对象的特征或关系。

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

状态定义与元素关联的当前条件或数据值。

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

虽然 ARIA 的所有三个元素都可以在一行代码中使用,但这不是必需的。相反,分层 ARIA 角色、属性和状态或值,直到您完成最终的无障碍功能目标。将 ARIA 正确地合并到您的代码库中可确保 AT 用户将拥有成功且公平地使用您的网站、应用或其他数字产品所需的所有信息。

最近,Chrome DevTools 创建了一种查看完整无障碍功能树的方法,使开发者更容易了解他们的代码如何影响无障碍功能。

何时使用 ARIA

2014 年,W3C 正式发布了 HTML5 建议。它带来了一些重大变化,包括添加了地标元素,例如 <main><header><footer><aside><nav>,以及诸如 hiddenrequired 之类的属性。借助这些新的 HTML5 元素和属性,以及不断增加的浏览器支持,现在 ARIA 的某些部分变得不那么重要了。

当浏览器支持具有 ARIA 等效的隐式角色的 HTML 标记时,通常无需向元素添加 ARIA。但是,ARIA 仍然包含 HTML 的任何版本中都不可用的许多角色、状态和属性。这些属性目前仍然有用。

这就引出了最终的问题:何时应该使用 ARIA?值得庆幸的是,WAI 小组制定了 ARIA 的五个规则,以帮助您决定如何使元素具有无障碍功能。

规则 1:不要使用 ARIA

是的,您没看错。向元素添加 ARIA 本身并不会使其更易于访问。WebAIM Million 年度无障碍功能报告发现,存在 ARIA 的主页平均比没有 ARIA 的主页检测到的错误多 70%,这主要是由于 ARIA 属性的实现不当。

此规则也有例外。当 HTML 元素没有无障碍功能支持时,则需要 ARIA。这可能是因为设计不允许使用特定的 HTML 元素,或者 HTML 中不提供所需的功能或行为。但是,这种情况应该很少见。

不要:分配角色。

<a role="button">Submit</a>

:使用语义元素。

<button>Submit</button>

如有疑问,请使用 语义 HTML 元素

规则 2:不要向 HTML 添加(不必要的)ARIA

在大多数情况下,HTML 元素本身就可以很好地工作,并且不需要添加额外的 ARIA。事实上,在使用 ARIA 的开发者通常必须添加额外的代码,以使元素在交互式元素的情况下发挥作用。

不要:分配误导性的角色。

<h2 role="tab">Heading tab</h2>

:正确分配角色。

<div role="tab"><h2>Heading tab</h2></div>

当您按预期使用 HTML 元素时,可以减少工作量并获得性能更好的代码。

规则 3:始终支持键盘导航

所有交互式(未禁用的)ARIA 控件都必须可通过键盘访问。您可以将 tabindex= "0" 添加到任何需要焦点但通常不接收键盘焦点的元素。避免使用带有正整数的制表符索引,以尽可能防止潜在的键盘焦点顺序问题。

不要:添加 tabindex。

<span role="button" tabindex="1">Submit</span>

:将 tabindex 设置为 `0`。

<span role="button" tabindex="0">Submit</span>

当然,如果可以,在这种情况下请使用真正的 <button> 元素。

规则 4:不要隐藏可聚焦元素

不要将 role= "presentation"aria-hidden= "true" 添加到需要具有焦点的元素,包括具有 tabindex= "0" 的元素。当您将这些角色和状态添加到元素时,它会向 AT 发送消息,表明这些元素不重要并跳过它们。这可能会导致尝试与元素交互的用户感到困惑或中断。

不要:隐藏可聚焦元素

<div aria-hidden="true">
  <button>Submit</button>
</div>

:公开可聚焦元素

<div>
  <button>Submit</button>
</div>

规则 5:为交互式元素使用可访问的名称

交互式元素的目的需要在用户知道如何与之交互之前传达给用户。确保所有元素都具有 可访问的名称,以供使用 AT 设备的人员使用。

可访问的名称可以是元素包围的内容(在 <a> 的情况下)、替代文本或标签。

对于以下每个代码示例,可访问的名称均为“红色皮靴”。

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

有很多方法可以检查元素的可访问名称,包括使用 Chrome DevTools 检查无障碍功能树,或使用屏幕阅读器对其进行测试。

HTML 中的 ARIA

虽然单独使用 HTML 元素是最佳实践,但在某些情况下可以添加 ARIA 元素。例如,您可能会将 ARIA 与 HTML 配对,用于需要更高 AT 支持级别的模式,因为环境限制或作为并非所有浏览器都完全支持的 HTML 元素的后备方法。

当然,对于在 HTML 中实现 ARIA 也有建议。最重要的是:不要覆盖默认的 HTML 角色,减少冗余,并注意意外的副作用。

看一些示例。

不要:分配错误的角色。

<a role="heading">Read more</a>

:使用正确的角色和一个额外的链接描述。

<a aria-label="Read more about some awesome article title">Read More</a>

不要:添加冗余角色。

<ul role="list">...</ul>

:减少冗余。

<ul>...</ul>

不要:忽略潜在的副作用。

<details>
  <summary role="button">more information</summary>
  ...
</details>

:解决副作用。

<details>
  <summary>more information</summary>
  ...
</details>

ARIA 的复杂性

ARIA 很复杂,您在使用它时应始终谨慎。虽然本课中的代码示例相当简单,但创建可访问的自定义模式可能会很快变得复杂。

有很多事情需要注意,包括但不限于:键盘交互、触摸界面、AT/浏览器支持、翻译需求、环境限制、旧代码和用户偏好。如果使用不当,少量的编码知识可能会有害,或者只是令人讨厌。

抛开这些警告不谈,数字无障碍功能并非全有或全无的情况,而是一个允许像这样存在一些灰色区域的频谱。根据具体情况,多种编码解决方案可以被视为“正确”。重要的是,您要不断学习、测试并尝试使我们的数字世界对所有人更加开放。

检查您的理解情况

测试您对 ARIA 和 HTML 的知识

以下哪项是构建可访问按钮的最佳实践?

<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
不太对。当语义 HTML 元素可用时,不应使用 ARIA。
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
不太对。虽然您可以使用 CSS 将此链接样式化为按钮,但这不是最佳实践。
<button id="saveChanges" type="button">Go to shop</button>
做得好!使用正确的语义 HTML 以及类型来创建按钮。