ARIA 和 HTML

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

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

我们来回顾一下 ARIA 的简短历史，了解 ARIA 的重要性，以及何时以及如何更好地使用它。

ARIA 简介

ARIA 最初由网络无障碍倡议 (WAI) 组织于 2008 年制定，该组织是负责治理互联网的综合性万维网联盟 (W3C) 的一部分。

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

“WAI-ARIA，无障碍丰富互联网应用套件，定义了一种可让残障人士更轻松地访问 Web 内容和 Web 应用的方法。它尤其适用于使用 HTML、JavaScript 和相关技术开发的动态内容和高级界面控件。"

WAI 团体

无障碍功能树

ARIA 会修改不正确或不完整的代码，通过更改、公开和扩充无障碍功能树的某些部分，为 AT 的用户打造更好的体验。

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

ARIA 增强的无障碍树。

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 开发者工具开创了一种查看完整的无障碍功能树的方法，可让开发者更轻松地了解其代码对无障碍功能的影响。

何时使用 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" 添加到需要焦点通常不会接收键盘焦点的任何元素。尽可能避免使用包含正整数的标签页索引，以免出现潜在的键盘焦点顺序问题。

错误做法
<span role="button" tabindex="1">Submit</span>
正确做法
<span role="button" tabindex="0">Submit</span>
当然，如果可以的话，在这种情况下，请使用真实的 <button> 元素。

规则 4：不隐藏可聚焦元素

请勿向需要焦点的元素（包括具有 tabindex= "0" 的元素）添加 role= "presentation" 或 aria-hidden= "true"。当您将这些角色/状态添加到元素后，它会向 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 开发者工具检查无障碍树，或使用屏幕阅读器测试无障碍功能树。

HTML 中的 ARIA

虽然仅使用 HTML 元素是最佳做法，但在某些情况下也可以添加 ARIA 元素。例如，您可以在由于环境限制而需要更高层级 AT 支持的模式中，将 ARIA 与 HTML 配对，或将其用作所有浏览器未完全支持的 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 和类型来创建按钮。