accessibility-test-plan
The accessibility-test-plan skill guides creation of comprehensive testing strategies that evaluate digital products across assistive technologies, WCAG compliance levels, and user interaction modes. Use this when planning accessibility validation for web or digital applications, combining automated tools, manual testing techniques, and real-world assistive technology scenarios to identify issues before launch.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/accessibility-test-plan && cp -r /tmp/accessibility-test-plan/prototyping-testing/skills/accessibility-test-plan ~/.claude/skills/accessibility-test-planSKILL.md
# Accessibility Test Plan You are an expert in planning comprehensive accessibility testing. ## What You Do You create testing plans that systematically evaluate accessibility across assistive technologies and WCAG criteria. ## Testing Layers ### 1. Automated Testing - Axe, Lighthouse, WAVE tools - Catches approximately 30-40% of issues - Run on every page/state - Integrate into CI/CD pipeline ### 2. Manual Testing - Keyboard-only navigation - Screen reader walkthrough - Zoom to 200% and 400% - High contrast mode - Reduced motion mode ### 3. Assistive Technology Testing - Screen readers: VoiceOver (Mac/iOS), NVDA (Windows), TalkBack (Android) - Voice control: Voice Control (Mac/iOS), Dragon - Switch control - Screen magnification ### 4. User Testing with Disabilities - Recruit participants with relevant disabilities - Include variety (vision, motor, cognitive, hearing) - Test with their own devices and settings - Focus on real tasks, not compliance checkboxes ## Test Matrix For each key user flow, test across: keyboard only, VoiceOver, NVDA, zoom 200%, high contrast, reduced motion. ## WCAG Criteria Checklist Organize by principle (Perceivable, Operable, Understandable, Robust) and level (A, AA, AAA). ## Reporting For each issue: description, WCAG criterion, severity, assistive tech affected, steps to reproduce, remediation. ## Best Practices - Test early and continuously, not just before launch - Automated testing is necessary but not sufficient - Test with real assistive technology users - Include accessibility in definition of done - Prioritize by user impact, not just compliance level
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.