无障碍结构如何决定AI智能体能否读取你的网页

屏幕阅读器使用了几十年的语义结构，如今也决定了 ChatGPT、Claude、Gemini、Grok 和 Perplexity 能否读取你的页面。

2016 年，作为设计团队的负责人，我与联邦政府的首席无障碍专家进行了一系列通话，从那些对话中学到的东西比多年阅读规范还要多。自 2006 年起我就一直在构建无障碍的 Web 应用，在大多数团队连 AA 级都不愿承诺时，我就在追求 AAA 级。我学到了太多，而这始终是我最挂心的事。

即便在当时，核心观点也是：无障碍很重要，我们应当关注它。

很长一段时间里，这项工作服务于一个规模很小、常被忽视的群体，你仅仅出于原则去捍卫他们。

这场争论刚刚变得更大了。

你的网站有了一类新型访客，而它看待你页面的方式与你截然不同。它读取的是页面的精简模型，称为无障碍树（accessibility tree）——正是浏览器二十年来为屏幕阅读器构建的同一套结构。它不知道颜色是什么；它寻找的是标注良好的结构。

如果你没有它，它就找不到你。而大多数网站都没有。

数据：2026 年 6 月初，Cloudflare 报告称，网络上的自动化流量首次超过了人类流量，页面请求中自动化流量约占 57%，人类流量占 43%。

代表人类行事的智能体，正成为网络流量中增长迅速的一部分。

通过读取页面结构来理解上下文的受众，已不再是可四舍五入的误差，而是你流量的绝大部分。欢迎来到包容性设计。问题随之收窄：哪些智能体读取什么、无障碍何时成为承重结构，以及最值得优先修复的一小类问题。

我将在后续系列文章中详细介绍各大主要智能体各自如何读取页面，因为这非常有趣，但这里是一个不错的起点。

各大厂商如何读取页面

智能体读取页面有三种方式：用视觉模型查看截图、读取文档的原始 HTML，或读取浏览器从该 HTML 构建的无障碍树。

每种方式都有代价。

截图耗费大量 token，且在布局密集时容易误读。原始 HTML 充满噪音，围绕少数关键元素的是成千上万 token 的包装器和脚本——坦白说，这是糟糕的工程实践和人类粗制滥造的代码所致。

无障碍树是廉价而干净的选项：一份简短的交互元素列表，包含它们的角色、名称和状态。Google 面向开发者的官方指南建议，有能力的智能体会结合这三种方式，主要依赖结构化通道，并用图片来确认布局。这很昂贵，而且也意味着会产生 3 种不同的结果。

各厂商在从哪里开始读取上存在分歧。

• Anthropic 的 Computer Use 以视觉为先：Claude 查看截图并计算像素来放置光标，这种方式灵活，但当屏幕发生变化时很脆弱。它的浏览器扩展 Claude in Chrome 则偏向另一端——其 read_page 工具优先读取无障碍树，针对文章类页面提供 get_page_text 工具，截图只是兜底方案。
• 微软则走了相反的路线，至少对开发者而言是这样。其 Playwright MCP——让模型驱动浏览器的官方服务器——基于结构化的无障碍快照工作，完全跳过视觉，其公开前提是结构化视图优于截图。而它的消费级产品恰恰相反：在 Edge 的 Copilot 模式中，Copilot Actions 在你已登录的会话中读取并执行操作，依赖的是屏幕上呈现的内容。
• Google 的 Gemini 智能体处于混合的中间地带。它将结构化通道与视觉扫描相结合，以确认布局的实际表现，而不是押注于其中一方。对用户来说，这体现为 Chrome 中的 Gemini 及其 Auto Browse 模式，Project Mariner 则是其背后的研究型智能体。
• 最能说明问题的是 OpenAI。其 Computer-Using Agent 同时驱动 Operator 和 Atlas 浏览器，最初是从截图起步的。OpenAI 自己的发布者指南如今告诉网站所有者，Atlas 使用 ARIA 标签——即支持屏幕阅读器的那些标签和角色——来解读页面结构，并指引他们遵循标准的无障碍实践。即便是这家以像素为先的公司，也在告诉你去修复你的无障碍树。

当无障碍成为基础

无障碍并非对每个页面都同等重要，值得明确它究竟在哪些页面重要。

对于以文字为主的页面，智能体通常能应付；文字就是内容，即使结构混乱也仍可阅读。而一旦智能体需要执行操作——找到正确的按钮、填写正确的字段、在选项中做出选择、并在流程中不迷失位置——风险就会立刻上升。

