Web 无障碍： 没有 ARIA 胜过乱用 ARIA

Web 无障碍： 没有 ARIA 胜过乱用 ARIA

【作者：张赐荣】

一、前言

在网页设计中，不仅仅只是说要满足界面上的美观，更需要考虑无障碍(a11y)的可用性，确保所有用户，包括视障人士、行动不便者等，都能顺畅使用产品。

ARIA（Accessible Rich Internet Applications，无障碍富互联网应用）正是 WAI（Web Accessibility Initiative）推出的重要规范之一，它为复杂 Web 应用提供了增强无障碍语义的能力。

然而，ARIA 是一把双刃剑。正如我们常说的：“没有 ARIA 胜过乱用 ARIA”。ARIA 的误用，不仅无助于改善无障碍体验，反而可能造成灾难性的负面效果。

笔者将围绕这一主题，层层深入剖析 ARIA 背后的设计哲学、基本原则、常见误区、实践案例及改进方案，帮助开发者避免掉入 ARIA 的“陷阱”，使我们能构建出真正对残障者友好的无障碍网页。

---

二、为什么说“宁可没有 ARIA 也不要乱用 ARIA？”

2.1 什么是 ARIA？

ARIA 是一套通过 HTML 属性（如 role, aria-label, aria-pressed 等）为用户界面元素添加无障碍语义的标准。

如果说 CSS 控制页面的视觉表现，ARIA 则控制页面在屏幕阅读器等辅助技术中的语义表现。例如，告诉屏幕阅读器“这是一个按钮”“这是一个菜单项”，甚至标识状态（如“被选中”或“已禁用”）。

2.2 不假思索的乱用 ARIA 为什么是糟糕的做法？

ARIA 的强大源于它可以：

• 覆盖原始语义（改变元素在辅助技术中的含义）
• 增强现有语义（补充必要的描述与状态）

正是这种“改写与增强”的特性，使 ARIA 极具风险：

✅ 正确使用，可以大幅提升无障碍体验；
❌ 错误使用，会让本就可用的元素变得不可用，甚至误导用户。

2.3 什么叫“乱用 ARIA”？

“乱用 ARIA”，主要指没有理解其规范与含义，却盲目添加 ARIA 属性，反而破坏了页面的无障碍结构。

比如：

• 滥用 role，破坏 HTML 原生语义。
• 用 aria-label 覆盖原始文本内容。
• 添加了 role="button" 却没有实现对应的键盘操作。

---

三、两大核心原则解析

在深入实践之前，必须牢牢掌握两个基本原则，这是防止“乱用 ARIA”的基石。

---

3.1 原则一：“角色”就是一种“承诺”

✅ 案例分析

代码示例：

<div role="button">确认订单</div>

这个 div 被声明为“按钮角色”，这其实是对用户、对辅助技术、对网页标准的一种承诺：

• 它应具备按钮的所有交互特性：
  • 可被聚焦（通常用 tabindex="0"）。
  • 响应 Enter、Space 键触发点击事件。
  • 有明确的可访问名称（如文本“确认订单”）。
  • 适当的状态提示（是否禁用、是否激活等）。

❌ 错误例子

比如针对上面的案例，如果你只是加了 role="button"，但没有绑定键盘事件或聚焦处理，这个按钮在视觉上也许看起来正常，但对屏幕阅读器用户而言：

• 他们会知道这是一个按钮。
• 但按下 Enter 或 Space 却毫无反应。
• 他们可能因此误判是网站故障。

这就像去商店点击“确认”按钮，却发现它取消了购物车一样糟糕。

🛠 正确实践

最优解是：
👉 直接使用 <button> 元素，而非 div + role="button" 方案。

因为 <button> 自带键盘支持、焦点管理、ARIA 语义，无需额外补救。

若非要用 div，则至少做到：

<div role="button" tabindex="0" aria-pressed="false" onclick="..." onkeydown="...">Place Order</div>

但维护成本高，出错风险大，因此不推荐。

---

3.2 原则二：ARIA 是斗篷，亦是吊带

慎重使用 ARIA，是因为它既可“覆盖”也可“增强”页面语义。

✅ 覆盖语义的例子

<a role="menuitem">关于我们</a>

本来 <a> 是链接，屏幕阅读器会提示“链接”。但加上 role="menuitem" 后，它会被读作“菜单项目”，完全改变语义。

✅ 增强语义的案例

<button aria-pressed="false">静音</button>

这里用 aria-pressed 标注了按钮状态，使用户明确知道这是一个可切换的静音按钮。

❌ 危险范例

<table role="log">

原本表格是结构化数据的标志，但添加 role="log" 后，表格特性丧失，辅助技术再也不会把它当表格看待，用户失去了表格的所有结构化导航能力。

🧠 思考：

• 什么时候“覆盖”是必要的？
  • 少数情况下，比如用 SVG 自定义组件，才需要 ARIA 全面赋予语义。
• 什么时候应该“增强”？
  • 更推荐在状态说明、额外标签说明中使用，比如 aria-label、aria-pressed、aria-hidden 等。

---

四、乱用 ARIA 的典型误区

错误方式	示例	问题
滥用 role	<div role="link">	破坏语义，缺少默认行为
多余 aria-label	<button aria-label="Submit">Submit</button>	重复信息
忽视键盘支持	<div role="checkbox">	无法用键盘操作
隐藏重要内容	<a aria-label="Go">More Info</a>	丢失上下文

---

五、最佳实践

✅ 首选原生 HTML 元素，如 <button>, <a>, <input> 等。

✅ 不要用 ARIA 覆盖原生元素已经具备的功能。

✅ 只有在没有等效 HTML 语义表达时，才考虑使用 ARIA。

✅ 为 ARIA 定义的组件，确保交互行为完整（聚焦、键盘、状态管理）。

---

六、结语

ARIA 是无障碍开发的利器，但利器也需慎用。

开发者应始终铭记：

没有 ARIA 胜过乱用 ARIA,能使用原生控件,请优先用之。

通过理解 ARIA 的原理、掌握正确的用法，借助规范与工具，我们才能真正创建出对每个用户都友好的 Web 应用。

参考资料:

• ARIA | MDN: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
• W3c ARIA: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/