Screen Reader Testing Guide

Screen Readers: The Essential Testing Tool

Automated accessibility scanners catch approximately 30–40% of WCAG failures. The remainder require manual testing with real assistive technologies. Screen readers are the most important manual testing tool because they expose failures in semantic structure, accessible names, state announcements, and dynamic content — all areas that automated tools cannot reliably assess.

You do not need to be an expert screen reader user to run effective accessibility tests. You need to know enough to navigate a page, identify what gets announced, and recognize when something is wrong. This guide gives you that foundation.

The Testing Matrix: Which Screen Reader + Browser

Screen readers and browsers interact at the OS accessibility API level. Not every combination works well. Use these tested pairings:

• NVDA + Firefox (Windows) — the most common combination in accessibility testing; free, open source.
• JAWS + Chrome or Edge (Windows) — the most common combination among blind users in enterprise; paid license.
• VoiceOver + Safari (macOS/iOS) — the standard for Apple platform testing; built into macOS and iOS.
• TalkBack + Chrome (Android) — standard Android screen reader; built into Android.
• Narrator + Edge (Windows) — Microsoft's built-in screen reader; useful for Windows-specific testing.

Test with at minimum NVDA+Firefox and VoiceOver+Safari to cover the most common user configurations.

NVDA Basics: Getting Started

Download NVDA from nvaccess.org (free). After installation:

• NVDA modifier key (NVDA key) is Insert by default (or CapsLock if you configure it).
• NVDA+Space toggles between Browse mode (reading) and Forms/Focus mode (interacting with forms).
• H navigates to next heading; Shift+H goes to previous heading.
• K navigates to next link; F navigates to next form field.
• 1–6 navigate to heading levels (1 = h1, 2 = h2, etc.).
• NVDA+F7 opens the Elements List — a dialog showing all headings, links, landmarks, and form fields on the page.
• NVDA+F5 opens the forms mode, NVDA+Ctrl+F opens the find dialog.

VoiceOver Basics: Getting Started

VoiceOver is enabled with Command+F5 (or triple-press Touch ID). The VO modifier is Ctrl+Option (VO key):

• VO+Right/Left Arrow — move to next/previous element.
• VO+Shift+Down Arrow — interact with a group (enter a list, table, iframe).
• VO+Shift+Up Arrow — stop interacting with a group (exit a list, table, iframe).
• VO+U — open the Rotor, which lets you navigate by headings, links, form controls, tables, and landmarks.
• VO+F3 — read item description.
• VO+Space — activate the focused element.

Testing Procedure: Page Structure

1. Navigate to the page and let it load completely.
2. Open NVDA Elements List (NVDA+F7) or VoiceOver Rotor (VO+U). Select "Headings". Verify: there is one h1, headings follow a logical hierarchy, no headings are missing, and headings describe their sections accurately.
3. In the same dialog, select "Landmarks". Verify: there is a main landmark, at least one nav landmark, and navigation landmarks are labeled if there are multiple.
4. In the same dialog, select "Links". Review all link text. Flag any that are "click here", "read more", or a bare URL without meaningful text.

Testing Procedure: Forms

1. Navigate to a form. Switch to Forms Mode (NVDA) or interact with form (VO+Shift+Down).
2. Tab to each form control. Verify the field's label is read aloud before the control type. Example: "Email address, edit text" — not just "edit text".
3. For required fields, verify "required" is announced.
4. Submit the form with invalid data. Verify error messages are announced — either via aria-live, focus movement to the error summary, or the error being associated with the field.
5. For custom selects/comboboxes, verify the selected value is announced and arrow key navigation within the dropdown announces each option.

Testing Procedure: Images and Media

• Navigate to images (press G in NVDA). For each image: verify the alt text is read and is meaningful. Verify decorative images are skipped (not announced at all).
• Navigate to any audio or video players. Verify play/pause buttons have accessible names. Verify captions are available and selectable.

Testing Procedure: Dynamic Content

Dynamic content — live regions, loading states, error messages, toast notifications — is one of the most common sources of screen reader failures:

• Trigger any ajax/dynamic content update (search results, form submission, filter apply). Verify the updated content is announced via aria-live.
• Open modal dialogs. Verify focus moves into the dialog and the dialog role/title is announced. Verify focus is trapped inside the dialog.
• Close modal dialogs. Verify focus returns to the trigger element.
• For single-page app route changes, verify a meaningful page title or heading is announced on navigation.

Interpreting Screen Reader Output

Knowing what should be announced helps identify what is wrong. For a button with text "Submit form": the screen reader should announce "Submit form, button". If it announces "button" only — the button has no accessible name. If it announces "div" — the element is a div with no ARIA role. If it announces nothing — the element is hidden from AT or has tabindex="-1".