大多数开发者都熟悉现代网络的标准标记语言超文本标记语言 (HTML)。不过，您可能不太熟悉具有无障碍功能的丰富互联网应用 (ARIA)（正式名称为 WAI-ARIA）：它是什么、如何使用，以及何时使用（何时不使用）。
HTML 和 ARIA 在提高数字产品的无障碍性方面发挥着重要作用，尤其是在使用屏幕阅读器等辅助技术 (AT) 时。两者都用于将内容转换为替代格式，例如盲文或文字转语音 (TTS)。
简要回顾 ARIA 的历史，了解其重要性，以及何时和如何最好地使用它。
ARIA 简介
ARIA 最初是由无障碍网络倡议 (WAI) 组织（万维网联盟 [W3C] 的一个子集，负责管理和监管互联网）于 2008 年开发的。
ARIA 并非真正的编程语言，而是一组可添加到 HTML 元素以提高其可访问性的属性。这些属性使用现代浏览器中的无障碍功能 API 将角色、状态和属性传达给辅助技术。此通信通过辅助功能树进行。
“WAI-ARIA（无障碍丰富互联网应用套件）定义了一种让残障人士更轻松地访问 Web 内容和 Web 应用的方式。它尤其有助于处理使用 HTML、JavaScript 和相关技术开发的动态内容和高级界面控件。”
WAI 组
无障碍功能树
ARIA 会修改不正确或不完整的代码，通过更改、公开和增强无障碍树的部分内容，为使用辅助技术的用户提供更好的体验。
无障碍树由浏览器创建，并基于标准文档对象模型 (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 开发者工具创建了一种查看完整无障碍树的方法，让开发者可以更轻松地了解自己的代码对无障碍功能的影响。
何时使用 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：不要隐藏可聚焦的元素
请勿向需要获得焦点的元素（包括具有 tabindex= "0" 的元素）添加 role= "presentation" 或 aria-hidden= "true"。当您向元素添加这些角色和状态时，它会向 AT 发送一条消息，表明这些元素并不重要，应跳过它们。这可能会导致用户感到困惑，或妨碍用户尝试与元素互动。
请勿：隐藏可聚焦元素
<div aria-hidden="true"> <button>Submit</button> </div>
要：公开可聚焦元素
<div> <button>Submit</button> </div>
规则 5：为互动元素使用无障碍名称
在用户知道如何与互动元素互动之前，需要先向用户传达该元素的用途。确保所有元素都具有无障碍名称，以便使用辅助技术 (AT) 设备的人员访问。
无障碍名称可以是元素（例如 <a>）所环绕的内容、替代文本或标签。
对于以下每个代码示例，无障碍名称均为“Red leather boots”。
<!-- 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 元素。例如，您可以在需要更高级别的辅助技术支持的模式中将 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/浏览器支持、翻译需求、环境限制、旧版代码和用户偏好设置。如果使用不当，少量的编码知识可能会带来不利影响，或者只是令人烦恼。
除了上述警告之外，数字无障碍功能并非“全有或全无”的情况，而是一个允许存在此类灰色地带的范围。根据具体情况，多种编码解决方案都可以视为“正确”。 重要的是，您要不断学习、测试，并努力让我们的数字世界对所有人更加开放。