Screen Reader Testing Guide
Updated March 2026Reviewed by Khushwant Parihar, CPACC
The complete reference for testing websites with NVDA, JAWS, VoiceOver, and TalkBack. Includes setup instructions, command references, testing procedures, and downloadable checklists.
Introduction
A screen reader is assistive technology software that converts on-screen content into synthesized speech or refreshable braille output. Screen readers enable people who are blind, have low vision, or have certain cognitive disabilities to perceive and interact with digital content. Rather than simply reading text aloud, screen readers interpret the structure, roles, states, and relationships of interface elements, giving users a comprehensive understanding of a web page without relying on visual presentation.
Screen readers work by accessing the accessibility tree, a structured representation of the page that the browser builds from the HTML DOM. The browser exposes this tree through platform-specific accessibility APIs -- UI Automation on Windows, NSAccessibility on macOS, and AccessibilityService on Android. When your HTML uses proper semantic elements (headings, lists, buttons, form labels) and ARIA attributes where needed, the accessibility tree accurately represents the page. When it does not, the screen reader experience breaks down, sometimes rendering a site completely unusable.
Screen Reader Market Share
| Screen Reader | Platform | Cost | Market Share |
|---|---|---|---|
| JAWS | Windows | $90/yr or $1,000+ | ~40% |
| NVDA | Windows | Free (open source) | ~30% |
| VoiceOver | macOS / iOS | Free (built-in) | ~15% |
| TalkBack | Android | Free (built-in) | ~10% |
| Narrator | Windows | Free (built-in) | ~5% |
Source: WebAIM Screen Reader User Survey (approximate figures based on primary screen reader usage)
Recommended Browser Pairings
Each screen reader works best with a specific browser. Using the wrong pairing can produce misleading test results.
- NVDA + Firefox -- Recommended starting point. The best free combination for comprehensive testing.
- JAWS + Chrome or Edge -- The industry-standard enterprise pairing. JAWS also works well with Firefox.
- VoiceOver + Safari -- Required on Apple platforms. Safari is the only browser that fully exposes macOS/iOS accessibility APIs to VoiceOver.
- TalkBack + Chrome -- The standard pairing for Android mobile testing.
NVDA
NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows. It is the recommended starting point for developers new to screen reader testing because it costs nothing, receives frequent updates, and pairs excellently with Firefox.
Setup Steps
- Download: Go to nvaccess.org/download and download the latest version. The installer is approximately 40 MB.
- Install: Run the installer. You can choose to install NVDA on your system or create a portable copy on a USB drive for use on machines where you cannot install software.
- Configure:On first launch, a Welcome Dialog appears. Check "Use Caps Lock as an NVDA modifier key" if you are on a laptop without an Insert key. Select your preferred keyboard layout (Desktop or Laptop).
- Launch: NVDA runs in the system tray. Right-click the tray icon or press NVDA + N to open the NVDA menu for preferences, tools, and help.
Key Settings to Configure
- -Speech rate: Preferences → Settings → Speech. Start at 40-50% speed while learning; experienced users typically run at 70-80%.
- -Browse mode: Preferences → Settings → Browse Mode. Enable "Automatic focus mode for focus changes" so NVDA switches to focus mode when you enter form fields.
- -Speech viewer: Tools → Speech Viewer. Opens a text window showing everything NVDA speaks, which is invaluable when learning.
Essential Commands
| Action | Shortcut |
|---|---|
| Start / Stop NVDA | Ctrl + Alt + N |
| Stop speaking | Ctrl |
| Read from cursor | NVDA + Down Arrow |
| Read current line | NVDA + Up Arrow |
| Next heading | H |
| Next link | K |
| Next form field | F |
| Next button | B |
| Next landmark | D |
| Elements list | NVDA + F7 |
| Toggle browse / focus mode | NVDA + Space |
| Read page title | NVDA + T |
| Next table | T |
| Navigate table cells | Ctrl + Alt + Arrow keys |
JAWS
JAWS (Job Access With Speech) by Freedom Scientific is the most widely used commercial screen reader, holding approximately 40% of the desktop screen reader market. It is the industry standard in enterprise and government environments and includes advanced scripting capabilities for customizing behavior on specific applications and websites.
Essential Commands
| Action | Shortcut |
|---|---|
| Stop speaking | Ctrl |
| Say current line | Insert + Up Arrow |
| Say all (read from cursor) | Insert + Down Arrow |
| Next heading | H |
| Headings list | Insert + F6 |
| Links list | Insert + F7 |
| Forms list | Insert + F5 |
| Next landmark | ; (semicolon) |
| Toggle virtual cursor | Insert + Z |
| JAWS find | Ctrl + Insert + F |
VoiceOver
VoiceOver is Apple's built-in screen reader for macOS. It ships with every Mac and requires no installation. VoiceOver must be used with Safari for the most accurate web testing, as Safari is the only macOS browser that fully exposes accessibility APIs to VoiceOver.
Getting Started
- -Enable: Press Cmd + F5, or go to System Settings → Accessibility → VoiceOver and toggle it on.
- -VO modifier: The VoiceOver modifier key is Ctrl + Option, abbreviated as "VO" throughout this guide and in Apple's documentation.
Essential Commands
| Action | Shortcut |
|---|---|
| Toggle VoiceOver | Cmd + F5 |
| Stop speaking | Ctrl |
| Read from cursor | VO + A |
| Next element | VO + Right Arrow |
| Previous element | VO + Left Arrow |
| Interact with group | VO + Shift + Down Arrow |
| Stop interacting | VO + Shift + Up Arrow |
| Activate element | VO + Space |
| Open Rotor | VO + U |
| Next heading | VO + Cmd + H |
| Next link | VO + Cmd + L |
The Rotor (VO + U)
The Rotor is VoiceOver's most powerful feature. It opens a navigable list where you can switch between headings, links, landmarks, form controls, tables, and more using the Left and Right arrow keys. Within each category, use the Up and Down arrow keys to select a specific item, then press Enter to navigate to it. Press Escape to close the Rotor.
The Rotor gives you a bird's-eye view of the page structure. Use it to verify that your heading hierarchy is logical, that all landmarks are labeled correctly, and that form controls have proper accessible names. If elements are missing from the Rotor categories, they are likely missing the semantic HTML or ARIA attributes needed for screen reader recognition.
VoiceOver
VoiceOver on iOS uses touch-based gestures instead of keyboard commands. It is the dominant screen reader on mobile devices and essential for testing mobile web experiences. Enable it via Settings → Accessibility → VoiceOver, or configure the Accessibility Shortcut (triple-click the Side button) for quick toggling during testing sessions.
Touch Gesture Commands
| Action | Shortcut |
|---|---|
| Next element | Swipe right |
| Previous element | Swipe left |
| Activate element | Double-tap |
| Read from top | Two-finger swipe up |
| Read from cursor | Two-finger swipe down |
| Pause / Resume speaking | Two-finger tap |
| Scroll | Three-finger swipe up/down |
| Change navigation mode | Rotor (two-finger twist) |
| Navigate by rotor setting | Swipe up/down |
TalkBack
TalkBack is Google's built-in screen reader for Android devices. Enable it via Settings → Accessibility → TalkBack. On many devices, you can also hold both volume keys for three seconds to toggle TalkBack on and off quickly.
Gesture Commands
| Action | Shortcut |
|---|---|
| Next element | Swipe right |
| Previous element | Swipe left |
| Activate element | Double-tap |
| Next heading | Swipe up then right |
| Next link | Swipe down then right |
| Previous heading | Swipe up then left |
| Scroll forward | Two-finger swipe up |
| Scroll backward | Two-finger swipe down |
| TalkBack menu | Three-finger tap |
| Home / Back | Swipe up then down |
Command Reference
Compare the 10 most common testing tasks across all screen readers. Select a tab to view the commands for each screen reader.
| Action | Shortcut |
|---|---|
| Navigate by headings | H / Shift + H |
| Navigate by links | K / Shift + K |
| Navigate by landmarks | D / Shift + D |
| Navigate by form fields | F / Shift + F |
| Read current element | NVDA + Up Arrow |
| Read all from cursor | NVDA + Down Arrow |
| Stop speaking | Ctrl |
| Open elements list | NVDA + F7 |
| Toggle browse / focus mode | NVDA + Space |
| Activate element | Enter or NVDA + Enter |
Testing Scenarios
Follow these six scenarios to systematically test the most critical accessibility concerns with a screen reader. Each scenario describes what to test, the expected behavior, and the most common failures.
Page Structure
What to Test
- -Navigate by headings (H key) and verify a logical hierarchy: one H1, then H2s, H3s, with no skipped levels
- -Check landmarks using the elements list or Rotor (main, nav, banner, contentinfo)
- -Read the page title (NVDA + T) and verify it is unique and descriptive
Expected Behavior
- -Headings reflect the visual structure and hierarchy of the page
- -At least main, navigation, and banner landmarks are present
- -Page title follows the pattern "Page Name - Site Name"
Common Failures
- -Skipped heading levels (H1 followed by H4)
- -No landmarks defined, so the elements list is empty
- -Generic page title like "Home" or "Untitled"
Navigation Menus
What to Test
- -Tab through all navigation items and verify they are links or buttons
- -Open dropdown submenus and verify the toggle announces expanded/collapsed
- -Check that the current page link is indicated
Expected Behavior
- -Navigation is inside a <nav> element announced as "navigation"
- -Submenu buttons announce aria-expanded state ("expanded" / "collapsed")
- -Current page uses aria-current="page" and is announced accordingly
Common Failures
- -Nav items are divs with click handlers instead of proper links
- -Dropdown toggle lacks aria-expanded, so state is invisible
- -No indication of which page is currently active
Forms
What to Test
- -Tab to each form field and verify the label is announced
- -Check that required fields announce "required"
- -Submit the form with errors and verify error messages are announced when focusing the invalid field
Expected Behavior
- -Each field announces: label, type (text, email, etc.), and required state
- -Error messages are linked via aria-describedby and read when the field is focused
- -Submission success or failure is announced to the user
Common Failures
- -Placeholder text used as the only label (disappears on input)
- -Required state communicated only by a visual red asterisk
- -Error messages appear visually but are not linked to inputs
Images
What to Test
- -Navigate to each image and listen for the alt text description
- -Verify decorative images are not announced at all
- -Check that complex images (charts, infographics) have a long text description
Expected Behavior
- -Informative images announce concise, meaningful descriptions
- -Decorative images with alt="" are completely skipped by the screen reader
- -Complex images provide equivalent information via figcaption or aria-describedby
Common Failures
- -Alt text is a filename like "IMG_3842.jpg" or "banner-final-v2.png"
- -Missing alt attribute causes screen reader to announce the full file URL
- -Decorative images have alt text, adding noise to the reading experience
Dynamic Content
What to Test
- -Trigger notifications and toast messages to verify they are announced automatically
- -Test loading states (spinners, skeleton screens) for screen reader announcements
- -Open modals, accordions, and tabs to verify content is announced and focus is managed
Expected Behavior
- -Notifications use aria-live="polite" or role="status" and are announced without focus moving
- -Loading states announce "Loading" and completion via live regions
- -Modals move focus inside when opened and return focus to the trigger when closed
Common Failures
- -Content updates silently with no aria-live region
- -Loading spinners are purely visual with no text alternative
- -Modal opens but focus remains behind it on the page
Tables
What to Test
- -Navigate to a data table (T key in NVDA) and verify it is announced as a table with row and column count
- -Use Ctrl + Alt + Arrow keys to move between cells and verify headers are announced
- -Check for a caption that describes the table's purpose
Expected Behavior
- -Column headers (<th scope="col">) are read aloud when moving to a cell in that column
- -Row headers (<th scope="row">) are read when moving to a cell in that row
- -Table caption is announced when entering the table
Common Failures
- -All cells use <td> with no <th> elements, so headers are never announced
- -No scope attribute on header cells, breaking header-cell association
- -CSS grid or flexbox layout presented as a <table>, confusing navigation
Testing Checklist
Use this interactive checklist to track your screen reader testing progress. Check off each item as you verify it. Download a PDF version to use offline.
Page Structure
Navigation
Forms
Images & Media
Interactive Elements
Dynamic Content
Frequently Asked Questions
Which screen reader should I start with?
Start with NVDA on Windows or VoiceOver on macOS. NVDA is free, open-source, and widely used, making it an ideal first screen reader for developers. Pair it with Firefox for the best testing experience. If you are on a Mac, VoiceOver is already built in and works best with Safari.
Do I need to test with every screen reader?
No. Testing with one desktop screen reader (NVDA or JAWS) and one mobile screen reader (VoiceOver on iOS or TalkBack on Android) covers the vast majority of your user base. NVDA plus Firefox is the recommended starting point because it is free and catches the most common issues. Add JAWS and VoiceOver testing when you need higher coverage.
What is the most used screen reader?
According to the WebAIM Screen Reader Survey, JAWS holds approximately 40% of the desktop screen reader market, followed by NVDA at around 30%. On mobile devices, VoiceOver dominates iOS usage, and TalkBack is the primary screen reader on Android. Overall, JAWS and NVDA together represent roughly 70% of desktop screen reader usage.
How do screen readers work?
Screen readers work by accessing the accessibility tree, a structured representation of the web page that the browser builds from the HTML DOM. The screen reader uses the accessibility APIs provided by the operating system (such as UI Automation on Windows, NSAccessibility on macOS, and AccessibilityService on Android) to read element names, roles, states, and values aloud via text-to-speech or to a refreshable Braille display. Proper semantic HTML and ARIA attributes ensure the accessibility tree accurately represents the page content.
What percentage of users rely on screen readers?
The World Health Organization estimates that at least 2.2 billion people globally have a near or distance vision impairment. While not all of these users require a screen reader, surveys indicate that millions actively use screen readers daily. The WebAIM survey consistently finds that the vast majority of screen reader users are people who are blind or have low vision, though a growing number of users with cognitive and learning disabilities also use screen readers or read-aloud features.
Is VoiceOver the same on Mac and iPhone?
No. While both are called VoiceOver and share the same brand, they have different interfaces and commands. macOS VoiceOver uses keyboard shortcuts with the VO modifier (Control + Option), whereas iOS VoiceOver uses touch gestures such as swipe, double tap, and the rotor (a two-finger twist). The underlying accessibility APIs also differ between macOS and iOS. You should test with both if your site serves desktop and mobile users.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences