--- name: accessibility-testing-strategy-51f905302a67 description: "Plan what to test, how to test, and who should test for accessibility. Use when defining a testing approach, planning QA, setting up automated and manual testing, or deciding what level of accessibility testing a project needs. Triggers on: accessibility testing, how to test, test plan, automated testing, manual testing, screen reader testing, user testing, accessibility QA, what to test, testing strategy." --- # Accessibility Testing Strategy Plan a testing approach that catches real accessibility barriers — because automated tools find roughly 30% of issues. The other 70% require human judgment. ## The Testing Pyramid ### Layer 1: Automated Testing (Catches ~30%) What it finds: - Missing alt text - Colour contrast failures - Missing form labels - Missing language attribute - Empty headings and buttons - Duplicate IDs What it misses: - Whether alt text is meaningful - Whether focus order is logical - Whether content makes sense - Whether interactions work with keyboard - Whether the experience is usable Tools: axe, Lighthouse, WAVE, Pa11y, jest-axe When: on every build, in CI/CD pipeline Who: automated — no human needed ### Layer 2: Manual Expert Testing (Catches ~50%) What it finds: - Keyboard navigation issues - Focus management problems - Logical reading order failures - Meaningful alt text assessment - Cognitive accessibility barriers - Interaction pattern issues Method: - Tab through every interactive element - Test with screen reader (VoiceOver or NVDA) - Test at 200% zoom - Test with system preferences enabled - Review content for plain language When: before each release, on major feature changes Who: someone trained in accessibility testing ### Layer 3: User Testing With Disabled People (Catches remaining ~20%) What it finds: - Real-world usability barriers that experts miss - Assistive technology compatibility issues - Unexpected workflows and workarounds - Cognitive and emotional barriers - Issues that only appear with actual AT proficiency Method: - Recruit participants with diverse disabilities - Test core tasks with their own devices and AT - Observe — don't guide or explain - Record what works, what fails, and what frustrates When: quarterly, or before major launches Who: users with disabilities using their own setup ## What to Test First ### Priority 1: Core Tasks - Can users complete the primary tasks the product exists for? - Test the critical path end to end - Any failure here is a launch blocker ### Priority 2: Input and Navigation - Keyboard-only navigation through the core flow - Screen reader navigation through the core flow - Touch interaction on mobile for the core flow ### Priority 3: Content and Comprehension - Is content understandable at the target reading level? - Are error messages helpful? - Is help available and findable? ### Priority 4: Edge Cases and Preferences - Zoom to 200% - System preferences (reduced motion, high contrast, dark mode) - Long content, empty states, error states ## Screen Reader Testing Basics For teams new to screen reader testing: ### Start With VoiceOver (Mac) - Turn on: Cmd + F5 - Navigate: VO + arrow keys (VO = Ctrl + Option) - Headings: VO + Cmd + H - Links: VO + Cmd + L - Forms: VO + Cmd + J - Turn off: Cmd + F5 ### Start With NVDA (Windows) - Download free from nvaccess.org - Navigate: Tab, arrow keys - Headings: H - Links: K - Forms: F - Stop speech: Ctrl ### What to Listen For - Does every interactive element have a name? - Are state changes announced (expanded, selected, checked)? - Does focus move to the right place after actions? - Can you understand the page reading only the headings? ## Assessment Questions 1. Is automated testing running on every build? 2. Is manual expert testing happening before each release? 3. Has the product been tested by people with disabilities? 4. Are core tasks tested with keyboard and screen reader? 5. Is there a clear priority for what to test first? --- Source attribution: wanghaisheng Original project: https://github.com/wanghaisheng/openaiworkhorse-design-team/blob/941a49c93eec04b2f2a6cff5156719d029ac35bb/.claude/skills/designer-role/skills/accessibility-testing-strategy/SKILL.md License: MIT License information: https://opensource.org/license/mit Original upstream instructions; downloaded from Dave AI. ## Upstream license notice MIT License Copyright (c) 2026 HeisenBerg? Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # Dave AI resource metadata Creator / publisher: wanghaisheng Original project: https://github.com/wanghaisheng/openaiworkhorse-design-team/blob/941a49c93eec04b2f2a6cff5156719d029ac35bb/.claude/skills/designer-role/skills/accessibility-testing-strategy/SKILL.md Attribution basis: Source repository record Fields of work: Design, Development & Engineering Roles: Frontend Developer, QA / Test Engineer, UX Designer Specialties: Specialty not specified Tools: Lighthouse, Pa11Y, Wave, Axe, Jest Axe Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 805a901a99bd0c5ca34247befe30994429010c71a9f034cea741a90f47756dbb