Screen Reader Testing
Validate web and mobile UIs with VoiceOver, NVDA, JAWS, and related screen readers using a prioritized platform matrix.
Overview
Screen Reader Testing is an agent skill most often used in Ship (also Build frontend) that validates web accessibility with VoiceOver, NVDA, JAWS, and related assistive technology using prioritized browser pairs.
Install
npx skills add https://github.com/wshobson/agents --skill screen-reader-testingWhat is this skill?
- Compares major screen readers (VoiceOver, NVDA, JAWS, TalkBack, Narrator) with platform and browser pairings
- Defines minimum coverage: NVDA+Firefox, VoiceOver+Safari on macOS and iOS; comprehensive adds JAWS, TalkBack, Narrator
- Explains browse/virtual vs focus/interaction modes and when each applies
- Targets ARIA implementations, forms, dynamic announcements, and navigation flows
- Usage-share table guides which AT combinations to prioritize on limited solo-builder time
- Five major screen readers cataloged with platform and browser pairings
- Minimum coverage requires 3 AT+browser combinations; comprehensive coverage adds 3 more
- Reference usage shares listed for VoiceOver (~15%), NVDA (~31%), and JAWS (~40%) in the skill table
Adoption & trust: 6.9k installs on skills.sh; 36.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI passes automated a11y scans but you do not know if real screen reader users can complete tasks on Windows, macOS, iOS, or Android.
Who is it for?
Indie SaaS and mobile web builders implementing ARIA-heavy interfaces who can spare time for hands-on NVDA and VoiceOver sessions.
Skip if: Teams that only need color-contrast fixes with no interactive components, or products with zero web UI surface.
When should I use this skill?
Validating screen reader compatibility, debugging assistive technology issues, testing ARIA, forms, dynamic announcements, or navigation accessibility.
What do I get? / Deliverables
You follow a documented AT matrix, modes, and scenario checklist so critical flows are verified before release and regressions are easier to reproduce.
- AT test matrix results for critical user journeys
- Repro steps for accessibility bugs tied to specific reader+browser pairs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Formal assistive-technology checks are canonical ship-phase QA before launch, though issues often trace back to build-time markup. Testing subphase covers manual and semi-manual AT validation distinct from automated lint-only accessibility scans.
Where it fits
Verify a new combobox announces expanded state correctly in VoiceOver browse mode before merging.
Run minimum matrix (NVDA+Firefox, VoiceOver+Safari desktop and iOS) on checkout and settings flows.
Confirm marketing landing page headings and skip links work under JAWS+Chrome for public compliance claims.
How it compares
Hands-on assistive-technology sessions—not a substitute for automated accessibility linting alone.
Common Questions / FAQ
Who is screen-reader-testing for?
Solo developers and designers responsible for accessibility who need a practical NVDA, VoiceOver, and JAWS testing playbook.
When should I use screen-reader-testing?
During ship QA before launch, and during build when adding modals, live regions, or complex forms that must announce correctly.
Is screen-reader-testing safe to install?
Review the Security Audits panel on this Prism page; the skill is documentation-only and does not require elevated permissions by itself.
SKILL.md
READMESKILL.md - Screen Reader Testing
# Screen Reader Testing Practical guide to testing web applications with screen readers for comprehensive accessibility validation. ## When to Use This Skill - Validating screen reader compatibility - Testing ARIA implementations - Debugging assistive technology issues - Verifying form accessibility - Testing dynamic content announcements - Ensuring navigation accessibility ## Core Concepts ### 1. Major Screen Readers | Screen Reader | Platform | Browser | Usage | | ------------- | --------- | -------------- | ----- | | **VoiceOver** | macOS/iOS | Safari | ~15% | | **NVDA** | Windows | Firefox/Chrome | ~31% | | **JAWS** | Windows | Chrome/IE | ~40% | | **TalkBack** | Android | Chrome | ~10% | | **Narrator** | Windows | Edge | ~4% | ### 2. Testing Priority ``` Minimum Coverage: 1. NVDA + Firefox (Windows) 2. VoiceOver + Safari (macOS) 3. VoiceOver + Safari (iOS) Comprehensive Coverage: + JAWS + Chrome (Windows) + TalkBack + Chrome (Android) + Narrator + Edge (Windows) ``` ### 3. Screen Reader Modes | Mode | Purpose | When Used | | ------------------ | ---------------------- | ----------------- | | **Browse/Virtual** | Read content | Default reading | | **Focus/Forms** | Interact with controls | Filling forms | | **Application** | Custom widgets | ARIA applications | ## VoiceOver (macOS) ### Setup ``` Enable: System Preferences → Accessibility → VoiceOver Toggle: Cmd + F5 Quick Toggle: Triple-press Touch ID ``` ### Essential Commands ``` Navigation: VO = Ctrl + Option (VoiceOver modifier) VO + Right Arrow Next element VO + Left Arrow Previous element VO + Shift + Down Enter group VO + Shift + Up Exit group Reading: VO + A Read all from cursor Ctrl Stop speaking VO + B Read current paragraph Interaction: VO + Space Activate element VO + Shift + M Open menu Tab Next focusable element Shift + Tab Previous focusable element Rotor (VO + U): Navigate by: Headings, Links, Forms, Landmarks Left/Right Arrow Change rotor category Up/Down Arrow Navigate within category Enter Go to item Web Specific: VO + Cmd + H Next heading VO + Cmd + J Next form control VO + Cmd + L Next link VO + Cmd + T Next table ``` ### Testing Checklist ```markdown ## VoiceOver Testing Checklist ### Page Load - [ ] Page title announced - [ ] Main landmark found - [ ] Skip link works ### Navigation - [ ] All headings discoverable via rotor - [ ] Heading levels logical (H1 → H2 → H3) - [ ] Landmarks properly labeled - [ ] Skip links functional ### Links & Buttons - [ ] Link purpose clear - [ ] Button actions described - [ ] New window/tab announced ### Forms - [ ] All labels read with inputs - [ ] Required fields announced - [ ] Error messages read - [ ] Instructions available - [ ] Focus moves to errors ### Dynamic Content - [ ] Alerts announced immediately - [ ] Loading states communicated - [ ] Content updates announced - [ ] Modals trap focus correctly ### Tables - [ ] Headers associated with cells - [ ] Table navigation works - [ ] Complex tables have captions ``` ### Common Issues & Fixes ```html <!-- Issue: Button not announcing purpose --> <button><svg>...</svg></button> <!-- Fix --> <button aria-label="Close dialog"><svg aria-hidden="true">...</svg></button> <!-- Issue: Dynamic content not announced --> <div id="results">New results loaded</div> <!-- Fix --> <div id="results" role="status" aria-live="polite">New results loaded</div> <!-- Issue: Form error not read --> <input type="email" /> <span class="error">Invalid e