最快验证页面可访问性的方式是打开f12控制台直接运行axe-core检测，但需确保document.readystate==='complete'、shadow dom传{shadowdom:true}参数，重点关注violations中color-contrast等硬伤，并结合accessibility inspector与手动tab测试。
不需要装插件、不依赖构建流程，打开页面按 F12 就能开始自测——但必须避开几个关键执行时机和参数陷阱，否则 axe.run() 返回空对象或漏报严重问题。
在控制台直接运行 axe-core 检测
这是最快验证当前页可访问性状态的方式，适合开发中即时反馈，也适用于上线后快速抽检。
- 确保页面已完全加载：执行前加判断
document.readyState === 'complete'，否则axe.run()可能返回空violations - 若页面含 Shadow DOM（如 Web Components 或某些 UI 库），必须传参
{shadowDom: true}，否则内部节点全被跳过 - 粘贴这行代码即可运行（CDN 加载 + 执行）：
await (await fetch('https://cdn.jsdelivr.net/npm/axe-core@4.10.2/axe.min.js')).text().then(eval); axe.run().then(console.log) - 重点关注返回对象中的
violations数组，特别是id为color-contrast、image-alt、heading-order的条目——它们对应真实影响键盘/屏幕阅读器的硬伤
用 Chrome DevTools 的 Accessibility Inspector 实时查 Role/Name/States
它不跑规则，但能立刻告诉你屏幕阅读器“看到”的是什么，比任何报告都直击语义失效本质。
- 打开方式：Cmd+Shift+P（Mac）或 Ctrl+Shift+P（Win），输入
Accessibility，选Show Accessibility面板；或右键元素 →Inspect Accessibility Properties - 重点盯三列：
Computed Role（是否为button而非generic）、Name（是否为空或仅含"icon"这类无效值）、States（如disabled是否实时同步） - 常见
Role: generic原因：<div onclick=""> 没加 <code>role="button"和tabindex="0"；<input>没配<label for="x"></label>；<dialog></dialog>fallback 时漏了aria-modal="true"手动 Tab 导航走一遍，专抓工具扫不出的焦点流断裂
自动化工具对“焦点卡死”“顺序错乱”“进不去出不来”完全无感，这部分必须人手实测。
- 禁用鼠标，全程只用
Tab/Shift+Tab/Enter/Space操作 - 关键路径必测：模态框打开后焦点是否锁在内部？关闭后是否回到触发按钮？
iframe内焦点出来后能否继续 Tab？ - 打开 Elements 面板，选中节点看右下角
Accessibility标签页，确认Focusable和Keyboard focusable是否为true - 特别注意 JS 动态插入的元素：比如
document.createElement('div')后没补role="alert"，axe 根本看不到这个节点
用 grep 快速筛 HTML 源码里三类高频缺失属性
80% 的可访问性硬伤集中在
alt、label、lang三个属性，静态扫描比等 axe 渲染更快更准。- 检查图片缺
alt：grep -n '@@##@@]*src=' index.html | grep -v 'alt="'
- 检查
input缺显式label：grep -n '<input index.html grep>
- 检查根
html标签缺lang：grep -n '
- 注意：
alt=""是合法的，但仅限纯装饰图；alt="图片"或alt="icon"属于无效值，必须重写
真正容易被忽略的是：所有动态渲染内容（React/Vue 组件、条件模板、JS 插入 DOM）都不会出现在静态 HTML 源码里，也就不会被
grep或 CLI 工具捕获——必须在真实浏览器环境里，用 axe DevTools 或 Accessibility Inspector 对每个可触发状态单独检测。 - 禁用鼠标，全程只用
