ARIA 角色和属性：最佳选择比较

W3C WAI-ARIA 1.2 规范中的 ARIA 角色和属性 超过一百个，尽管其中一小部分就能解决 XHTML 和 CSS 小部件中的大多数可访问性问题。角色定义了元素是什么，属性定义了其状态或关系，但 ARIA 不会修改浏览器行为：每个添加的角色都要求使用 JavaScript 实现交互。

可访问的富互联网应用程序 (ARIA) 是一种 W3C 规范，它向本机形式没有的 HTML 元素添加语义。角色描述元素是什么（“按钮”、“选项卡”、“对话框”），而属性则描述其“状态”或“关系”（“aria-expanded”、“aria-controls”、“aria-labelledby”）。 W3C 在 使用 ARIA 中发布的 ARIA 的第一条规则很直白：如果有一个原生 HTML 元素已经可以完成这项工作，请使用它并且不要添加 ARIA。

原因是 ARIA 不会修改浏览器行为。 <div role="button"> 不会通过 Tab 获得焦点，不会响应 Enter 键或空格，并且不会随表单一起提交。它只会改变辅助技术所宣布的内容。所有交互都必须使用 JavaScript 实现并仔细管理。在 XHTML/CSS 项目中，HTML 是静态的，JS 是最少的，这意味着添加的每个 aria 角色和属性都是您的代码必须履行的承诺。

ARIA 的第二条规则要求不要改变本机语义，除非绝对必要。 <h2 role="tab"> 会破坏标题的结构，并使按区域导航的屏幕阅读器感到困惑。第三条规则要求所有 ARIA 控件都可以通过键盘操作。第四个要求不要在获得焦点的元素上使用 aria-hidden="true"。第五个，也是最容易被遗忘的，提醒我们任何交互元素都需要一个可访问的名称：没有标签的角色是一个静音按钮。

如何选择：标准在列表之前

选择角色或属性不是品味问题。按顺序应用这些标准可以避免有关 aria 角色和属性的大多数错误：

1. 是否有原生 HTML 元素？ 如果有，请使用它。 <button>、<details>、<dialog>、<input type="checkbox"> 涵盖的情况比人们想象的要多。
2. 小部件需要动态状态吗？ 如果它在打开/关闭、选择/未选择或展开/折叠之间变化，则需要状态属性（aria-expanded、aria-selected、aria-pressed）。
3. 是否需要元素之间的关系？ 关系属性（aria-controls、aria-labelledby、aria-describedby、aria-owns）连接可访问性树无法从 DOM 推断的部分。
4. 是否需要实时公告？ 实时区域（aria-live、role="status"、role="alert"）在不移动焦点的情况下解决更新。
5. 我可以维护它吗？ 没有键盘或屏幕阅读器测试的复杂 ARIA 模式比什么都没有更糟糕。

维护成本是最容易被忽视的标准。一个精心制作的“role=”tablist“”需要箭头键管理、旋转“tabindex”、“aria-selected”和“aria-controls”的同步以及正确隐藏非活动面板。如果团队无法处理这个问题，则一组带有锚点的链接更容易访问且更便宜。

Related: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

最实用 ARIA 角色对比

下表总结了在实际审计中反复出现的角色，以及对应的原生元素（如果存在）和最常见的陷阱。

角色	用途	原生替代方案	常见陷阱
button	执行动作的控件	<button>	未添加 Enter/空格键处理或 tabindex="0"
link	导航至其他 URL	<a href>	将其用于非导航操作
dialog	模态或非模态窗口	<dialog>	未在关闭时捕获焦点或将其返回
tablist / tab / tabpanel	选项卡界面	无直接替代	未将 aria-selected 与可见面板同步
menu / menuitem	应用程序菜单	<select> 或链接列表	将其用于 Web 导航菜单
alert	紧急且即时的消息	role="status"（用于非紧急）	过度使用导致屏幕阅读器饱和
status	信息更新	<output>	在更新前未将其插入 DOM
progressbar	任务进度	<progress>	未更新 aria-valuenow
tooltip	弹出描述	title（有限）	未与 aria-describedby 关联
combobox	带建议列表的字段	<datalist>（有限）	未宣布结果数量

