ARIA、反模式与你
摘要
本文批评了ARIA和ARIA创作实践指南(APG)的误用,警告不要使用LLM代理从APG生成代码,并强调在可访问性方面应优先使用原生HTML而非ARIA。
<p><a href="https://lobste.rs/s/jespwh/aria_anti_patterns_you">评论</a></p>
查看缓存全文
缓存时间: 2026/06/26 22:13
# ARIA、反模式以及你
来源:https://dbushell.com/2026/06/26/aria-anti-patterns-and-you/
无 AI - 纯手工制作
2026年6月26日,星期五
请花一分钟理解一下 **ARIA**(https://www.w3.org/WAI/standards-guidelines/aria/)是什么,不是什么。ARIA,尤其是 **ARIA 创作实践指南(APG)**(https://www.w3.org/WAI/ARIA/apg/),常常被误解。我前几天读到一篇文章(https://dbushell.com/notes/2026-06-24T05:31Z/),里面有个让人捂脸的时刻:
> 而借助现代 LLM 智能体,将规范转化为可运行代码的速度惊人。把 agent 指向 APG 的模式,描述你的组件标记,就能得到一个可靠的初稿,再打磨和测试即可。
这令人担忧,而“LLM 智能体”还不是最糟糕的部分!APG **不是** 关于构建无障碍网站的“最佳实践”操作指南。它的存在是为了演示 ARIA 规范在理论上应该如何工作——不管实际支持情况如何,也不管是否存在更无障碍、无需 ARIA 的模式(确实有)。正如 Eric Bailey 指出的:
> 该指南最初是为了帮助演示 ARIA 的能力而编写的。因此,它的代码示例几乎排他性地、压倒性地、不成比例地偏向 ARIA。
> — Eric Bailey,《我希望有人在我接触 ARIA 时告诉我的事》(https://www.smashingmagazine.com/2025/06/what-i-wish-someone-told-me-aria/#the-downsides)
——这很合理,因为:
> 浏览器和辅助技术开发者可以利用本指南中的代码来评估其对 ARIA 1.2 的支持质量。
> — 《先读我》(https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/#:~:text=Except%20in%20cases,for%20ARIA%201.2》),ARIA 创作实践指南 (APG)
即使 ARIA 得到了完全支持(实际上并没有,参见 https://a11ysupport.io/),APG 仍然不是“最佳实践”指南。“最佳实践”是根本不要使用 ARIA。
> 如果你可以使用原生 HTML 元素或属性,并且 **已内置** 你所需的语义和行为,那就应该这样做,而不是重新利用一个元素并添加 ARIA 角色、状态或属性来使其可访问。
> — 2.1 ARIA 使用第一规则(https://www.w3.org/TR/using-aria/#rule1),《使用 ARIA》,W3C
APG 存在于真空中,只是为了展示 ARIA 规范。举个例子,按钮模式(https://www.w3.org/WAI/ARIA/apg/patterns/button/examples/button/)的代码里居然有这段:
```
<span role="button" tabindex="0">打印页面</span>
```
我实在想不出任何情况下应该用 `<span>` 来代替 `<button>`。在你告诉我“我无法修改我的 React(https://jsx.lol/)组件库”之前,请帮网络一个忙,删掉你的代码库吧。
公平地说,按钮示例中有一个“先读此”(https://www.w3.org/WAI/ARIA/apg/patterns/button/examples/button/#support-notice-header)的 disclosure 组件——猜猜怎么着?他们用的是 `<details>` 元素(https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details),而不是 disclosure 模式(https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/),因为 APG 并非最佳实践。
很难责怪开发者误用 ARIA 和 APG。我自己也曾困惑过。作为 W3C 文档,APG 相当吸引人。如果你理解它存在的意义,它是个有用的资源。但 ARIA 的滥用已经让网络变得更不可访问。
> 页面上 ARIA 使用量的增加与检测到的错误数量呈正相关。存在的 ARIA 属性越多,检测到的无障碍错误也越多。
> — The WebAIM Million(https://webaim.org/projects/million/#aria),WebAIM
## TL;DR
尽可能避免使用 ARIA。不要把一个该死的 LLM 指向 APG!我简直不敢相信我会这么说:如果你绝对不愿意学习或自己写代码,那就用 Google 的垃圾(https://dbushell.com/2026/05/20/google-just-spat-in-my-face/)。显然 OpenAI 正在向网络抛出 ARIA(https://adrianroselli.com/2025/10/openai-aria-and-seo-making-the-web-worse.html),看哪些能粘住。啊啊啊!我不知道了,对你的专业素养保留一些自豪感吧?
---
P.S. 说出一个不是屏幕阅读器的辅助技术。不容易吧?所以不要随意用“测试”这个词来当某个可疑做法和建议的“免罪卡”。如果你想在派对上赢下这个游戏,Declan Chidlow 的《数字无障碍技术概述》(https://vale.rocks/posts/digital-accessibility-technologies)会很有帮助。
相似文章
不要对div等通用元素使用aria-label
本文解释了为什么对div或span等通用HTML元素使用aria-label违反了ARIA规范,并且会导致屏幕阅读器行为不一致,附有浏览器测试结果。
@bibryam: 使用代理,保持主导权. https://devindickerson.dev/posts/using-agents-keeping-agency/…
一篇博客文章警告,AI 编码代理通常会默认选择流行但不适用的技术,导致技术债务,并敦促开发者在架构决策中保持主导权。
不要在静态文本元素上使用 aria-label (2024)
本文解释了为什么对 div 和 span 等静态文本元素使用 aria-label 或 aria-labelledby 是一种无障碍反模式——因为这些属性在没有角色覆盖的情况下不允许用于这些元素,并提供了正确使用的指导。
你是自己写代码,还是让AI代理来做?以及如何获得好的UI设计
探讨手动编写代码与使用AI代理之间的权衡,并提供关于如何实现良好UI设计的建议。
为AI智能体设计API
本文认为,为AI智能体设计API需要遵循与人类不同的原则,强调清晰性、明确性,并避免使用默认值,因为智能体可以阅读整个文档并编写大量代码。