作者：vivo 互联网前端团队 - Han Xuejian
随着海外业务拓展和欧盟等市场对无障碍要求持续明确，无障碍成为研发质量体系中的基础能力。本文介绍一套覆盖 Web 端、Vue 编码阶段和 Android App 真机页面的检测工具链：Web 端覆盖 PC 页面与 H5 页面，Chrome 插件发现运行时问题；VS Code 插件前置检测并结合大模型辅助修复；桌面端工具基于 ADB、截图和 UI XML 完成 App 检查，帮助团队形成质量闭环。
1 分钟看图掌握核心要点👇
一、背景
随着海外业务持续发展，产品需要面对更多市场、更多用户场景和更明确的合规要求，无障碍能力也从体验优化逐步变成研发质量体系中的基础能力。尤其在欧盟等市场，数字产品无障碍相关要求正在持续细化，业务侧、研发侧和测试侧对自动化检查、问题定位和修复闭环的需求明显增加。
在真实研发流程里，无障碍问题往往散落在不同阶段：代码里少了 alt，页面运行后才发现按钮没有可访问名称，App 真机测试时又暴露出 TalkBack 朗读和触控区域问题。如果这些问题都等到上线前集中排查，定位、沟通和返工成本都会被放大。
因此，我们希望解决的不是某一条规则，而是让无障碍问题在合适的阶段被发现、被定位、被修复，并最终形成可复查、可沉淀、可持续演进的质量闭环。
围绕这个目标，我们建设了一套覆盖 Web 端页面、代码编辑器和 Android App 的无障碍检测工具链：
- **Chrome 插件：**面向 Web 端页面运行时检测，覆盖 PC 页面与 H5 页面，可一键扫描页面中的无障碍问题，并展示问题原因、影响范围和修复建议。
- **VS Code 插件：**面向开发阶段，在编写 Vue 代码时实时检测无障碍问题，并支持调用大模型一键生成修复方案。
- **桌面端 App 检测工具：**面向 Android 真机页面，通过 ADB 直连手机，结合页面截图与 UI XML 结构分析 App 无障碍问题。
整体架构可以分为五层：最上层是面向不同使用场景的检测入口，中间是数据采集与分析能力，最终沉淀到统一的规则、报告和标准体系。
图：无障碍检测工具链整体架构
二、Web 端页面：基于浏览器插件的一键检测
Web 端页面检测工具同时适用于 PC 页面和 H5 页面。工具在遵循开源许可的基础上，基于开源项目 Accessibility Insights for Web 进行二次开发。底层扫描能力主要依赖 axe-core，同时结合浏览器插件的多上下文架构，实现页面注入、状态同步、结果展示和报告导出。
图：Chrome 插件对 Web 页面进行无障碍检测
从架构上看，Chrome 插件运行在多个上下文中：
- **Popup：**用户点击插件图标后看到的入口，提供快速检测、快速评估、评估、临时工具等入口。
- **Background Service Worker：**全局调度中心，负责维护状态、分发消息、协调目标页面和结果页。
- **Target Page：**被检测的真实页面，插件会向页面和 iframe 注入 Content Script。
- **Details View：**结果展示页，用于展示扫描进度、问题列表、节点详情、修复建议和报告导出。
扫描链路可以概括为：
插件侧的扫描并不是简单地把 axe-core 结果原样展示出来。扫描结果会经过规则筛选、消息装饰和结果转换：一方面根据工具内置规则决定本次要跑哪些检测项；另一方面会把失败节点、失败原因、修复建议、帮助链接等信息整理为统一的卡片模型，最终在结果页中展示。
例如页面中常见的图片缺少替代文本、表单控件缺少可访问名称、颜色对比度不足、ARIA 属性使用不正确、标题结构不合理等问题，都可以在检测后直接看到对应的失败节点、问题原因和修复建议。
图：问题详情中展示失败原因、影响节点与修复建议
这类运行时检测的价值在于，它能看到 Web 端页面真实渲染后的 DOM 状态，并覆盖 PC 页面与 H5 页面。对于很多由组件组合、条件渲染、接口数据或运行时状态造成的问题，仅靠源码扫描很难完整覆盖，而浏览器插件可以在最终页面上进行验证。
三、编码阶段：VS Code 插件实时检测与 AI 修复
如果无障碍问题只在联调或测试阶段才被发现，修复成本会明显上升。为此，我们实现了 VS Code 插件，把检测前移到开发编码阶段。
插件激活后会监听 .vue 文件的打开、保存和编辑器切换事件。当发现当前文件是 Vue 文件时，插件会抽取