role="alert" 和 role="status" 之间的选择是关于 aria 角色和属性的细微差别决策的一个很好的例子。 alert 中断当前屏幕阅读器的阅读； status 等待用户完成。对于表单验证错误，“alert”是合适的。对于用户写入时“找到 3 个结果”，“status”是正确的，“alert”会导致侵入。

ARIA 的属性与组合

这些属性与四个系列相关，每个系列解决一个不同的问题。

Worth a look: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

标签。 aria-label 在没有可见文本时提供名称。 aria-labelledby 引用另一个元素的 id，并且当文本已存在于屏幕上时更可取，因为它维护单一事实来源。 aria-describedby 添加了更长的描述，例如字段的帮助文本。区别很重要：名称是用户聚焦时听到的名称；描述是可以中断的附加上下文。

状态。 用于手风琴和下拉菜单的“aria-expanded”（真/假）。 “aria-selected”用于选项卡和选项。 “aria-checked”表示自定义复选框，值“mixed”表示三态状态。 aria-pressed 用于切换按钮。当元素仍然可聚焦但不可操作时为“aria-disabled”，与本机属性“disabled”相反，后者将其从 Tab 键顺序中删除。

关系。 aria-controls 指示按钮控制哪个元素。当 DOM 不反映视觉关系时，“aria-owns”会重新组织可访问性树。 aria-activedescendant 允许您在宣布活动元素（组合框中的常见模式）时保持对容器的关注。

实时区域。 aria-live="polite" 或 "assertive" 定义紧急程度。 aria-atomic="true" 会导致整个区块被公布，而不仅仅是修改的部分。已宣布更改的“aria-relevant”过滤器。

一个经常被忽视的细节：ARIA 属性仅适用于具有有效角色的元素。没有角色的 <div> 上的 aria-expanded 将不会被宣布。 ARIA 布尔值是文本字符串（“true”、“false”），而不是 JavaScript 布尔值；将 aria-expanded="false" 写入布尔属性会产生不一致的结果。

小部件访问错误

该错误主要是由于 ARIA 与 HTML 结构错误有关。 在已有 <nav> 可用时，向 <div> 添加 role="navigation" 会导致区域重复并干扰地标导航。

Related: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

第二个错误是焦点。打开时不移动焦点、打开时不捕获焦点、关闭时不将其返回到触发器的模态小部件会让键盘用户在不可见的内容中导航。原生的“

”元素解决了部分问题，但不是全部：返回焦点仍然是开发人员的责任。

第三个错误是使用 aria-hidden 隐藏仍然可聚焦的元素。一个设置了 aria-hidden="true" 但没有 display: none 或 visibility: hidden 的关闭菜单，其链接仍保留在 Tab 顺序中，导致用户聚焦到不可见元素。正确的做法是同时在视觉上和可访问性树中将其隐藏。

If you are shopping: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

第四个错误是缺少可访问名称。带有单个 SVG 图标的 <button> 需要带有文本的 aria-label 或 <span class="visually-hidden">。装饰性 SVG 需要 aria-hidden="true" 和 focusable="false"，因此 Internet Explorer 和一些较旧的浏览器不会将其包含在 Tab 键顺序中。

关于角色的说明和 ARIA 的属性

没有工具可以代替实际屏幕阅读器的测试，但各种工具的组合可以检测 aria 角色和属性中的大多数故障。

静态验证。 W3C ARIA 验证器（Nu HTML Checker 的一部分）检测不存在的角色、写得不好的属性和禁止的组合。 ax DevTools 和 Lighthouse 指出没有可访问名称且缺少强制属性的角色。

辅助功能树检查。 Chrome 和 Firefox DevTools 允许您准确地查看辅助技术接收到的辅助功能树。这是检查角色是否实际应用以及浏览器计算出的可访问名称的最快方法。

手动测试。 仅使用键盘（Tab、Shift+Tab、箭头、Enter、Space、Escape）导航整个小部件，然后使用 Windows 上的 NVDA、JAWS（如果可用）或 macOS 和 iOS 上的 VoiceOver。桌面阅读器和移动阅读器的结合涵盖了大部分真实案例。

