编程开发 编辑复核
前端可访问性审查清单
按键盘、屏幕阅读器、语义、焦点、对比度和错误反馈检查页面，给出证据和最小修复顺序。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名前端可访问性工程师。请基于真实 DOM、交互和视觉证据审查页面，不把工具扫描报告直接当成完整结论。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 检查标题层级、地标、表单标签、按钮名称和语义结构
2. 检查键盘顺序、焦点可见性、弹层关闭和错误反馈
3. 检查对比度、缩放、动态内容和触摸目标
4. 按用户影响和修复成本给出回归测试与验收条件
输入变量：
- 页面上下文（{{page_context}}）：说明页面任务、用户和关键状态。
- DOM 或代码（{{dom_or_code}}）：提供相关 HTML、组件和交互代码。
- 测试证据（{{test_evidence}}）：提供键盘、读屏或自动化测试结果。
- 参考标准（{{standard}}）：说明要遵守的标准和产品限制。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先用键盘和屏幕阅读器复核关键路径，再处理低影响的标记问题。
- 修复后重新测试焦点、错误和动态更新，不只跑一次扫描器。
WHEN IT FITS
适用判断
适合这些情况
- 页面已经实现，需要检查有没有明显的可访问性问题。
- 你能提供实际的 HTML 结构或组件代码。
- 要在上线前过一遍，避免基础问题。
换个做法更好
- 你要的是可测试的验收方案：用《前端无障碍测试计划》。
- 页面还是设计稿：先实现再审查，或者审查设计稿的对比度和层级。
- 你只有截图：模型看不出语义结构和键盘顺序。
FAILURE MODES
常见翻车与修正
- 建议给所有元素加 ARIA 属性。
原生语义元素优先，多余的 ARIA 反而制造问题。要求先检查能否用语义化标签解决，只在原生不足时才用 ARIA。
- 模型判断对比度不达标，但给出的色值是它猜的。
要求只对你提供的实际色值做判断，并给出计算过程；没有色值的标注「需实测」。
- 只检查了静态结构，忽略了键盘操作和焦点管理。
补充要求：逐个交互元素说明键盘可达性、焦点顺序、模态框的焦点陷阱和关闭后的焦点归还。
ACCEPTANCE
怎么判断输出合格
- 优先给出语义化标签的方案，ARIA 只在必要时使用。
- 对比度判断基于你提供的实际色值，有计算过程。
- 覆盖了键盘操作、焦点顺序和焦点管理。
- 每条问题都指到了具体的元素或组件。
SAFETY BOUNDARY
使用边界
- 模型看不到实际渲染结果，它的判断基于代码推测；对比度和焦点顺序必须实测。
- 自动检查覆盖不了屏幕阅读器的实际体验，关键流程要用真实辅助技术走一遍。