accessibility-testing

无障碍测试（英文）

中文版： 请参阅对应的中文技能。

适用场景

• 需要在真实项目情境中获得无障碍测试方面的帮助。
• 需要可直接用于执行、评审或后续跟进的输出。

工作流

1. 阅读并遵循渐进式披露部分列出的主提示词（覆盖范围、结构、质量标准）。
2. 只补充会影响结果的项目背景：范围、环境、约束、风险、依赖项、预期交付物。
3. 如果输入不完整，先提供可用的初稿，并明确标记假设和信息缺口。
4. 默认使用 Markdown；只有用户提出要求时才切换格式。

领域执行要点

1. 记录项目指定的 WCAG 版本/级别、范围和成功准则 ID。缺少的目标保持未确定状态；切勿默认选择级别或声称符合标准。
2. 建立“准则 ID | 用户任务/状态 | 输入方式/辅助技术/版本 | 步骤 | 证据类型 | 结果”表。自动化扫描、键盘、屏幕阅读器和人工视觉证据应分别记录。
3. 测试键盘导航、打开、操作、关闭和焦点恢复。检查屏幕阅读器的名称/角色/状态及动态播报。根据用户影响优先处理无法访问的关键操作。
4. 扫描结果为零只能证明已扫描部分的结果。保留人工测试的 FAIL 和未执行的 NOT_RUN；按准则汇总证据，但不得将部分扫描结果提升为符合标准的结论。

核心约束

• 按风险/业务影响确定优先级，不要一视同仁。
• 将已确认事实与当前假设分开。
• 不要编造用户未提供的端点、字段、环境或根本原因。
• 确保输出可执行：场景具体、优先级明确、后续步骤清晰。

渐进式披露

• 校准领域结果、有效控件或证据缺口时，请阅读 references/domain-decision-example.md，了解脱敏输入、逐项判断基准和可复现的计算。

• 生成输出前，请阅读并遵循 prompts/accessibility-testing.md（最低覆盖范围、输出结构、质量标准）。

• 用户要求 Excel/CSV/JSON/Word 时：请阅读 output-formats.md 并遵循对应格式。

• 有合适的现成模板时：使用 output-templates/ 下匹配的文件。

• 对于深入的框架/故障排查/架构说明：只阅读 references/ 下相关文件，不要加载整个目录。

• 对于格式转换或辅助检查：优先使用现有的 scripts/，不要重复造轮子。

• 对此技能进行评估/回归测试：使用 skill-up 配合 evals/。

交付前检查清单

• 遵循了主提示词的输出结构
• 最低覆盖重点：范围和目标用户、键盘访问、焦点顺序和可见焦点、屏幕阅读器语义和标签、标题和地标、表单错误和验证反馈、颜色对比度和非颜色提示、图像、图标和替代文本……（详见主提示词）
• 覆盖了最低检查清单，或说明了未覆盖项
• 高风险项目有明确的优先级
• 未编造用户未提供的细节
• 已标记假设和信息缺口

常见陷阱

• 范围/背景缺失时，不要假装内容完整。
• 不要将所有项目视为同等重要。
• 不要忽略假设和信息缺口。
• 不要堆砌与当前工具链无关的通用理论。