编程开发 编辑复核
前端无障碍测试计划
从键盘、焦点、语义、对比度、读屏和动态状态设计可执行的无障碍检查。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名前端无障碍测试员。请基于真实页面交互设计无障碍测试计划，区分自动扫描能发现的问题和必须人工验证的问题。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 页面任务、组件和语义结构
2. 键盘路径、焦点顺序和可见焦点
3. 读屏名称、动态状态、表单错误和通知
4. 颜色对比、缩放、移动端和减少动效
5. 测试环境、严重程度和验收标准
输入变量：
- 页面或组件（{{page}}）：提供页面结构、交互和状态。
- 关键任务（{{tasks}}）：列出用户必须完成的任务。
- 技术栈（{{stack}}）：说明框架、组件库和现有检查工具。
- 目标标准（{{standard}}）：提供组织采用的标准或最低要求。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 自动扫描只能作为筛选，键盘和读屏必须人工走关键路径。
- 修复后保留测试环境、浏览器和结果记录。
WHEN IT FITS
适用判断
适合这些情况
- 需要把可访问性做成可重复执行的验收步骤。
- 有多个页面或组件要覆盖，需要统一测试口径。
- 要区分自动化能查的和必须人工验证的。
换个做法更好
- 你要的是对现有页面的一次性审查：用《前端可访问性审查清单》。
- 只有一个简单页面：直接审查比建计划快。
- 团队还没有任何可访问性基础：先做一轮审查看看差距。
FAILURE MODES
常见翻车与修正
- 计划全靠自动化工具，认为跑过 axe 就合格。
自动化只能覆盖三成左右的问题。要求明确区分自动化项和人工项，并列出必须人工验证的场景。
- 测试步骤写成「用屏幕阅读器检查」，没说检查什么。
要求每个人工步骤写明用哪个读屏软件、操作什么、听到什么算通过。
- 没定合格标准，测完不知道能不能上线。
补充要求：给出分级的通过标准，哪些问题阻塞上线、哪些可以排期修复。
ACCEPTANCE
怎么判断输出合格
- 明确区分了自动化项和人工验证项。
- 每个人工步骤都有具体操作和通过标准。
- 有分级的合格标准，能判断是否阻塞上线。
- 覆盖了键盘、读屏、对比度和动效偏好设置。
SAFETY BOUNDARY
使用边界
- 自动化检测只能覆盖一部分问题，键盘导航和屏幕阅读器体验必须人工走查。
- 测试计划要包含真实辅助技术用户的反馈渠道，只靠工具验收会漏掉实际使用障碍。