Screen Reader Testing Script
Structured test script for evaluating accessibility with screen readers.
Actions
Tags
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
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.
New prompts & templates by email
Weekly copy-paste prompts, pattern notes, and AI UX resources on Substack - no spam, unsubscribe anytime.