一句话结论：可访问性树（accessibility tree）是浏览器从 DOM 计算出的语义结构，每个节点只剩角色、名称和状态。它原本服务屏幕阅读器，现在也是 AI agent 读页面的主要数据模型：OpenAI 说 Atlas 里的 ChatGPT agent 用 ARIA 角色与标签理解页面结构，Microsoft 的 Playwright MCP 默认把可访问性快照而不是截图交给模型，Google 的 web.dev 在 2026 年 4 月发布了 agent 友好网站指南。而在我们免费检测工具的聚合数据里，深检成功的 72 个站中 46 个、也就是 64% 的可访问性树不合格——这是全部检查项里失败率最高的一项。
一、可访问性树是什么，agent 为什么读它
浏览器解析 HTML 得到 DOM，再从 DOM 派生出一棵更小的树：每个节点带角色（button、link、heading、textbox、table）、可访问名称（按钮上的文字、图片的 alt、表单的 label）和状态（expanded、checked、disabled）。装饰性的 div、span、CSS 类名和布局信息不在这棵树里。它是页面的语义摘要。
agent 读它而不是读截图或完整 DOM，有两个现实原因。第一是成本：一份 DOM 可能有几千个节点，可访问性树只保留有语义和可交互的部分，喂给模型的 token 少得多。第二是可靠性：视觉模型得从像素里猜哪一块能点，树直接给出角色和名字。
三家厂商的公开表述可以互相印证：
- OpenAI 帮助中心的 Publishers and Developers FAQ 写道，Atlas 里的 ChatGPT agent"使用 ARIA 标签——与支持屏幕阅读器相同的标签和角色——来理解页面结构与交互元素"，并建议按 WAI-ARIA 实践给按钮、菜单、表单加上描述性的角色、标签与状态。
- Microsoft 的 Playwright MCP 默认用
browser_snapshot返回可访问性树的 YAML 序列化，元素带引用编号，模型说"点第 3 个"就能操作；截图只是在树信息不足时的回退。 - Google 的 web.dev 文章《Build agent-friendly websites》（2026 年 4 月更新）把可访问性树称为"忽略 CSS 视觉噪声、聚焦纯粹功能的高保真地图"，并说明 agent 会把 DOM、可访问性树与视觉渲染交叉比对。
不是所有 agent 都以树为主：Anthropic 的 computer use 以截图为主要输入；OpenAI 的 Computer-Using Agent 把截图与 DOM、可访问性树分层结合。但没有一家把树当成可有可无的东西。Cloudflare Radar 在 2026 年 6 月初的数据是，面向 HTML 内容的 HTTP 请求里约 57% 来自自动化程序——这些读者里越来越多是靠这棵树导航的。
二、我们的数据：64% 不合格，且与无障碍分数不是一回事
妙蛙 GEO 的免费检测工具在深检阶段运行 Lighthouse 的 agent-accessibility-tree 审计。这个审计属于 Lighthouse 13.3 起默认包含的 agentic browsing 分类（该分类仍标注为开发中），它不是 0 到 100 的分数，而是一组确定性规则的通过与否：可交互元素是否都有可访问名称、角色与父子关系是否合法、可交互内容是否被从树里隐藏。
《86 个网站来测了 AI 可见度：近一半在配置 AI 不看的东西，三分之二栽在 AI 真正读的地方》公开的结果：
| 检查项 | 分母 | 不合格 | 比例 |
|---|---|---|---|
| 可访问性树不合格 | 72 站 | 46 | 64% |
| H1 缺失或多个 | 64 站 | 20 | 31% |
| 无 JSON-LD 结构化数据 | 68 站 | 27 | 40% |
需要强调的是，一个页面在 Lighthouse 无障碍分类拿 90 分以上，仍可能在这一项直接失败——它是二元判定。公开案例里有过：无障碍分类 92 分的站，因为一个搜索框带了 aria-expanded 与 aria-haspopup 却没有对应的 combobox 角色，整项失败。所以"我们的无障碍分数很高"不能替代这项验收。
三、六种把树弄坏的常见写法
WebAIM 对 100 万个首页的 2026 年度分析（WebAIM Million）给出了全网基线：95.9% 的首页有可检测的 WCAG 2 失败，平均每页 56.1 个错误；缺少替代文本的图片出现在 53.1% 的首页，缺少标签的表单输入 51%，空链接 46.3%，空按钮 30.6%，缺少文档语言 13.5%。同一份报告里，使用了 ARIA 的首页平均错误 59.1 个，没用 ARIA 的 42 个——ARIA 不是越多越好，写错的 ARIA 会把错误信息自信地写进树里，agent 无从分辨。
对 agent 影响最直接的六类：
- 用 div 或 span 做按钮和链接。 树里没有 button 或 link 角色，agent 不知道它能点。
- 只有图标的按钮没有名称。 搜索、购物车、关闭按钮在树里是一个空的 button。
- 参数表用 div 网格拼出来。 没有 table、row、cell 角色，agent 拿不到"这一格属于哪一列"的关系；这一点对产品页尤其致命，见《产品页 GEO 改造：把参数表变成 AI 可引用的答案》。
- 标题层级失真。 多个 H1、跳级、用加粗大字冒充标题；我们的数据里 31% 的站在 H1 上就出了问题。
- 表单没有关联 label。 输入框在树里叫 textbox，没有名字；询盘表单就是这样让 agent 填错字段的。
- 对内容用 aria-hidden，或者让隐藏元素仍能聚焦。 前者把正文从树里删掉，后者让 agent 落到不该存在的位置。
还有两类结构性问题：Shadow DOM 里的组件如果不把语义暴露出来，树会在那里断开；把关键数字放在图片里，树只能读到 alt——这也是我们编辑规范要求图中数字必须在正文重写一遍的原因。
UC Berkeley 与密歇根大学发表在 CHI 2026 的 A11y-CUA 研究提供了一个旁证：默认条件下 computer-use agent 完成了 78.3% 的任务，改成只用键盘导航的辅助技术条件后降到 41.67%，放大镜条件下 28.3%。它测的是 agent 在辅助技术使用条件下的表现，不是"网站树坏了"的直接对照实验，但方向一致——agent 对语义路径的依赖，和屏幕阅读器用户是同一种依赖。
四、怎样验收：看树，不看渲染效果
Chrome DevTools。 Elements 面板右侧的 Accessibility 标签能看到任一节点的计算角色、名称与状态；顶部的"Full-page accessibility tree"开关可以把整棵树当成主视图浏览。验收时问三个问题：每个能点的东西有没有角色和名字？标题大纲能不能当目录读？表格是不是表格？
Playwright。 page.ariaSnapshot() 输出与 Playwright MCP 相同的 YAML 树，可以写进测试断言：
- heading "工业级 X 型号参数" [level=2]
- table:
- row "额定功率 5.5 kW":
- cell "额定功率"
- cell "5.5 kW"
- button "获取报价"
- link "下载规格书"把关键页面的快照存进仓库，改版后跑对比，树的结构变化会在发布前暴露。
Lighthouse。 本地跑 --only-audits=agent-accessibility-tree，或直接用我们的免费检测。注意这是二元结果，失败时按报告里的具体规则修。
手工抽查。 用键盘 Tab 走一遍关键流程（找产品、看参数、发询盘）：每一步焦点落在哪里、屏幕上是否能看出来、按 Enter 是否触发——agent 的路径和这条路径高度重合。
五、Google 的建议，其实是无障碍清单的另一种写法
web.dev 那篇指南的核心建议可以压缩成七条：优先用 <button>、<a>、<input> 等语义元素而不是样式化的 div；必须自定义时给 role 与 tabindex；用 for 把 label 关联到输入；可点击元素设置 cursor: pointer，Google 称之为"可操作性的强信号"；保持跨页面的布局稳定，加购按钮不要在不同品类页跑到不同位置；避免透明遮罩挡住可交互元素；可交互元素不小于 8 平方像素。每一条都能对应到既有的 WCAG 条款——这不是一套新标准，是老标准第一次有了新的读者。
同一篇指南的措辞是"考虑遵循"，也没有把任何一条与排名或引用挂钩。它解决的是"agent 能不能操作你的页面"，不是"AI 会不会推荐你"。
六、验收清单
- 每页一个 H1，H2、H3 不跳级，大纲读起来像目录；
- 每个可交互元素有角色与可访问名称，图标按钮有 aria-label 或可见文字；
- 参数与对比数据用真实
<table>，带<th>与 caption； - 表单输入有关联 label，错误提示能被树读到；
- 图片有说明性 alt，图中数字在正文以文字重写；
<html lang>与内容语言一致，多语言站每个版本各自正确；- main、nav、header、footer 等 landmark 存在且不重复；
- 正文不被 aria-hidden，隐藏元素不可聚焦；
- 不使用正数 tabindex；
- 关键页面的 ariaSnapshot 进仓库，发布流程里做对比；
- Lighthouse 的 agent-accessibility-tree 通过，且每次改版后重跑。
边界声明
- 可访问性树合格是 agent 能操作页面的资格条件，与 AI 是否引用、是否推荐没有已证实的因果关系；《Schema 结构化数据在 GEO 里还有用吗？2026 年的实测结论》讨论过同类"资格与效果"的区分。
- 各厂商 agent 的感知方式不同且在快速变化；本文引用的是 2026 年 9 月前的公开表述。
- Lighthouse 的 agentic browsing 分类仍标注为开发中，规则集可能调整。
- A11y-CUA 研究测的是辅助技术使用条件下的 agent 表现，不是网站树质量的对照实验，只能作为方向性旁证。
- 我们的 86 站样本来自主动使用检测工具的网站，不代表全网。
本文事实资料来自 Google web.dev《Build agent-friendly websites》与 Chrome 开发者文档中 Lighthouse agentic browsing 评分说明、OpenAI 帮助中心 Publishers and Developers FAQ、Microsoft Playwright 文档、WebAIM Million 2026、CHI 2026 论文 A11y-CUA（UC Berkeley 与密歇根大学）、Cloudflare Radar，以及妙蛙 GEO 免费检测工具的聚合数据。
本文由妙蛙 GEO 研究团队撰写，使用 AI 辅助进行资料整理与语言校对，文中事实、来源和结论均经人工复核。