无障碍回归审计 Prompt:12 个 axe-core 之外的模板

别再让 a11y 回归藏在"axe 没报警"后面。12 个 Prompt:键盘顺序、焦点管理、屏幕阅读器文案、动效偏好。

axe-core 抓得到的是简单 30%——对比度、alt 文本、role 匹配。剩下 70%(焦点陷阱、缺 live region、键盘顺序乱、动效引发癫痫)需要 Prompt 显式列失败模式并给出复现步骤。

适合哪些场景

要满足 WCAG 2.2 AA 的消费类应用工程师、做 a11y 评审的设计、投政企单子需要审计报告的创业团队。

什么时候不建议这样写 Prompt

纯后端改动别用——错了范围。axe-core 没先跑别用——AI 别重做工具能做得更好的事。

Prompt 结构公式

每个 a11y 审计 Prompt 都要带这六个要素:

  • 角色:AI 扮演谁(SRE / Release Captain / staff 工程师 / QA Lead)。
  • 上下文:技术栈 / 分支 / 失败日志 / diff / dashboard URL。
  • 目标:一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
  • 限制:AI 不能做什么(别自动修、别瞎造文件路径)。
  • 输出格式:编号清单、markdown 表格、JSON、unified diff、可运行代码。
  • 示例 / 信号:1-2 条”好输出”示例,或反例。

这套 Prompt 适合用在哪

  • PR 范围 a11y 回归
  • 复杂组件键盘顺序验证
  • 屏幕阅读器体验通查
  • 动效 / reduce-motion 审计
  • 表单错误无障碍

12 个可直接复制的 Prompt 模板

1. PR 范围 a11y diff

Audit this PR for a11y regressions in the diff only. Cover: (1) New interactive elements without keyboard handlers, (2) `role="button"` on non-buttons missing key handlers, (3) Removed aria-labels, (4) Decorative imagery added without `alt=""`, (5) Heading order broken. file:line + severity.

2. 键盘顺序验证

For `{componentName}`, describe the keyboard tab order step by step (Tab / Shift+Tab / Enter / Esc / Arrow keys). Flag: (1) Focus skipping a logical element, (2) Focus moving into invisible content, (3) Tab order that doesn't match visual order, (4) Esc that doesn't close a modal.

可替换变量: componentName

3. 屏幕阅读器朗读文案

Audit what a screen reader will announce for `{componentName}`: (1) Accessible name (label / aria-label / aria-labelledby), (2) State announcements (selected / expanded / loading), (3) Live region for async results, (4) Icon-only buttons get a visible-or-aria-name. Output a script-like trace of expected announcements.

可替换变量: componentName

4. 表单错误无障碍

Audit this form's error UX: (1) Errors associated via `aria-describedby` to the right input, (2) Submission summary at top with anchor links, (3) Live region announces error count, (4) Focus moves to first invalid field on submit, (5) Errors don't rely on colour alone. file:line.

5. 路由切换的焦点管理

For this SPA, audit focus management on navigation: (1) Does focus move to the new page's main heading? (2) Is title announced? (3) Are skip-links present and working? (4) Does focus survive modal open / close? Output failures + recipe per page.

6. 动效 + prefers-reduced-motion

Audit motion: (1) Any animation > 5s loops without pause? (2) Flashing > 3 times per second (seizure risk)? (3) Parallax / autoplay video without controls? (4) `prefers-reduced-motion` respected? Output file:line + fix.

7. diff 内对比度检查

For colour changes in this diff, compute contrast against WCAG AA: (1) Body text ≥ 4.5:1, (2) Large text / UI components ≥ 3:1, (3) Focus indicator ≥ 3:1 against adjacent colours. Don't check unchanged elements.

8. 触控热区大小

Audit interactive targets on mobile: (1) ≥ 44×44 CSS px for primary actions, (2) Spacing between adjacent targets ≥ 8px, (3) Custom buttons in lists meet target. file:line + severity.

9. 加载 / 异步朗读

Audit async UX: (1) Loading state announced via aria-live or role="status", (2) Errors announced via aria-live="assertive" sparingly, (3) Optimistic UI matched by reverted state on failure. file:line.

10. 自定义控件 ARIA 模式

For `{widgetType}`, verify it implements the WAI-ARIA authoring pattern. List: (1) Required role + key behaviours, (2) Where this implementation diverges, (3) Top 3 fixes by impact. Don't propose a full rewrite if 2 patches fix it.

可替换变量: widgetType — combobox / tabs / dialog / menu / treegrid

11. 移动端屏幕阅读器走查

Walk through this screen with VoiceOver (iOS) + TalkBack (Android). Predict announcements per swipe-right. Flag where Android / iOS will diverge meaningfully. Output a comparison table.

12. a11y 回归 triage

Last release had {nIssues} a11y bug reports. Triage: (1) Cluster by component, (2) Identify the top 3 by user impact (severity × reach), (3) Suggest one preventive check per cluster.

可替换变量: nIssues

容易踩的坑

  • “axe 没报警”就当过——覆盖率 ~30%。
  • 为了好看去掉 focus 环——键盘没法用。
  • <div onClick> 代替 <button>——键盘和屏阅同时失效。
  • 弹窗关闭时焦点没还原,键盘掉进 trap。
  • 到处用 aria-live assertive——屏阅被刷屏。
  • 表单错误只用红色——色盲不可见。
  • 不做 reduced-motion 检查——现代规范,简单能加。

优化技巧

  • 先跑 axe-core,再让 Prompt 抓它抓不到的。
  • 每个新组件手测键盘导航。
  • 季度用一次 VoiceOver / NVDA。
  • 语义 HTML 优先,ARIA 只是兜底。
  • 每个组件配一份 a11y.md 说键盘 + 屏阅契约。
  • PR 引入新 axe 违规要卡;已存在的别一并卡,避免 PR 失焦。
  • 焦点环必须保留——设计师顶住。

FAQ

  • axe-core 够 WCAG AA 吗?: 只占约三分之一,需配合手测键盘 + 屏阅。
  • 一定要找残障用户测吗?: 消费级产品最终是要的——工具 + AI 让你”好”,到不了”很好”。
  • 冒烟测试怎么做?: 拔掉鼠标,能完成功能就行;不能就说明键盘用户也不行。
  • 动效敏感用户怎么处理?: @media (prefers-reduced-motion) 切到非动画版本;自动播放视频禁止带声音。
  • PDF 需要无障碍吗?: 面向公众的,多数司法管辖区要(US Section 508 / EU EN 301 549)。
  • AI 能取代 a11y 顾问吗?: 高风险审计不行。常规检查 AI,边界由顾问。

相关阅读

标签: #Prompt #编程 #无障碍 #无障碍