Which screen reader and browser to test with, the handful of commands you actually need, and a short routine that finds the problems automated tools miss.
In short
Screen reader testing means using your product the way a blind or low-vision user does, by listening instead of looking. For most teams, three setups cover the ground: NVDA with Chrome or Firefox on Windows, VoiceOver with Safari on iPhone and Mac, and TalkBack with Chrome on Android. Learn ten commands and test every critical journey.
A screen reader (skärmläsare in Swedish) is software that reads the interface aloud or to a braille display and lets the user navigate by headings, links, landmarks and form fields. Automated scanners can tell you an image lacks alt text; only screen reader testing tells you whether the page makes sense when heard. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for developers and testers who want a repeatable routine rather than a one-off experiment.
Which screen readers should you test with?
Test with the screen readers your users actually run, which in Europe means NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android.
WebAIM's tenth Screen Reader User Survey, run in late 2023 and early 2024 with 1,539 respondents, found JAWS at 40.5 percent and NVDA at 37.7 percent as the primary desktop screen reader, with NVDA the most common in Europe. On mobile, 91.3 percent of respondents used a screen reader and VoiceOver was the most common at 70.6 percent. WebAIM notes the sample is self-selected, so treat the numbers as indicative.
Platform
Screen reader
Browser to pair with
Cost
Start it
Windows
Screen reader
NVDA
Browser to pair with
Chrome or Firefox
Cost
Free, open source
Start it
Ctrl+Alt+N after install
Windows
Screen reader
JAWS
Browser to pair with
Chrome
Cost
Commercial licence
Start it
From the Start menu
macOS
Screen reader
VoiceOver
Browser to pair with
Safari
Cost
Built in
Start it
Command+F5
iOS and iPadOS
Screen reader
VoiceOver
Browser to pair with
Safari
Cost
Built in
Start it
Settings, Accessibility, VoiceOver
Android
Screen reader
TalkBack
Browser to pair with
Chrome
Cost
Built in on most devices
Start it
Hold both volume keys if the shortcut is on
A practical minimum is NVDA for desktop and VoiceOver on iPhone for mobile, with TalkBack added when Android is a significant share of your traffic or you ship a native Android app. JAWS matters most for enterprise tools used by employees who already have a licence.
What do you need to know before you start?
Screen readers have two ways of moving through a page, and most confusion in early testing comes from not knowing which one is active.
On Windows, NVDA uses browse mode to read a page, where single letters jump between elements, and focus mode to type into fields, where keys go to the page. NVDA usually switches automatically when you enter a form field; NVDA+Space toggles manually. The NVDA key is Insert by default and Caps Lock can be set as an alternative, as the NVDA user guide describes.
VoiceOver on the Mac uses the VO keys, Control+Option by default, and a rotor (VO+U) that lists headings, links, landmarks and form controls. On iPhone and Android you move with swipes instead of keys.
Turn on the speech viewer in NVDA, or the caption panel in VoiceOver, so you can read what is spoken while you learn.
The commands that cover most tests
Ten commands per platform cover nearly every check a developer needs to run.
NVDA on Windows (browse mode):
- H and Shift+H move to the next and previous heading; 1 to 6 jump to that heading level.
- D moves between landmarks, such as header, navigation, main and footer.
- K moves between links, F between form fields, T between tables and L between lists.
- Tab moves through interactive elements, like a keyboard user.
- NVDA+F7 opens the elements list, a quick view of all headings, links and landmarks.
- Ctrl stops speech; the down arrow reads the next line.
VoiceOver on iPhone:
- Swipe right or left with one finger to move to the next or previous element.
- Double-tap to activate the focused element.
- Rotate two fingers to open the rotor, then swipe up or down to jump by headings, links or form controls.
- Two-finger swipe up reads the whole screen from the top.
TalkBack on Android: swipe right or left to move, double-tap to activate, and use reading controls to jump by headings or links. Google's TalkBack gesture guide notes that some gestures change on devices with gesture navigation, so check the guide for your version.
A 20-minute screen reader testing routine
Run the same routine on every critical journey, because a fixed set of questions makes results comparable between releases and testers.
- Listen to the page title. It should say where you are, for example "Checkout, step 2 of 3, Shop name".
- List the headings. Do they outline the page in a logical order, without skipped levels or missing sections?
- List the landmarks. Is there one main region, and are navigation areas labelled when there are several?
- Tab through the interactive elements. Each should announce a name, a role and a state, such as "Subscribe, checkbox, not checked".
- Check images. Informative images should have a meaningful description; decorative ones should be silent.
- Fill in a form wrongly. Are labels, required states, hints and errors announced? Our guide to accessible forms lists what to expect.
- Open and close dynamic content. Menus, dialogs and accordions should announce whether they are expanded, focus should move into a dialog and return when it closes.
- Trigger status messages. "Added to basket" or "3 results" should be announced without moving focus.
- Complete the journey. Can you finish the task without seeing the screen?
Record each finding with the screen reader, browser and versions, what you heard, what you expected and the affected WCAG criterion. Many issues found this way also affect keyboard users, so combine this routine with keyboard accessibility testing.
How does screen reader testing fit into the release process?
Screen reader testing fits best as a short manual check on changed journeys every sprint, with a full pass before major releases, alongside automated scans in the pipeline.
Automated tools catch structural errors quickly, but they cannot judge whether an announcement makes sense. Our comparison of automated accessibility testing and a manual audit explains how the two divide the work. Three habits make the manual part sustainable:
- Test components once, in isolation. When the design system's menu, dialog and tabs work with screen readers, every page that uses them inherits the result.
- Rotate the tester. Developers who test their own work learn the patterns fastest.
- Involve real users for the big questions. Developers testing with a screen reader find technical defects; experienced screen reader users find usability problems that sighted testers miss.
Keep reading
From our work
Client Case: Lea BankLea Bank rebuilt its digital platform with Strapi, React, GrowthBook, GA4, and BigQuery to improve SEO, A/B testing, and marketing autonomy.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Is NVDA free to use for testing?
Yes. NVDA is a free, open-source screen reader for Windows developed by NV Access, a non-profit organisation, and it can be used for commercial testing without a licence fee. NV Access accepts donations. It works best with Chrome and Firefox, and it is among the two most used desktop screen readers in WebAIM's surveys, alongside the commercial JAWS.
Can I test with VoiceOver on a Mac instead of a Windows screen reader?
VoiceOver on macOS is useful, but it does not replace a Windows screen reader. Most desktop screen reader users run Windows with NVDA or JAWS, and these handle web pages differently from VoiceOver. If you only have a Mac, run NVDA in a Windows virtual machine for desktop checks, and use VoiceOver on iPhone, which is the most common mobile screen reader.
How often should developers test with a screen reader?
Test every new or changed component and every changed journey before it is merged, with a short routine of five to twenty minutes. Run a fuller pass across critical journeys before major releases and after redesigns. Frequent, short tests by the people who wrote the code find more issues earlier than a rare, long audit at the end of a project.
Does passing screen reader testing mean a site meets WCAG?
No. Screen reader testing covers many criteria, especially names, roles, states, structure and announcements, but not all of them. Contrast, reflow at 320 pixels, target size and several cognitive criteria need other methods. Combine screen reader checks with automated scans, keyboard testing and zoom testing, and map each finding to a WCAG criterion so coverage is visible.