交易型、多步骤和动态的界面，正是结构损坏从不便变成一堵砖墙的地方。

如果键盘用户无法完成任务，智能体通常也无法完成。

证据正变得具体。在 CHI 2026 上发表的 A11y-CUA 研究中，加州大学伯克利分校和密歇根大学的研究人员在不同条件下，让 Claude Sonnet 4.5 完成了 60 项日常网页和桌面任务。

• 在正常访问条件下，智能体完成了其中约 78%。
• 当限制为仅键盘导航——即无障碍树智能体所依赖的路径——成功率降至 42%，耗时约为两倍。
• 在放大的视口下，成功率降至 28%。

让屏幕阅读器用户陷入困境的结构性缺口，同样会让智能体陷入困境。如果键盘用户无法完成任务，智能体通常也无法完成。无障碍结构并不是与智能体就绪性并行的另一条轨道；它就是那条轨道。

可读性不等于认可

构建一个智能体能读取的页面，并不等于认可每一个读取它的智能体。Anil Dash 曾主张，其中一些产品对开放网络怀有公开的敌意，用合成的摘要取代了底层的页面和链接。

可读性与认可是两回事。

他说得对，可读性和认可确实是两回事。你可以让页面在结构上诚实，同时仍然判定某个浏览器对网络来说是一笔坏买卖，并把这两种判断分开。这项准则自有其立身之本：无论你如何看待任何 智能体，它都在为使用辅助技术的人服务。

Nielsen Norman Group 从设计的角度提出了类似的论点，将智能体视为你现在所服务的一类用户，无论你是否出于本意——这是为它们构建的理由，而不是对它们的判决。

关于代价，还有一个更尖锐的版本，它与整篇文章的基调相悖。一个可访问且语义正确的页面，是 AI 助手最容易阅读、总结并据此作答的页面类型——这使它成为最容易被窃取而不为你带来任何流量的页面类型。

如果把结构工作做好，助手可能会引用你、转述你，并把用户留在它自己的 答案里。

这简直就是反向 SEO——遵守标准，然后付出代价。欢迎来到 AI 的世界。

赢得智能体的那份可读性，可能会让你失去点击，以及随之而来的排名。这是一个真实的权衡，不是发布残缺页面的理由，但请睁大眼睛 进入。

从何处 开始

类别一：语义结构与地标

这是基础，也是成本最低的收益。原生 HTML 元素无需任何额外工作，就会在无障碍树中自我宣告。一个 <button> 就是一个智能体能找到并 信任的按钮。

一个绑定了点击事件的 <div> 是一个没有名称、没有角色的盒子，智能体只能去猜测它，而且它猜错的频率高到足以造成问题。web.dev 的指导刻意不追求花哨：使用含义符合你意图的元素，大部分结构就会 自行解决。

在这个基础之上还有两样东西。标题是智能体阅读的大纲，用以理解页面包含什么以及各部分如何关联；一个合乎逻辑的顺序，从 h1 到 h2 到 h3 而不跳级，给智能体的是一张地图，而不是 一堆杂物。

地标——导航、main、header、footer——告诉它自己正站在哪个 区域。

这些建议没有一条是新的。它们就是这个领域多年来一直在教授的结构，只是现在多了一位会照字面理解的 读者。

类别二：名称、角色与 状态

智能体可能使用的每一个控件，都需要在树中有一个名称，一个说明其身份的角色，以及——当它发生变化时——一个说明其当前状态的状态。大多数真实页面正是在这里失败的。没有标签的纯图标按钮、全都写着“阅读更多”的链接、用通用标记构建的自定义下拉菜单和模态框：每一个落入无障碍树时都是空白或 问号。

智能体能看到那里有东西，却无法分辨它 是做什么的。

ARIA 的存在是为了填补原生 HTML 无法表达的空白——赋予自定义控件它原本缺乏的角色和状态。但它附带一条严格的规则，而供应商们往往会 忽略它。

ARIA 的第一规则是不要使用 ARIA：如果原生元素已经承载了含义，就用它，因为错误或空的 ARIA 属性比没有更糟。

它不会让树留空；它会用自信而错误的信息填满树，而智能体无从得知自己正被误导。OpenAI 的指南建议发布者使用 ARIA。无障碍从业者反驳说，持久的修复是正确的标记，而不是外挂属性——而数据站在他们这一边。

