Screen Reader Testing Script
Structured test script for evaluating accessibility with screen readers.
Use Case
Conducting screen reader testing, training team members on assistive technology testing, or creating accessibility QA processes.
Prompt
You are an accessibility testing expert helping me create a test script for screen reader evaluation. I need to systematically test my product with assistive technology.
Test Context:
- Product/feature to test: [What you're testing]
- Screen readers to use: [VoiceOver, NVDA, JAWS, TalkBack]
- Key user flows: [Critical paths to test]
- Target WCAG level: [A, AA, or AAA]
Please create a comprehensive screen reader test script:
1. Test Environment Setup
VoiceOver (macOS):
- Enable: Command + F5
- Rotor: VO + U
- Navigation: VO + arrows
- Key commands reference: [List essential commands]
NVDA (Windows):
- Enable: Ctrl + Alt + N
- Elements list: NVDA + F7
- Navigation: Arrow keys
- Key commands reference: [List essential commands]
Browser combinations to test:
- macOS: Safari + VoiceOver, Chrome + VoiceOver
- Windows: Firefox + NVDA, Chrome + NVDA
- Mobile: iOS Safari + VoiceOver, Android Chrome + TalkBack
2. Pre-Test Checklist
□ Screen reader installed and updated
□ Browser zoom at 100%
□ Test page loaded fresh
□ Keyboard focus visible
□ Audio working
3. Landmark & Structure Test
□ Page has proper landmarks (main, nav, header, footer)
□ Landmarks are announced correctly
□ Heading structure is logical (h1 → h2 → h3)
□ Skip links work and are announced
□ Page title is descriptive
What to check:
- Use rotor/elements list to view landmarks
- Navigate by headings - is the hierarchy correct?
- Check if skip link moves focus appropriately
4. Navigation Test
□ All interactive elements reachable by keyboard
□ Focus order matches visual order
□ Focus indicator visible
□ No focus traps
□ Menu/dropdown accessible
□ Modal dialogs trap focus correctly
What to check:
- Tab through entire page - any elements skipped?
- Can you exit all menus and dialogs?
- Is focus ever lost or invisible?
5. Interactive Elements Test
For each button/link/control:
□ Role announced correctly (button, link, checkbox, etc.)
□ Name/label is descriptive
□ State announced (pressed, expanded, selected)
□ Instructions provided if needed
□ Feedback announced on interaction
Common issues:
- Clickable divs not announced as buttons
- Icons without accessible names
- State changes not announced
6. Form Test
For each form field:
□ Label associated and announced
□ Required fields indicated
□ Error messages announced
□ Success feedback announced
□ Autocomplete suggestions accessible
□ Date pickers/custom controls work
What to check:
- Enter each field - is label clear?
- Submit with errors - are they announced?
- Can you complete the form eyes-closed?
7. Dynamic Content Test
□ Live regions announce updates
□ Loading states announced
□ Notifications/toasts announced
□ Infinite scroll accessible
□ Auto-updating content manageable
What to check:
- Do status messages get announced?
- Can users pause auto-updating content?
8. Image & Media Test
□ Images have alt text
□ Alt text is descriptive (not "image" or filename)
□ Decorative images hidden from AT
□ Complex images have long descriptions
□ Video has captions
□ Audio has transcripts
What to check:
- Navigate to each image - is alt text useful?
- Are decorative images silent?
9. User Flow Testing
For each critical flow ([list your flows]):
Flow: [e.g., Sign up for account]
□ Step 1: [Action] - Announced: [Expected announcement]
□ Step 2: [Action] - Announced: [Expected announcement]
□ Step 3: [Action] - Announced: [Expected announcement]
□ Success: [Outcome announced correctly]
Can a user complete this flow using only a screen reader?
10. Issue Documentation Template
Issue #[X]:
- Screen reader: [Which SR]
- Browser: [Which browser]
- Location: [Page/component]
- Steps to reproduce: [How to find it]
- What was announced: [Actual]
- What should be announced: [Expected]
- WCAG criterion: [Which guideline]
- Severity: [Critical/Serious/Moderate/Minor]How to use
- 1Set up your testing environment with screen reader
- 2Practice basic navigation commands before testing
- 3Replace placeholders with your specific product and flows
- 4Test systematically through each section
- 5Document issues as you find them
- 6Test with at least 2 screen reader/browser combinations
- 7Include users who rely on screen readers if possible
Pro Tips
- • Start simple - learn basic commands before testing
- • Close your eyes periodically to experience what AT users experience
- • Test the same flow in multiple screen readers - they behave differently
- • VoiceOver + Safari and NVDA + Firefox are most important combinations
- • Focus on critical user flows first, not every page
- • Don't assume automated tools catch everything - they miss 70%
- • Involve actual screen reader users for the most accurate feedback
Tags
Related Prompts
Design System Component Visual Spec Writer
Developer-friendly visual specs: anatomy, tokenized properties per variant/state, spacing, responsive behavior, and accessibility for one component cluster.
Color Palette & Typography System Builder
Production-oriented foundations: primitive scales, semantic tokens, contrast tables, dark mode mapping, modular type scale, and token naming for tools like Style Dictionary.
Visual Hierarchy Audit
Structured critique of an existing screen from a detailed description: attention flow, hierarchy scores, P1/P2 issues, contrast flags, spacing, prioritized fixes, before/after for the top fix.
Accessibility Audit Report
Document accessibility findings with severity ratings, WCAG mappings, and remediation guidance.