多数无障碍审计止步于 axe-core 全绿。问题在于：自动化工具按问题数量算，只能覆盖约 57% 的真实无障碍问题（Deque 2024 年对 1.3 万多个页面状态的研究），而这 57% 还被高频出现的颜色对比错误拉高了。真正绊倒用户的那些问题——自定义控件里的焦点陷阱、关闭后丢焦点的 modal 栈、把装饰更新读出来的 live region、只用红色表示错误的状态、漏掉 WCAG 2.2 新增 24px 下限的 23×23px 点击目标——恰恰是自动化看不到的那一半。
下面这 12 个 Prompt 强制 AI 走两遍页面（一遍纯键盘用户，一遍屏幕阅读器用户），并把每条发现映射到具体的 WCAG 2.2 成功标准 + 1 行修复。WCAG 2.2（2023 年 10 月发布，2024 年 12 月更新，现为 ISO/IEC 40500:2025）截至 2026 年 6 月仍是事实标准——WCAG 3.0 还停留在工作草案阶段，预计 2028 年前都不会成为正式推荐标准。配合 无障碍回归审计 Prompt 把修复锁住，防止下次发版又退回去。
TL;DR
- 先跑 axe-core 或 Lighthouse 清掉省事的那 57%，再用 1-12 号 Prompt 去抓需要人工的另一半。
- 每个 Prompt 都以「映射到具名 WCAG 2.2 条目 + 1 行修复 + 1 步人工复测」收尾。
- 一定要粘真实 HTML 或组件源码——泛泛的描述只会得到泛泛、无法核实的答案。
- 推荐模型：Claude Opus 4.7 或 Sonnet 4.6（1M token 上下文，整块组件都装得下）、GPT-5.5、Gemini 3.1 Pro。三家对 ARIA 模式都推理得不错；ARIA role 要照规范核对，别信模型的记忆。
- 这些 Prompt 只做审计，不做认证。法律层面的签字（EAA、ADA）仍然需要人工无障碍测试员。
这套 Prompt 适合用在哪
- 上线前无障碍审计
- WCAG 2.1 / 2.2 AA 合规评审（欧盟《无障碍法案》经由 EN 301 549 要求的级别）
- 自定义控件无障碍评审
- 表单流无障碍
- PR 级无障碍检查
怎么用这些 Prompt
把 Prompt 粘进去，然后在写着 [paste ...] 的地方下方直接贴上真实的 HTML、JSX 或渲染后的 DOM。模型只能审计它看得到的东西——你写「一个下拉菜单」只会得到教科书式答案，而真实标记会暴露缺失的 aria-expanded，以及那个本该是 <button> 的 <div onClick>。对动态控件，除了组件源码，还要附一句状态变化说明（展开/收起、出错、加载中），因为屏阅和 live region 的行为依赖静态标记看不到的运行时状态。
1. 语义 HTML 审计
下面是页面或组件 HTML。审计语义 HTML：
(a) 标题层级（不跳级，只有一个 h1）；
(b) landmarks（header / main / nav / footer / aside）；
(c) 用列表还是 div 堆；
(d) button vs link vs div（动作用 button，导航用 link）。
每条问题给出 WCAG 2.2 条目 + 1 行修复。
[paste HTML]2. 键盘导航走查
下面是页面或组件。请以纯键盘用户身份走查。
对每个可交互元素 Tab 一遍，列出：
(a) Tab 顺序 vs 视觉顺序；
(b) 焦点可见性（依 2.4.7 及 2.4.13 焦点外观的尺寸/对比要求）；
(c) 键盘陷阱（2.1.2）；
(d) skip-link（2.4.1）；
(e) 只能用鼠标触达的控件。
每个问题标出对应 WCAG 条目。
[paste]3. 屏幕阅读器流审计
下面是页面。请描述屏幕阅读器用户（假设 NVDA 或 VoiceOver）
从加载到完成主任务会「听到」什么。标出：
(a) 装饰内容被读出；
(b) 关键信息被漏；
(c) 状态变化未被宣告。
并注明每个控件可访问名称的来源（label / aria-label / aria-labelledby）。
[paste]4. 颜色对比检查
下面是色板 + 10 组组件配色（前景文字 / 背景）。
每组给：对比度、WCAG AA 结论（正文 4.5:1，大字与 UI 组件按 1.4.11 为 3:1）、
AAA 结论（7:1）、能通过 AA 的最小 hex 调整。
[paste colors]5. 表单 a11y 审计
下面是表单。审计：
(a) label 关联（for/id 或包裹式 label）；
(b) 错误信息宣告（aria-describedby + role=alert）；
(c) 必填指示（不能只靠颜色）；
(d) 键盘提交；
(e) 出错后焦点管理（焦点移到第一个无效字段）；
(f) autocomplete 属性（1.3.5）；
(g) 可访问的身份验证：不含解谜这类认知测试步骤（3.3.8）。
每条问题映射到 WCAG 2.2 条目。
[paste form HTML]6. Modal / dialog a11y
下面是 modal 组件。审计：
(a) 打开时焦点进入 modal；
(b) 打开期间焦点陷阱锁在内部；
(c) Esc 关闭；
(d) role=dialog + aria-modal=true + aria-labelledby；
(e) 关闭后焦点回到触发点；
(f) 阻止背景滚动；
(g) 获焦时 dialog 不被遮挡（2.4.11）。
每条标出对应条目。
[paste]7. 自定义控件 ARIA 评审
下面是自定义控件（tabs / accordion / combobox / menu 等）。
对照对应的 WAI-ARIA Authoring Practices（APG）模式。
列出偏差，并提议满足规范所需的最小 ARIA role / state / 键盘处理
（方向键、Home/End、Enter/Space）。每个 ARIA role 都照规范核对，不要凭记忆。
[paste]8. 图片 alt 审计
下面是页面上 10 张图及其当前 alt。每张：
(a) 装饰图（alt=""）还是信息性图；
(b) alt 在上下文中是否承担了图片的功能；
(c) 是否与旁边文字重复；
(d) 复杂图（图表/示意图）附近是否有更长的描述。
给出修订后的 alt（1.1.1）。
[paste]9. 焦点管理审计
下面是多步流程。逐个走查焦点行为：
(a) 焦点起点；
(b) 下一步/返回/提交时移到哪；
(c) 宣告了什么。
标出任何把焦点丢到文档顶部或 body 的步骤，
并检查焦点是否被吸顶头部完全遮挡（2.4.11）。
[paste]10. 动态内容 live region 审计
下面是动态更新的组件（toast / 搜索结果 / 表单错误）。
审计：
(a) 更新是否被宣告；
(b) live region 礼貌度是否得当（状态用 aria-live=polite，
仅错误/紧急用 assertive）；
(c) 是否过频宣告或抢走焦点；
(d) 更新前该区域是否已在 DOM 中（事后才插入的空 live region 往往不触发）。
[paste]11. 仅靠颜色的信号
下面是页面或图表。找出所有只用颜色传达信息的点
（如红色 = 错误但无图标/文字、红绿状态点、图表系列只靠色相区分）。
每处提议非颜色的次级信号（图标、文字标签、纹理）。映射到 1.4.1。
[paste]12. WCAG 条目映射
下面是我的 axe-core 或 Lighthouse 无障碍报告。每条：
(a) 映射到具体 WCAG 2.1 / 2.2 条目及级别（A / AA）；
(b) 优先级（阻塞 / 大 / 小）；
(c) 最小代码修复；
(d) 验证它的人工测试（键盘、屏阅或对比度工具）。
再附一小段：这类页面上 axe-core 通常检测不到的 WCAG 失败项。
[paste report]WCAG 2.2 新增、但审计仍常漏的条目
WCAG 2.2 在 2023 年新增了 9 条成功标准，其中 4 条经常被旧审计清单漏掉，所以跑 2、6、9 号 Prompt 时要明确点名：
| 条目 | 级别 | 要求 |
|---|---|---|
| 2.4.11 焦点不被遮挡（最低） | AA | 获焦元素不能被吸顶头部、底栏或其他作者内容完全遮住 |
| 2.4.13 焦点外观 | AAA | 焦点指示器相对未获焦状态至少 3:1 对比，且有最小尺寸 |
| 2.5.7 拖拽动作 | AA | 任何拖拽交互都要有单指针替代方式（点按） |
| 2.5.8 目标尺寸（最低） | AA | 触摸目标至少 24×24 CSS 像素（含间距例外） |
容易踩的坑
- 把 axe-core 全绿当「审计完成」。自动化按数量算约覆盖 57%，按条目算更少；其余的都在键盘和屏阅走查里。
- 漏掉纯键盘走查，焦点陷阱、缺 skip-link 永远不会被发现。
- 写自定义 tabs / combobox / menu 没对照 WAI-ARIA Authoring Practices（APG）模式。
- 成功 / 错误态只用颜色——明眼人没事，色盲与屏阅用户完全看不到。
- modal 圈住屏阅焦点但没圈住键盘焦点（或反过来），两条都要单独测。
- live region 把装饰更新也读出来，训练用户忽略 assertive 通道。
- 因为审计模板早于 WCAG 2.2，就忽略了 24px 目标尺寸和焦点不被遮挡这两条。
- 盲信 AI 凭记忆给出的 ARIA role。模型会编造不存在的 role 名和 state 组合；要照 W3C ARIA Authoring Practices Guide 核对。
FAQ
这些 Prompt 能取代人工无障碍审计吗？ 不能。它们能替掉繁琐的第一遍，并抓出大量自动化漏掉的人工类问题，但法律合规——欧盟《无障碍法案》（2025 年 6 月 28 日已生效）、美国 ADA——仍需人工测试员用真实屏幕阅读器验证。把 AI 输出当成排好优先级的待办清单，而不是合格证书。
做无障碍审计哪个模型最好？ Claude Opus 4.7 和 Sonnet 4.6（截至 2026 年 6 月为 1M token 上下文）能轻松装下整块组件加它的 CSS，这对对比度和焦点推理很关键。GPT-5.5 和 Gemini 3.1 Pro 对 ARIA 模式也推理得不错。差距在上下文大小和你是否愿意粘真实标记，而不是模型的原始智商。
为什么映射到 WCAG 2.2 而不是 WCAG 3.0？ WCAG 3.0 还是工作草案（2026 年 3 月草案列了 174 条要求，并废除了通过/不通过的评级），预计 2028 年前不会成为 W3C 正式推荐标准。WCAG 2.2 AA 才是今天监管机构和 EN 301 549 引用的标准，所以 2026 年的审计应当对照它。
用这些 Prompt 前要先跑 axe-core 或 Lighthouse 吗？ 要。先让自动化清掉颜色对比、缺失 alt、表单 label 这些高频可机检的问题，再把报告喂给 12 号 Prompt，把人工时间花在键盘、屏阅和控件行为上。
怎么核实 AI 给的 ARIA 建议是对的？ 每个提议的 role 和 state 都照 W3C ARIA Authoring Practices Guide 核对，再用真实屏幕阅读器测试（Windows 上 NVDA，macOS/iOS 上 VoiceOver）。AI 模型偶尔会编出根本不存在、或浏览器直接忽略的 role/state 组合。