How to Test Your Website with Screen Readers: A Practical Guide

Automated accessibility testing tools are valuable, but they only catch about 30% of accessibility issues. The other 70%? They require human testing—ideally with the same assistive technologies your users rely on. Screen readers are the most critical tool in this testing arsenal.

Why Screen Reader Testing Matters

Screen readers convert visual content into speech or Braille output, enabling blind and visually impaired users to navigate the web. But they only work well when websites are built with proper semantic structure.

Testing with a screen reader reveals issues that automated tools miss:

• Whether your content makes sense when read linearly
• If interactive elements are properly announced
• Whether users can navigate efficiently using headings and landmarks
• If dynamic content updates are communicated
• Whether custom widgets are actually usable

The Major Screen Readers

Three screen readers dominate the market. For thorough testing, you should test with at least two of them:

NVDA (Windows) — Free

NonVisual Desktop Access (NVDA) is the most popular free screen reader. It's open-source, regularly updated, and used by approximately 30% of screen reader users.

• Platform: Windows
• Cost: Free (donation-supported)
• Download: nvaccess.org
• Best for: Primary Windows testing, budget-conscious teams

JAWS (Windows) — Commercial

Job Access With Speech (JAWS) is the most widely-used commercial screen reader, particularly in enterprise environments. About 40% of screen reader users rely on JAWS.

• Platform: Windows
• Cost: ~$1,000/year (40-minute demo mode available free)
• Download: freedomscientific.com
• Best for: Enterprise testing, comprehensive coverage

VoiceOver (macOS/iOS) — Built-in

VoiceOver comes pre-installed on all Apple devices. It's the standard for Mac and iPhone users, making it essential for mobile accessibility testing.

• Platform: macOS, iOS, iPadOS
• Cost: Free (included with operating system)
• Activation: System Preferences → Accessibility → VoiceOver
• Best for: Mac users, iOS mobile testing

Getting Started with NVDA

NVDA is the best starting point for screen reader testing. It's free, well-documented, and representative of how many blind users browse the web.

Installation

1. Download NVDA from nvaccess.org
2. Run the installer and follow the prompts
3. Choose "Install on this computer" for regular testing
4. NVDA will start automatically after installation

Essential NVDA Keyboard Commands

NVDA uses the Insert key as its modifier (called the "NVDA key"). Here are the commands you'll use most:

Basic Navigation:

• ↓ / ↑ — Read next/previous line
• Tab — Move to next focusable element
• Shift + Tab — Move to previous focusable element
• Enter or Space — Activate buttons/links
• NVDA + ↓ — Start reading from current position
• Ctrl — Stop speaking

Quick Navigation (single-key shortcuts):

• H — Jump to next heading
• 1-6 — Jump to heading of that level
• D — Jump to next landmark/region
• K — Jump to next link
• F — Jump to next form field
• B — Jump to next button
• T — Jump to next table
• G — Jump to next graphic/image

Add Shift to any quick navigation key to go backwards (e.g., Shift + H for previous heading).

Your First NVDA Test

Follow this checklist for basic screen reader testing:

1. Load your page — NVDA should announce the page title
2. Press H repeatedly — Navigate through all headings. Do they make sense? Is the hierarchy logical?
3. Press D repeatedly — Navigate through landmarks. Are main, navigation, and footer regions defined?
4. Press Tab repeatedly — Go through all interactive elements. Is the order logical? Can you tell what each element does?
5. Press G repeatedly — Check images. Do they have meaningful alt text?
6. Test forms — Navigate to form fields. Are labels announced? Can you complete and submit the form?

Testing with VoiceOver on Mac

VoiceOver is already on your Mac—you just need to turn it on.

Activation

• Quick toggle: Press Cmd + F5
• Settings: System Preferences → Accessibility → VoiceOver

Essential VoiceOver Commands

VoiceOver uses Control + Option as its modifier (called "VO"). Most testers hold these keys with their left hand.

