accessibility-testing · diff
git:20260325.c371d73 to git:20260803.f52f41e
30 added, 20 removed. Audit A to A.
---
name: accessibility-testing
description: Use this skill when you need to design accessibility testing against WCAG, keyboard navigation, and assistive technology scenarios; triggers include accessibility testing and a11y testing.
---
# Accessibility Testing (English)
- **中文版：** 见对应中文技能。
+ **中文版：** See the corresponding Chinese skill.
## When to Use
- Need help with accessibility testing in a real project context.
- Need an output that can be used directly for execution, review, or follow-up.
- ## Output Format Options
+ ## Workflow
- Markdown by default. If you need Excel, CSV, JSON, Word, or other supported formats, append the format request at the end and check [output-formats.md](output-formats.md).
+ 1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
+ 2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
+ 3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
+ 4. Default to Markdown; switch formats only when the user asks.
- ## How to Use
+ ## Core Constraints
- 1. Open `prompts/accessibility-testing.md` and use it as the main prompt.
- 2. Add the real project context: scope, environment, constraints, risks, dependencies, and expected deliverable.
- 3. If the input is incomplete, return a usable first version and mark missing information and assumptions.
+ - Prioritize by risk / business impact — do not treat everything equally.
+ - Separate confirmed facts from current assumptions.
+ - Do not invent endpoints, fields, environments, or root causes the user did not provide.
+ - Keep output executable: concrete scenarios, clear priority, clear next steps.
- ## Reference Files
+ ## Progressive Disclosure
- - `prompts/accessibility-testing.md`: main prompt for this skill.
- - `output-formats.md`: optional output format instructions.
- - `references/`: supporting notes loaded only when needed.
- - `scripts/`: helper scripts or converters for this skill.
+ - Before producing output, read and follow `prompts/accessibility-testing.md` (minimum coverage, output structure, quality bar).
+ - When Excel/CSV/JSON/Word is requested: read `output-formats.md` and honor the format.
+ - When a ready-made template fits: use matching files under `output-templates/`.
+ - For deep framework/troubleshoot/schema notes: read only the relevant file(s) under `references/`, do not load the whole directory.
+ - For format conversion or helper checks: prefer existing `scripts/` over reinventing.
+ - For evaluating/regressing this skill: use `evals/` with skill-up.
- ## Common Pitfalls
+ ## Pre-delivery Checklist
- - Do not use it with vague scope and no context.
- - Do not treat every area as equally important.
- - Do not skip assumptions and missing information.
+ - [ ] Followed the main prompt's output structure
+ - [ ] Minimum coverage focus: scope and target users, keyboard access, focus order and visible focus, screen reader semantics and labels, headings and landmarks, form errors and validation feedback, color contrast and non-color cues, images, icons, and alternative text, ... (details in main prompt)
+ - [ ] Covered the minimum checklist, or explained omissions
+ - [ ] High-risk items have explicit priority
+ - [ ] Did not invent details the user did not provide
+ - [ ] Assumptions and gaps are marked
- ## Best Practices
+ ## Common Pitfalls
- - Start from the prompt file, then add only the context that matters.
- - Keep the output risk-driven and executable.
- - If the request is incomplete, return a usable first version and mark gaps.
+ - Do not pretend completeness when scope/context is missing.
+ - Do not treat every item as equally important.
+ - Do not skip assumptions and information gaps.
+ - Do not dump generic theory unrelated to the current toolchain.