配了三年 AI 编程工具，今天才发现它的「眼睛」根本不是摄像头——Accessibility Tree 把这件事彻底变了

你的网站设计师看到的是像素，AI 编程工具看到的不是截图——是一个残障辅助工具用了三十年的底层结构。这件事把前端开发的账全变了：你的网站好不好，不只是人说了算，机器也在打分。

AI 怎么「看」你的网页

AI 编程工具控制浏览器跟你不一样。你看的是页面，它看的是Accessibility Tree（无障碍树）。

这个树是浏览器从 HTML 构建出来的语义模型，最早是给屏幕阅读器用的。每一行代码转成一个节点，节点里有四样东西：角色（这是按钮还是输入框）、名称（按钮上写的什么字）、状态（启用还是禁用）、描述（补充说明）。

AI 拿到的是这个，不是截图，不是原始 HTML，是经过浏览器过滤后的结构化文本。

截图表面的问题在于成本和精度。拿 GPT-4o 处理一张网页截图大约要花 50,000 tokens，还要花 3-8 秒才能完成一次「看→理解→点击」的循环。更要命的是它要猜坐标，两个长得像的按钮它分不清哪个是你要的。

Accessibility Tree 把这个成本直接砍到 15,000 tokens 以内，速度降到亚秒级。browser-use（Python 开源框架，2026 年 5 月已有 96,282 个 GitHub Star）把这个方案做成了产品线，它的描述是”让网站对 AI 编程工具可访问”。

微软的 Playwright MCP 把这个推到了事实标准的位置。它直接拿 accessibility snapshot 当默认输出，不再用视觉模型。rtrvr.ai 用纯 ARIA 角色做 DOM 解析，在 WebBench 上跑出了 81% 的成功率，比所有基于截图的方案都高，每次操作耗时不到一秒。

Mozilla 2026 年推出的 Tabstack 也在用同一套架构，官宣数字是比截图方案节省 60-80% tokens。

真实数据：大多数网站根本过不了关

AgentLens 的研究显示，68% 的网站存在阻碍 AI 编程工具完成基本操作的障碍，比如填不了联系表单，或者无法浏览产品列表。

WebAIM 2026 年的百万网站审计报告更直观：95.9% 的首页至少有一个可检测的 WCAG 2 失败项，平均每个页面 56.1 个错误。这是六年来第一次整体倒退，不是进步。

Cloudflare Radar 在 2026 年 5 月 30 日到 6 月 5 日这一周测到的数据更说明问题：57.2% 的 HTML 页面 HTTP 请求来自自动化 Bot，人类只有 42.8%。这个交叉比 Cloudflare CEO 预测的 2027 年提前了一年多到来。

你的下一批「访客」，很可能不是人而是一段代码。

具体哪里坏了

第一个：图标按钮没有无障碍名称。

用 div 套样式做的按钮，在 accessibility tree 里显示成 button name: “”——一个空名字。AI 编程工具知道这是按钮，但不知道它是干什么的。屏幕阅读器说「按钮」，然后就没有然后了。

第二个：状态写在 CSS class 里。

.is-open 在代码里，但 accessibility tree 里没有任何属性告诉 AI「菜单现在是打开的」。把 class=”is-open” 换成 aria-expanded=”true”，AI 编程工具立刻就能读懂当前状态。

第三个：可交互元素用的是无语义的 div。

一个 div 加了 click 事件，在 accessibility tree 里根本不出现，因为没有 role 属性告诉浏览器「这个元素是可交互的」。屏幕阅读器用户找不到它，AI 编程工具也找不到它。

怎么修

能用原生 HTML 就别用 div。 浏览器给 button 和 a 标签自动补全 role，用手写 div 模拟的按钮就缺少这一层。

给每个可交互元素起名字。 图标按钮加 aria-label，输入框用 label 标签关联。

别用 ARIA 覆盖原生语义。 ARIA 是补漏的，不是替换原生语义的。

暴露动态内容。 用 aria-expanded、aria-selected、aria-checked 这些状态属性把 JS 改的状态告诉 accessibility tree。

Chrome 自己出了审查工具

2026 年 6 月，Chrome for Developers 上线了一个新的 Lighthouse 审查分类：Agentic Browsing。专门测你的网站对 AI 编程工具是否友好。

具体检查三项：每个可交互元素是否有可编程名称；树结构是否完整；是否有布局偏移导致 AI 编程工具点击错位置。

结论

语义化 HTML 三十年没白学。你为屏幕阅读器用户写的无障碍代码，今天直接变成了 AI 编程工具能否操作你网站的门槛。修一个问题，服务两个人群，这笔账不需要额外成本。

下一个要问的不是「我的网站对用户友好吗」，是「我的网站对机器友好吗」。

你的 CI 里跑的那些 E2E 测试，那些因为 CSS 选择器断裂而失败的用例——它们不只是测试问题，它们是 AI 可操作性的诊断报告。同样的问题堵住了两扇门，修一次就够了。