Basic Navigation:

• VO + → / VO + ← — Move to next/previous element
• VO + Space — Activate current element
• VO + A — Read from current position
• Ctrl — Stop speaking
• Tab — Move to next focusable element

Web Navigation (use with VO + U for Rotor):

• VO + U — Open Rotor (then use ← → to switch categories)
• VO + Cmd + H — Jump to next heading
• VO + Cmd + J — Jump to next form control
• VO + Cmd + L — Jump to next link
• VO + Cmd + T — Jump to next table

The VoiceOver Rotor

The Rotor (VO + U) is VoiceOver's most powerful feature. It displays lists of headings, links, form controls, landmarks, and more. Use arrow keys to navigate these lists, then press Enter to jump to that element.

Testing with VoiceOver on iOS

Mobile accessibility testing is crucial—over 60% of web traffic is mobile. VoiceOver on iOS uses touch-based gestures.

Activation

• Settings: Settings → Accessibility → VoiceOver
• Shortcut: Enable "Accessibility Shortcut" to triple-click the side button

Essential iOS VoiceOver Gestures

• Swipe right — Move to next element
• Swipe left — Move to previous element
• Double-tap — Activate current element
• Two-finger swipe down — Read from current position
• Two-finger tap — Stop speaking
• Rotor: Rotate two fingers on screen to change navigation mode (headings, links, etc.), then swipe up/down to navigate that category

What to Test For

When testing with screen readers, focus on these key areas:

1. Page Structure

• Is there a descriptive page title?
• Are headings used properly (H1 → H2 → H3, no skipped levels)?
• Are landmark regions defined (main, nav, footer, etc.)?
• Does the content make sense when read linearly?

2. Navigation

• Can you reach all interactive elements with Tab?
• Is the tab order logical?
• Can you tell where you are at all times (focus indication)?
• Can you skip repetitive navigation with a skip link?

3. Links and Buttons

• Is link text meaningful out of context? (Not "click here")
• Are buttons clearly labeled?
• Do icons have accessible names?

4. Images

• Do meaningful images have descriptive alt text?
• Are decorative images hidden from screen readers?
• Are complex images (charts, infographics) adequately described?

5. Forms

• Is every field labeled?
• Are required fields indicated?
• Are error messages announced and associated with fields?
• Can you complete and submit the form using only keyboard?

6. Dynamic Content

• Are modals/dialogs announced when they open?
• Is focus managed properly when content changes?
• Are status messages (success, error) announced via live regions?

Creating a Screen Reader Testing Checklist

Here's a simplified checklist you can use for each page:

1. ☐ Page title is descriptive and unique
2. ☐ All headings are logical and properly nested
3. ☐ Landmark regions are defined
4. ☐ Skip link is present and functional
5. ☐ All interactive elements are keyboard accessible
6. ☐ Tab order is logical
7. ☐ Focus is visible at all times
8. ☐ Links have meaningful text
9. ☐ Images have appropriate alt text
10. ☐ Form fields are properly labeled
11. ☐ Error messages are associated with fields
12. ☐ Dynamic content changes are announced
13. ☐ Modals trap and manage focus correctly

Tips for Effective Testing

1. Turn off your monitor — Even for a few minutes, this helps you understand the screen reader experience
2. Slow down the speech rate — When learning, reduce speed in settings
3. Use the speech viewer — Text logs help identify issues
4. Test in multiple browsers — Screen reader behavior can vary by browser
5. Document issues clearly — Note the screen reader, browser, and exact steps to reproduce

Beyond Testing: Building Accessible from the Start

Screen reader testing should ideally happen throughout development, not just at the end. The earlier you catch issues, the cheaper they are to fix.

Consider:

• Including accessibility in your definition of "done"
• Running quick screen reader tests during code review
• Training developers to use screen readers regularly
• Partnering with users who rely on assistive technology for user testing