AI 编码 Agent 写完页面却不合规？Aether 用真实浏览器把无障碍修复变成可验证流程
AI 编码 Agent 很擅长生成组件，却不一定能判断页面在真实浏览器里是否可访问。只看 JSX、模板或静态 HTML，Agent 很容易漏掉对比度、可访问名称、ARIA 用法、焦点区域和地标结构等问题。更麻烦的是，给出“看起来合理”的修复并不等于修复真的生效。
Aether WCAG Scanner 是一个面向 Claude Code 的插件，也可以作为 MCP 服务被其他客户端调用。它用 Playwright 驱动 Chromium，在桌面、平板和移动端视口渲染页面，再用 axe-core 检测 WCAG 2.1 AA 问题。它的重点不是输出一张问题清单，而是把检测、修复和复测串成一个闭环。
为什么要让 Agent 看到真实页面
代码层面的推断有一个先天限制：Agent 看到的是开发者交给它的 markup，不一定是浏览器最终渲染出来的界面。CSS、响应式断点、动态内容、焦点状态和客户端路由，都可能改变实际结果。
Aether 的工作方式更接近一次自动化审计：先在浏览器中打开页面，再由 axe-core 测量渲染结果；随后针对违规项给出修复建议。常见修复会包含修正后的 HTML、对应的 WCAG 成功准则，以及技术示例。修复完成后，它还能重新扫描目标元素，报告问题是否消失，以及是否引入回归。
这使 Agent 的判断依据从“根据代码猜页面”变成“根据浏览器测量结果修改代码”。对于需要同时支持桌面、平板和手机的页面，这个差异尤其重要。
安装与第一次运行
Aether 的 README 给出了 Claude Code 插件市场安装方式：
/plugin marketplace add https://github.com/allchemylabs/claude-plugins.git /plugin install aether-wcag-scanner@allchemylabs
安装时可以配置 Allchemy Labs API key。没有 key 也能工作：扫描器和常见规则的模板修复会在本地运行；key 的作用是增加托管 insights 引擎提供的语料库修复建议。项目文档还明确说明，客户端插件是 MIT 许可，而托管服务是专有服务，因此不要把两者混为一个开源产品。
第一次扫描会安装插件依赖，并为 Playwright 下载 Chromium。文档给出的运行环境要求是 Node.js 20 或更高版本。如果安装后 MCP 服务暂时没有连接，可以等待依赖初始化完成，再运行 /reload-plugins。
安装完成后，最直接的入口是：
/wcag-scan http://localhost:3000
这个技能会按“扫描 → 检查违规项 → 应用修复 → 重新扫描 → 汇总”的顺序工作。它适合放在开发分支上运行，而不是等到上线前才一次性处理。
也可以接入任意 MCP 客户端
Aether 的服务以 npm 包 @allchemylabs/aether-wcag-scanner 发布，支持通过 stdio 接入 MCP 客户端。配置可以写成：
{
"mcpServers": {
"aether-wcag-scanner": {
"command": "npx",
"args": ["-y", "@allchemylabs/aether-wcag-scanner"],
"env": { "ALLCHEMY_API_KEY": "<your beta key>" }
}
}
}
没有 key 时，删除 env 也可以使用离线扫描。首次运行会下载 Chromium，文档提示下载量约为 150 MB。对 Codex、Cursor 或 Windsurf 用户，项目建议把仓库里的 AGENTS.md 复制到项目中，让 Agent 知道应该执行浏览器扫描，而不是只抓 HTML 后凭经验猜测。
五个工具组成一个闭环
Aether 暴露了五个 MCP 工具：
| 工具 | 用途 |
|---|---|
aether_scan_and_fix | 推荐入口；扫描 URL 或 SPA 路由，并返回带修复建议的违规项 |
aether_get_fix | 针对单个违规项获取修复或规则解释 |
aether_verify_fix | 用 Playwright 与 axe 复测修复，检查回归和合规变化 |
aether_check_html | 不打开真实页面，只分析 HTML 片段 |
aether_submit_feedback | 对修复建议评分，帮助改进指导引擎 |
如果只想先观察问题，可以把 maxFixes 设为 0，先完成扫描，再由开发者决定哪些修改应该进入代码库。这个步骤很有价值，因为自动修复并不能替代对业务语义的判断。
SPA 项目不要用 networkidle 硬等
单页应用是无障碍扫描中容易被低估的一类场景。Aether 可以接收 spa 配置，沿着客户端路由扫描多个页面：
{
"spa": {
"entryUrl": "http://localhost:4200",
"framework": "angular",
"maxRoutes": 10
}
}
framework 可以填写 angular、react 或 vue，也可以省略让工具自动检测；路由既可以通过客户端链接发现，也可以显式提供。
项目文档特别强调，它不会把 Playwright 的 networkidle 当作唯一就绪条件。长轮询和 WebSocket 会让这种等待方式长期不结束。Aether 使用 DOM 安静、框架钩子和待处理请求排空等信号组成稳定性判断；配置中如果设置 networkIdle，会被拒绝。这是一个值得借鉴的工程细节：测试“页面准备好了吗”时，应描述应用状态，而不是迷信某个浏览器事件。
它不能替代人工审计
自动扫描只能覆盖一部分无障碍障碍。Aether 的免责声明也明确指出，扫描得到“没有问题”并不代表网站符合 WCAG、ADA、欧洲无障碍法案、Section 508 或其他法律标准。团队仍需要检查内容语义、键盘操作、屏幕阅读器体验，并在必要时安排人工测试或专业审计。
比较稳妥的落地方式是：把 Aether 当作开发循环里的快速反馈层。Agent 先扫描和修复，开发者审阅差异，再由真实用户和无障碍测试人员验证关键流程。这样既能减少机械问题，也不会把法律和产品责任交给一个自动化工具。
结语：让 Agent 的“完成”有证据
Aether 的价值不只在于又增加了一个 WCAG 检测器，而在于它把 AI 编码 Agent 的输出连接到了真实浏览器和复测结果。对于登录、结算、表单、后台管理等关键页面，可以要求 Agent 在声称完成之前留下扫描与验证记录，而不是只提交一段看起来正确的前端代码。
如果你的团队已经使用 Claude Code 或其他 MCP 客户端，Aether 是一个相对清晰的试验点：先在本地页面上运行离线扫描，观察它能否发现真实问题；再决定是否接入托管修复建议。最终目标不是让自动化工具替人做无障碍判断，而是让每次修复都更接近“测量过、改过、复测过”。