从无障碍访问到AI智能体执行：WebMCP助力网页智能操作，降低成本提升效率

网页已具备机器接口大多数开发者认为无障碍访问是面向人类用户的一项功能。从技术层面讲无障碍访问要求网页平台解决一个更深入的问题以机器可读的形式暴露接口。早在AI智能体出现之前屏幕阅读器就已经通过角色、标签、状态和关系的结构化语义表示来访问网页无需进行像素解读也不用截图。这正是AI智能体所需要的。早在大语言模型LLM出现之前辅助技术就已经证明了核心论点机器可以导航界面语义可以超越呈现形式结构可以替代视觉。基于截图的智能体花费token去重新发现浏览器早已知晓的事实而无障碍访问树已经以结构化的形式包含了角色、名称和状态。在智能体开发工作中从基于截图的执行方式切换到基于DOM的原生执行方式后每个操作的延迟从2 - 5秒降低到了500毫秒以内token成本也降低了一个数量级。无障碍访问证明了论点现在需要下一层突破无障碍访问已经解决了智能体面临的大部分问题。它为机器提供了发现界面的方法能够暴露可用的控件、它们的名称、状态和关系。但发现并不等同于执行。无障碍访问树可以识别名为“结账”的按钮并指示其是否禁用但它无法提供该操作本身的契约例如它接受哪些输入、需要哪些前置条件以及会产生哪些状态变化。针对这一差距新兴的WebMCP技术引入了一种浏览器原生的方式用于暴露智能体可以直接调用的类型化能力。当表单字段没有明确的智能体注释时Chrome的声明式API会首先从关联的元素中推导参数描述如果没有标签则会回退到aria - description。三十年来无障碍访问要求开发者正确编写的HTML代码如今已成为智能体工具契约的主要输入。正如一位同事所说“如果我们在无障碍访问方面做得很好那么在这方面就可以事半功倍。”现代组件架构破坏了前端模式现代组件架构积极降低了无障碍访问和智能体都依赖的语义质量。当设计系统将原生按钮封装在自定义组件中时最终进入DOM的往往是一个带有生成类名且没有语义角色的div无障碍访问树只能识别为“通用”而非“按钮”。在WebMCP的声明式API下没有标签的表单字段没有可供浏览器继承的参数描述无论哪种情况智能体都无法开展工作。除了混乱的div结构虚拟化列表只渲染可见行使得视口外的内容完全无法访问客户端状态在视觉上更新但ARIA属性从未更新会让智能体基于过时的快照进行操作。这些问题的共同根源在于无障碍访问仅被视为人类用户的关注点语义层在抽象过程中被悄然破坏这如今已成为一个双重失败。为确定性进行设计人类可以容忍模糊的用户界面UI但智能体不行。每一处模糊都意味着可能行动的概率分布而概率分布可能会大规模地导致错误行动。对于现在考虑这个问题的前端团队来说可以从以下三个方面入手- 使状态可见影响某个操作是否可用的每一项客户端状态都应反映在无障碍访问树中而不仅仅是在视觉上呈现。如果购物车数量在状态存储中更新但按钮的aria - label没有随之更新智能体就会基于过时的信息进行操作。ARIA同步不是一种增强功能而是接口契约的一部分。- 确保标识符稳定CSS模块和构建时哈希会生成每次部署都会变化的类名这些类名作为选择器毫无意义。采用具有稳定、人类可读标识符的数据属性约定例如checkout.submit_order能让智能体运行时在重构、重新设计和框架迁移后仍有目标可寻。添加了一条代码检查规则当交互式元素缺少此类标识符时构建将失败。- 使操作明确如今元素的功能完全存在于JavaScript中对任何外部观察者来说都是不透明的。WebMCP所指向的方向也是鼓励团队现在开始思考的方向是将操作意图与UI语义一同暴露出来包括操作的名称、接受的输入、需要的前置条件以及产生的效果。即使没有正式的协议一致的模式也能让智能体运行时有据可依而不是靠推断。开始将智能体的可操作性视为无障碍访问的严格超集。像axe - core这样的工具已经能捕捉到相当一部分智能体故障因为它们会验证智能体所依赖的语义层。WebMCP团队为智能体网络提出的Lighthouse审计是自然的下一步。完成已开启的工作HTML为我们提供了机器可读的结构ARIA和无障碍访问对象模型赋予了我们机器可读的含义。智能体接下来需要的是机器可读的能力即不仅要知道控件是什么还要知道它能做什么、在什么条件下运行以及会产生什么效果。那些在无障碍访问方面投入精力的团队不仅打造了更具包容性的产品还构建了网页上最接近智能体兼容的用户界面。WebMCP明确了这种传承关系标签变成了参数描述ARIA元数据变成了智能体元数据语义结构成为了机器执行的基础。几十年前辅助技术就证明了这一论点机器可以导航界面语义可以超越呈现形式结构可以替代视觉。这并非一种新协议而是ARIA和无障碍访问对象模型所开启工作的延续——将机器可读的描述转化为智能体可以可靠执行的契约。