VSCode本身不运行网页或直接检测a11y，需靠插件预检（如Web Accessibility、axe DevTools、HTMLHint）+ 浏览器验证（Chrome/Edge的axe或Lighthouse）闭环保障；插件仅静态分析源码，无法覆盖JS动态交互、焦点管理、屏幕阅读器朗读等运行时场景。
VSCode 本身不运行网页，也不直接检测辅助功能（a11y）——它靠插件在编辑时静态分析 HTML/JSX/Vue 等源码中的可访问性风险。真正在浏览器中运行并做动态检测，必须配合 Chrome 或 Edge 的开发者工具（如 axe DevTools、Lighthouse）。所以，想“在 VSCode 中运行并检测”，本质是：**用插件预检 + 用浏览器验证**，缺一不可。
Web Accessibility 插件：保存即扫描，但只查结构问题
robcohen 的 Web Accessibility 插件是轻量级结构检查主力，适合写代码时快速拦截常见错误。
- 它只在你保存文件（
Cmd+S）后触发，不实时监听输入；不扫描运行时 DOM，所以不会发现 JS 动态插入的button缺少aria-label - 支持的文件类型取决于语言模式：确保右下角显示的是
HTML、JavaScript React或Vue，否则插件不激活 - 默认规则较宽松，比如
region检查常误报，建议在settings.json中显式关闭："web-accessibility.rules": {"region": false} - 问题提示带 WCAG 编号（如
WCAG 4.1.2），但不提供修复代码片段——得自己补aria-labelledby或改语义标签
axe DevTools for VS Code：手动触发，覆盖更多运行时场景
axe DevTools 插件能模拟部分运行时环境，比纯静态检查更进一步，但仍有边界。
- 右键 HTML 文件 →
Analyze with axe，它会启动一个临时服务加载该文件（含内联 JS），然后跑 axe-core 扫描 - 能发现对比度不足、
alt缺失、焦点顺序混乱等，但无法处理跨 iframe 或 fetch 动态渲染的内容 - 报告里点“Show code”可跳转到对应行，但修复建议仍是文本描述，不会自动插入
role="navigation" - 若项目用 Webpack/Vite 构建，别对
dist/index.html运行它——应检查源码（src/index.html或 JSX 组件）
HTMLHint + .htmlhintrc：强制团队遵守基础 a11y 规则
如果你需要把 a11y 检查嵌入 CI 或统一开发规范，HTMLHint 配合配置文件更可控。
- 在项目根目录建
.htmlhintrc，启用硬性规则："alt-require": true、"aria-role": true、"label-required": true - 它会在编辑器里直接标红，比如
<img>标签没alt就划波浪线，比等保存后才提示更及时 - 注意：它不识别 JSX 中的
alt（如<img alt="logo" />在 React 组件里会被忽略），除非你额外配"parsers": ["html", "javascript"] - 错误信息简洁，例如：
[htmlhint] Attribute 'alt' is required.，没有上下文解释，适合已有 a11y 基础的团队
为什么不能只信 VSCode 插件？关键盲区在这儿
所有 VSCode a11y 插件都卡在同一个瓶颈：它们看不到真实用户交互后的状态。
- JS 控制的弹窗是否正确管理焦点（
focus-trap是否生效）？插件不知道 - 屏幕阅读器（NVDA、VoiceOver）实际朗读顺序是否与 DOM 顺序一致？插件测不了
- 键盘 Tab 流是否跳过隐藏元素、是否卡死在某个组件里？必须人工走一遍
- 动态更新的
aria-live区域内容变更是否被及时通告？得开 VoiceOver 才能验证
所以，VSCode 插件只是第一道过滤网，真正兜底还得靠 Chrome 的 axe 扩展或 Lighthouse 的 Accessibility 审计——打开 DevTools → Lighthouse → 选中 “Accessibility” → Generate report。
