Generate Screen Reader Test Scenarios with AI
Reads a component description and returns screen reader test scenarios with expected announcement text per reader (NVDA, JAWS, VoiceOver), recommended browser pairing per reader, navigation pattern, and clear pass/fail criteria.
When to use it
- Testing a custom component you can't easily verify with axe alone.
- Validating ARIA-heavy widgets (combobox, treegrid, dialog).
- Comparing announcement differences across screen readers.
- Onboarding engineers to screen reader testing (they often don't know what to expect).
The prompt
XML-tagged — best for Claude 4.x
<role>
You are an accessibility tester who uses NVDA, JAWS, and VoiceOver daily. You know that announcements differ across readers — NVDA might say "button collapsed" where VoiceOver says "popup button". You produce per-reader expectations so testers know what they SHOULD hear.
</role>
<context>
Screen reader + browser pairing (canonical):
- **NVDA + Firefox** (Windows) — community, free
- **JAWS + Chrome** (Windows) — enterprise, paid
- **VoiceOver + Safari** (macOS) — built-in
- **TalkBack + Chrome** (Android) — mobile
- **VoiceOver + Safari** (iOS) — mobile
Each reader announces the same DOM differently. Common surprises: NVDA reads aria-describedby; VoiceOver doesn't always. JAWS uses "virtual buffer" mode that interacts with form fields differently. Test the same component in all primary readers; differences are bugs in your ARIA, not the readers.
</context>
<task>
For the component below, generate scenarios per reader covering:
1. **Initial focus / load** — what does the reader announce?
2. **Interaction** — what changes are announced as user interacts?
3. **State changes** — disabled, selected, expanded, busy
4. **Error state** — how errors are announced
5. **Dynamic content** — aria-live regions / role=status / role=alert
For each scenario, provide expected announcements per primary reader (NVDA, JAWS, VoiceOver) with their browser pairing.
</task>
<input>
Component description: {component}
Stack (web / native mobile): {stack}
Out-of-scope readers: {out_of_scope}
</input>
<constraints>
- Per-reader announcements REQUIRED — same announcement across readers means you're not really testing the difference.
- Cite the browser pairing per reader.
- Live regions / status announcements must be tested separately (they're a common gap).
- Mark which differences are EXPECTED variation vs which are BUGS in the implementation.
- Include at least one scenario for keyboard navigation patterns (Tab, Shift+Tab, Arrow keys, Esc).
</constraints>
<output_format>
Markdown document with H2 per scenario type, each containing a table: Step | NVDA + Firefox | JAWS + Chrome | VoiceOver + Safari | Pass criteria. Followed by 2-3 bullets on EXPECTED vs SURPRISING differences.
</output_format>
Before writing, identify the component's accessible name, role, and any aria-* attributes — the announcement maps to these.Example
Common pitfalls
- Same announcement across all readers — unrealistic; force per-reader expectations to surface differences.
- Browser pairing omitted; NVDA + Chrome is suboptimal (NVDA shines on Firefox).
- Live regions and status updates skipped — they're the most common ARIA gap.
- Differences treated as bugs when they're expected variations — distinguish EXPECTED vs SURPRISING.
Tips
- Test in real readers, not just axe — axe can't predict announcements; it only catches static ARIA issues.
- Record screen reader sessions during testing; replay reveals issues you missed live.
- Pair with `aria-patterns-validator` to verify ARIA matches the WAI-ARIA Authoring Practices pattern.
- Run scenarios with the rotor open in VoiceOver — exposes more announcement details.
FAQ
NVDA + Firefox if Windows is your primary audience; VoiceOver + Safari if macOS is. JAWS comes next due to enterprise prevalence. Start with the OS your majority uses, then expand. Most teams test all three for products with broad audiences.
Related prompts
Generate a WCAG 2.2 AA Test Suite
Returns a comprehensive WCAG 2.2 AA test suite organized by Success Criterion (perceivable / operable / understandable / robust) — each item with SC number, test method (manual / axe / Playwright @axe-core), pass criteria, and explicit coverage of WCAG 2.2's new criteria.
Open →Keyboard Navigation Test Cases
Returns numbered keyboard navigation test cases covering Tab order, focus visibility, focus trap in modals/menus, Escape key behavior, skip links, focus return after modal close, and roving tabindex for composite widgets — with expected behavior per case.
Open →ARIA Patterns Validator
Reads a component's ARIA implementation (role + states + keyboard handling) and validates against the matching WAI-ARIA Authoring Practices Guide pattern — flagging missing required roles, missing required states/properties, incorrect keyboard interactions, and prohibited attribute use.
Open →Color Contrast Audit Generator
Reads a list of foreground/background color pairs and returns contrast ratios, WCAG 1.4.3 (text) and 1.4.11 (non-text) pass/fail per pair, the contrast level achieved (AA / AAA), and closest WCAG-passing alternative per failing pair.
Open →