ARIA、反模式与你

Lobsters Hottest 新闻
web-accessibility aria anti-patterns llm-agents apg best-practices

摘要

本文批评了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

Hacker News Top

本文解释了为什么对div或span等通用HTML元素使用aria-label违反了ARIA规范，并且会导致屏幕阅读器行为不一致，附有浏览器测试结果。

构建高效的智能体

Anthropic Engineering

Anthropic 发布了构建高效 AI 智能体的工程指南，倡导采用简单、可组合的模式以及直接使用 API，而非依赖复杂的框架。文章区分了工作流与自主智能体，并就何时使用每种架构提供了实用建议。

@ItsRoboki: https://x.com/ItsRoboki/status/2046220862546960563

X AI KOLs Timeline

# AI 智能体术语不过是新瓶装旧酒 如果你是一位经验丰富的软件工程师，却对 AI 智能体（AI Agent）的世界感到困惑，原因很可能不是技术太复杂——而是行话太多。 欢迎了解**"词汇税"**：这是一种因新造术语而产生的认知负担，让你误以为自己面对的是全新的概念，而实际上不过是你已经熟悉的老朋友换了身行头。 --- ## 什么是词汇税 每隔几年，技术圈都会经历一轮术语洗牌。某个领域起飞了，新词汇随之涌现，旧有的工程概念被重新包装，贴上新标签。 这并不总是有意为之的炒作。有时候，新词汇确实能承载细微的差别，或者为特定社区提供更精准的表达。但很多时候，它制造的困惑远比带来的清晰要多。 词汇税的本质就是：**你为了弄懂这些词在说什么，而不得不付出额外的认知成本**。 AI 智能体领域目前正在大量征收这笔税。 --- ## 逐一拆解那些花哨术语 ### "Orchestrator"（编排器） 这个词让人联想到某种神秘的 AI 大脑，在幕后统筹全局。 实际上？它就是一个**控制流管理器**。它决定先调用哪个函数，根据结果走哪条分支，什么时候结束循环。你在写业务逻辑的第一天就做过这件事。 换个说法：`main()` 函数加上一些条件判断。 --- ### "Harness"（执行框架） AI 圈子喜欢说某个模型被"装进了一个 harness"。 这翻译过来就是：**一个包装类或运行时环境**，负责管理模型调用的生命周期——处理输入输出、捕获错误、维护状态。 换个说法：适配器模式（Adapter Pattern）加上一个 try/catch 块。 --- ### "Memory Layer"（记忆层） 这个词听起来像是给 AI 装上了某种类人的记忆系统。 实际上它就是**存储和检索机制**。短期记忆是会话上下文（session context），长期记忆是数据库查询，语义记忆是向量搜索。 换个说法：缓存 + 数据库 + 搜索索引。 --- ### "Tool Use"（工具调用） 模型"学会了使用工具"，这句话读起来颇具魔幻色彩。 脱下这层外衣，它就是：**函数调用**。模型输出一个结构化的请求，系统解析它，执行对应的函数，把结果返回给模型。 换个说法：API 调用的调度与执行。 --- ### "Agentic Loop"（智能体循环） 这个术语让整个架构听起来像是某种自主意识的涌现。 它的本质是：**一个 while 循环**，每次迭代都会：获取当前状态 → 决定下一步行动 → 执行行动 → 更新状态 → 判断是否结束。 换个说法：事件循环（Event Loop），或者任何一个游戏引擎里的主循环。 --- ### "Grounding"（落地/锚定） "模型需要被 grounded"——这句话在 AI 文章里频繁出现。 它的意思是：**把模型的输出与可验证的外部数据绑定**，防止它胡说八道（即"幻觉"）。RAG（检索增强生成）是最常见的实现方式。 换个说法：数据验证 + 外部数据源注入。 --- ### "Reflection"（反思） 听起来像是 AI 在进行哲学沉思。 实际操作是：**让模型评估自己的上一个输出**，判断是否满足要求，如果不满足则重新生成。这是一个带有评判步骤的迭代优化循环。 换个说法：带校验逻辑的重试机制（retry with validation）。 --- ### "Chain"（链） LangChain 里的"链"，以及各种"prompt chain"。 这就是**函数组合（function composition）**，或者说是管道（pipeline）。输出 A 作为输入传给 B，B 的输出传给 C。 换个说法：Unix 管道。`cat file | grep keyword | sort | uniq` --- ## 那么，是不是什么都没变？ 当然不是。有几件事确实是新的，或者至少是在规模和能力上发生了质变： 1. **不确定性变成了一等公民**：传统函数给定相同输入，输出是确定的。LLM 不是。这要求你在架构层面认真对待概率性行为，而不只是在边界情况里处理它。 2. **自然语言成为了接口**：当接口是自然语言时，你没办法写一个传统意义上完整的类型规范。这对系统边界的设计提出了新要求。 3. **上下文窗口是有限资源**：你需要像管理内存一样精心管理上下文，这是一种在普通 Web 开发里不太常见的约束。 4. **涌现行为（Emergent Behavior）确实存在**：模型组合起来之后，有时会产生你没有显式编程的行为。这既是能力，也是风险。 --- ## 如何用已有知识来理解 AI 智能体 这里有一个简单的映射框架，供有经验的工程师参考： | AI 智能体术语 | 等价的工程概念 | |---|---| | Orchestrator | 控制流 / 状态机 | | Memory Layer | 缓存 + 数据库 | | Tool | 可调用函数 / API | | Agentic Loop | 事件循环 / 主循环 | | RAG | 查询 + 上下文注入 | | Reflection | 带校验的重试 | | Chain / Pipeline | 函数组合 / Unix 管道 | | Prompt Template | 带参数的字符串模板 | | Agent | 带状态的服务 + 决策逻辑 | --- ## 写在最后 词汇税不是阴谋，但它有真实的代价。它让有经验的工程师低估自己已有的能力，让新人觉得这个领域比实际上更难进入。 下次当你遇到一个陌生的 AI 术语，不妨先问自己：**"如果我是五年前，没有这个词，我会怎么描述这件事？"** 大多数时候，你会发现你早就认识它了。 AI 智能体领域确实有令人兴奋的新东西。但其中最难的部分，往往不是理解那些新概念——而是先剥掉裹在旧概念外面的那层新皮。