这才是最该让你不安的部分。2026 年，网络无障碍六年来首次恶化。WebAIM 对前一百万个主页的年度扫描发现，其中 95.9% 存在可检测的 WCAG 失败，高于 94.8%；平均每个页面在 1,437 个元素上携带约 56 个错误——页面复杂度在一年内跃升 22.5%。ARIA 使用量增长了 27%，而最用力使用它的页面携带的错误也最多。

WebAIM 指出了一个可能的罪魁祸首：AI 辅助编码。如今正在读取你页面的同一波智能体，也在帮助生成那些使其无法读取的破损结构。

我们将在后续文章中讨论所需的那套框架。

类别三：文本替代与标签

这一类别关乎页面上真实存在、但在结构中不可见的内容，除非你把它显式化。图像是最明显的例子：没有替代文本，智能体无法区分产品照片、logo 和图表，而没有 alt 文本的链接图像会变成一个指向虚无的链接。WebAIM 年复一年地发现，缺失的替代文本仍是网络上最常见的失败之一。

智能体无法填写它无法命名的字段。

表单字段是同一问题的另一个场景。智能体无法填写它无法命名的字段，因此与其输入绑定的标签，就是完成结账与放弃结账之间的差别。

修复方案平淡且众所周知：为有意义的图像提供真实的替代文本，为装饰性图像提供空 alt，并为每个输入提供程序化标签。

类别四：反馈与稳定布局

最后一个类别关乎智能体行动之后发生的事。状态必须被播报，而不仅仅是显示。如果确认仅以视觉变化的形式出现，智能体就会当作什么都没发生。

如果确认仅以视觉变化的形式出现，智能体就会当作什么都没发生。

从未到达树中的结果、错误或状态更新会让智能体猜测；live region 和受管焦点就是你告诉它页面已移动的方式。

而布局必须保持不动。

当同一个控件在每个页面上位于不同位置时，回退到截图的智能体会失去立足点，因此一致性不再只是打磨问题，而变成智能体能否找到该事物的问题。

这项工作早已被明确规定，而且已经很多年了

这是令人安心的部分，在一篇关于新技术的文章中很少见。你并没有被要求为某种专有的新格式做优化。智能体需要你页面的东西，正是无障碍社区一直以来所要求的：语义标记、命名控件、真实的文本替代、诚实的状态、稳定的布局。

这项工作过去只为使用辅助技术的人支付一次回报。现在它支付两次，因为同样的结构正是机器所读取的。

所以把它当作分诊，而不是重建。不要试图让每个页面都能防住 agent。找到 agent 必须采取行动的流程——结账、预订、账户变更——先让这些流程清晰可读。

打开浏览器的开发者工具，查看该流程的无障碍树（accessibility tree），问问自己是否只凭这棵树就能完成任务。然后只用键盘走一遍。你在哪里碰壁，agent 也会在哪里碰壁。

通过结构来阅读的受众在规模还小的时候很容易被忽视。但它已经不小了。你能看到的那部分网络正日益成为这个房间里较小的一半，而另一半正在阅读你构建的那棵树——或者你没有构建的那棵树。

需要考虑什么

在你改动任何东西之前，权衡以下几点：

• agent 是否会在页面上采取行动，而不仅仅是阅读它。静态文字风险很低；结账、预订和账户变更才是结构变得承重的地方。
• 你是否只凭无障碍树就能完成关键流程。打开你的开发者工具，看一看，然后只用键盘走一遍同样的流程。你在哪里卡住，agent 就在哪里卡住。
• 每个控件是否都有名称、角色和状态。只有图标、且文字都写着“阅读更多”的按钮和链接，正是会让 agent 陷入困境的空白之处。
• 你是否在用 ARIA 来修补本应使用原生标记的地方。错误或空的属性比没有属性更糟，因为它会用看似确凿、实则错误的信息填满整棵结构树。
• 图片、表单字段和反馈是否被明确描述。替代文本、关联标签和被播报的状态，正是让它们不至于在结构中隐形的关键。
• 布局在相似页面之间是否保持稳定。一旦退回到截图模式，当同一个控件 移动了位置，agent 就会失去它的位置。
• 可读性是否等同于认可。并非如此——你可以构建一个诚实的页面，同时仍然认为某个特定的 agent 对 网络来说是一笔糟糕的交易。

神秘特工机器人：即使你看不见它们，可访问性对 agent 也很重要 最初发表于 Medium 上的 UX Collective，人们正在那里通过高亮和回应这篇文章继续这场讨论。