ARIA 基础

ARIA（无障碍富互联网应用）是一组属性，能帮助浏览器向屏幕阅读器等辅助技术说明动态内容。你可以把它想成给网站配上隐形的手语翻译员，或加上盲文标签：当 HTML 的原生功能无法说明一个元素是什么、能做什么时，ARIA 就能补上这部分信息。例如，用 div 元素搭建的自定义下拉菜单，可以通过 ARIA 角色和相关信息，让辅助技术理解这是一个菜单、哪个选项已被选中，以及菜单处于展开还是折叠状态。原生 HTML 本身就具备无障碍支持，所以在添加 ARIA 属性之前，始终应优先使用标准元素。 请检查：看看你当前的项目中，哪些地方用 ARIA 补充了 HTML，而不是替代了 HTML。

ARIA 通过特殊属性，为 HTML 元素补充信息，主要包括角色、状态和属性。角色说明元素是什么，例如按钮、菜单或对话框；状态说明元素当前的情况，例如已展开、已选中或已禁用；属性则提供标签、描述等额外信息。这三类信息配合起来，让辅助技术能够理解并向用户传达复杂的动态界面信息，而原生 HTML 在设计时并未涵盖这些需求。

ARIA 的核心原则是 ARIA 第一法则：如果有自带无障碍支持的原生 HTML 元素可用，就优先使用它。按钮元素本身就能向屏幕阅读器说明自己的用途，也能自动处理键盘焦点，无须添加 ARIA。只有在创建自定义组件，或 HTML 缺少你需要的语义时，才使用 ARIA，例如标签页界面、实时搜索区域或可折叠的手风琴组件。

ARIA 的实际应用随处可见：表单验证系统用 aria-invalid 和 aria-describedby 让屏幕阅读器读出错误信息；模态对话框添加 aria-modal，并将键盘焦点限制在对话框内；实时记分牌用 aria-live 播报比分变化；导航菜单用 aria-expanded 和 aria-current 表明展开状态和当前位置。这些用法遵循同一个模式：ARIA 描述正在发生什么，让辅助技术能够有效地传达这些信息。

实际实现时，你需要留意更新时间和状态管理。当 JavaScript 更新内容时，你必须同步更新相应的 ARIA 属性，否则辅助技术会播报过时的信息。键盘导航需要清晰可见的焦点标识，以及合理的 Tab 键切换顺序。交互元素需要通过 aria-label 或 aria-labelledby 提供明确的标签；如果无法使用原生 disabled 属性，则必须通过 aria-disabled 传达禁用状态。

ARIA 源于 Web 无障碍倡议（WAI），旨在弥补 Web 2.0 应用中的无障碍缺口。在这类应用中，动态内容和由 JavaScript 驱动的界面打破了传统的屏幕阅读器交互模式。ARIA 规范定义了一套角色、状态和属性的分类体系，将界面元素映射到辅助技术使用的无障碍 API，从而在 DOM 与平台的无障碍层之间架起桥梁。

关于 ARIA 有效性的研究揭示了实现过程中的关键挑战。《WAI-ARIA 编写实践指南》为常见组件提供了基于证据的实现模式，并强调 ARIA 依靠角色、属性和状态之间的配合来发挥作用，而不是孤立地添加几个属性 [2]。

• W3C Web 无障碍倡议（无日期）：ARIA 的无障碍树映射机制会将 ARIA 属性转换为平台专用的无障碍 API，使屏幕阅读器能够理解自定义界面元素 [1]

术语解释：无障碍树——浏览器内部的一种结构，将 DOM 映射到无障碍 API，让辅助技术能够理解网页内容并与之交互。

ARIA 在使用不当时，会有明显的局限和风险。它无法让原本不具备无障碍支持的元素变得无障碍：给 div 添加 role="button"，并不会带来按钮功能或键盘支持，只会让屏幕阅读器把它读作按钮。屏幕阅读器对不同 ARIA 属性的支持程度各不相同，有些属性即使在现代浏览器中也得不到良好支持。ARIA 本身也无法改善移动端的无障碍体验，必须结合恰当的语义化 HTML 和触控目标。规范一直在演进，一些属性会被弃用，同时也会出现新属性，因此需要持续维护。也许最关键的问题是，ARIA 解决的是表面症状，例如播报不佳，而不是根本原因，例如选用了不合适的 HTML 元素。这会让无障碍支持变得脆弱，稍微改动实现就可能失效。