参考文档。 W3C ARIA 创作实践指南 (APG) 包括带有键盘和代码示例的综合模式。这是发明新模式之前应该查阅的资料来源。

如何在实际 XHTML/CSS 项目中决定

在具有轻量级 CSS 和 JavaScript 的 XHTML 网站上，最具成本效益的策略是从本机 HTML 开始，仅在本机无法到达的地方添加 ARIA。具有正确的 <label>、<fieldset> 和 <legend> 的表单需要很少的 ARIA。具有“”的数据表也不会。当出现 HTML 未涵盖的模式时，ARIA 角色就会出现：选项卡、手风琴、带过滤的组合框、模式对话框和动态通知。

建议在代码本身中记录 ARIA 角色和属性的每次使用，并用注释解释其原因。当六个月后有人重构该组件时，他们会知道“aria-controls”是否仍然必要或已成为孤立的。孤立的 ARIA 属性（指向不再存在的 id）是验证器无法可靠检测到的无声故障源。

最后，将可访问性视为组件“完成”定义的一部分，而不是后续审核。从第一次提交开始就使用键盘和屏幕阅读器进行测试的具有 ARIA 角色的小部件的成本远低于审核后修复的小部件。

要点

• ARIA 角色和属性不会添加行为：没有键盘和焦点管理的角色比没有更糟糕。
• ARIA 的第一条规则是只要存在原生 HTML 就使用它； <button>、<dialog> 和 <details> 涵盖的情况比人们想象的要多。
• 属性分为标签、状态、关系和活动区域；每个家庭解决不同的问题。
• role="alert" 中断并且 role="status" 等待：错误的选择会使屏幕阅读器用户饱和。
• ARIA 布尔值是字符串（“true”/“false”），属性仅适用于具有有效角色的元素。
• 必须使用键盘和真实屏幕阅读器进行测试；验证器只能检测到一部分失败。

资料来源和进一步阅读

• WAI-ARIA — 维基百科：Web 可访问性倡议 – 可访问的富互联网应用程序 (WAI-ARIA) 是万维网联盟 (W3C) 发布的一项技术规范，…

常见问题

ARIA 角色和属性之间有什么区别？

角色定义了辅助技术的元素，例如role =“tab”或role =“dialog”。属性描述其状态或其关系，例如“aria-expanded”或“aria-labelledby”。角色应用于代表组件的元素；属性通常应用于同一元素或与其相关的元素。

我应该在什么时候使用 ARIA 而不是原生 HTML？

仅当没有 HTML 元素覆盖该模式时。 W3C ARIA 的第一条规则很明确：如果有原生元素，就使用它。选项卡、手风琴、具有过滤功能的组合框和模式对话框以及 HTML 无法自行实现的其他模式都需要 ARIA 角色。

元素具有“可访问名称”是什么意思？

可访问的名称是屏幕阅读器在聚焦元素时宣布的文本。它是根据内容、“aria-label”、“aria-labelledby”或关联的“”按照规范定义的优先级顺序计算的。没有可访问名称的交互角色是用户无法识别的控件。

为什么我的 role="button" 对键盘没有反应？

因为 ARIA 不添加行为。 <div role="button"> 需要 tabindex="0" 来接收焦点以及 Enter 和 Space 的 keydown 处理程序。最简单、最可靠的解决方案是使用原生的<button>元素，它已经包括焦点、键盘激活和表单提交。

使用 aria-hidden="true" 坏吗？

从辅助功能树中隐藏装饰性或重复内容是正确的，但它永远不应该应用于接收焦点的元素。如果可聚焦元素保留有 aria-hidden="true"，则键盘用户可能会聚焦屏幕阅读器未宣布的内容。始终将其与实际的视觉隐藏结合起来。

哪些工具可以验证 ARIA 角色和属性？

W3C Nu HTML 检查器包括 ARIA 角色和属性的验证，并检测不存在的角色或禁止的组合。 axe DevTools 和 Lighthouse 指出没有可访问名称且缺少强制属性的角色。为了验证最终结果，浏览器 DevTools 中的可访问性树检查器准确显示了辅助技术收到的内容。