大多数开发者都熟悉现代 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 也使用无障碍功能树来提供辅助技术可以理解的表示形式。
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>
,以及诸如 hidden
和 required
之类的属性。借助这些新的 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>
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
<button id="saveChanges" type="button">Go to shop</button>