Screen Reader Testing: How to Check Your Website with VoiceOver and NVDA

Picture the new website of a community college offering evening classes. The team did solid work: the design is calm, the contrast is fine, and the automated accessibility check flags only two minor issues. Two weeks after launch, an email arrives. A blind woman wanted to sign up for a Spanish class and gave up. On the course page, she heard “Learn more, link” five times in a row. In the registration form, she could not tell which field she was in. And after she pressed “Register,” nothing happened, as far as she could hear.

The team never noticed any of these problems, because they had never experienced the site the way screen reader users do: as a sequence of words, roles and states, with no layout and no quick glance across the page. A screen reader test gives you that change of perspective. With a handful of commands and about 20 minutes per page type, you can find most of the serious issues yourself.

This article shows how screen reader users explore a website, how to turn on VoiceOver and NVDA, which commands you actually need and what a compact test routine looks like. The community college website serves as a running example throughout. It is made up, but typical.

What a screen reader does and why you should try one yourself

A screen reader is software that turns the content and controls on a screen into speech or braille. It does not read what you see. It reads what the browser tells it about the page: text, headings and their levels, links, buttons, form fields with their labels, and states such as “selected” or “expanded.” Whether that information is correct depends on the HTML and, where used, on ARIA, a set of extra attributes that describe roles and states for assistive technologies.

Automated tools catch some of this, such as a missing alt attribute. What they cannot judge is whether a label makes sense, whether the heading structure is logical or whether a status message arrives at the right moment. For an overview of automated and manual methods, see Accessibility Testing: Tools and Methods for UX Designers.

How screen reader users explore a website

Sighted people skim a page in seconds and then jump to whatever looks interesting. Screen reader users essentially do the same thing with different tools. Instead of having the page read from top to bottom, they use keyboard shortcuts to jump from heading to heading, link to link or region to region. Or they bring up a list of all headings or links and pick from it.

How common these strategies are is documented in the Screen Reader User Survey by WebAIM, an organization within the Institute for Disability Research, Policy & Practice at Utah State University. The eleventh edition ran in July and August 2026 and received 1,780 valid responses. Asked how they first try to find information on a lengthy page, respondents said:

• 67.8 percent: navigate through the headings
• 12.5 percent: use the find feature
• 9.7 percent: read through the page
• 6.7 percent: navigate through the links
• 3.4 percent: navigate through landmarks

Headings are by far the most important orientation tool. 88.3 percent of respondents find heading levels very or somewhat useful. Landmarks, meaning marked-up page regions such as the header, navigation, main content and footer, are rarely the first step, but people do use them: 28.3 percent navigate by landmarks “whenever they’re available” or “often,” and another 32.7 percent sometimes. So-called skip links, which jump straight to the main content, are used always or often by 37.7 percent.

Some context: the sample is not controlled, and WebAIM notes that it may not represent all screen reader users. More than half of the responses came from North America. The previous survey, from December 2023 and January 2024, shows how much such numbers can shift: back then, 40.5 percent named JAWS as their primary desktop or laptop screen reader and 37.7 percent NVDA, compared with 55.0 and 32.9 percent in 2026. Headings, however, were clearly in the lead then too (71.6 percent), and that is what matters for your test.

One more number matters in practice: 91.8 percent of respondents also use a screen reader on a mobile device, most often VoiceOver on iPhone or iPad (72.2 percent). If you only test on desktop, you are missing a large part of reality.

Which screen reader to test with

Two free starting points are the obvious choice:

• NVDA on Windows: NVDA (NonVisual Desktop Access) is a free, open-source screen reader by NV Access, translated into more than 50 languages. It works with Chrome, Firefox and Edge. In the WebAIM survey, “NVDA with Chrome” was the second most common combination after “JAWS with Chrome.”
• VoiceOver on Mac and iPhone: VoiceOver is built into macOS and iOS. According to WebAIM, it currently works best with Safari on the Mac. On the iPhone, it covers the most common mobile setup.

JAWS, the most widely used desktop screen reader in the survey, is commercial and belongs in a professional audit. To get started, NVDA or VoiceOver is enough, as long as you pair them with the browsers people actually use them with.

NVDA: getting started and the essential commands

Download NVDA from the NV Access website and install it. After that, Ctrl+Alt+N starts the screen reader. Almost all commands use the so-called NVDA key. By default, that is the Insert key, and you can switch it to Caps Lock. WebAIM recommends choosing the desktop keyboard layout even on a laptop, because otherwise some commands that rely on the number pad are missing.

One concept is worth understanding before you start: NVDA has a browse mode and a focus mode. In browse mode, single letters move you around the page. In focus mode, keystrokes go to the form field so you can type. NVDA usually switches automatically when you tab into an input field and signals this with a sound. NVDA+Space switches manually.

For a first test, these commands are all you need:

• Ctrl: stop speech immediately
• NVDA+Down Arrow: read everything from the current position
• H: next heading, 1 to 6: next heading at that level
• D: next landmark
• K: next link
• F: next form field, B: next button
• G: next graphic, T: next table
• Shift plus any of these letters: move in the opposite direction
• NVDA+F7: elements list with all links, headings and landmarks
• NVDA+Q: quit NVDA

A tip for everyday testing: in the NVDA menu (NVDA+N), under Tools, you will find the Speech Viewer. It shows everything NVDA says as text in a window, so you can copy findings word for word into your notes.

VoiceOver on the Mac and the iPhone

On the Mac, Command+F5 turns VoiceOver on and off. If your Mac or Magic Keyboard has Touch ID, you can also hold the Command key and quickly press Touch ID three times. Or go to System Settings, Accessibility, VoiceOver.

VoiceOver commands start with the VO keys. By default, that means pressing Control+Option together, or Caps Lock on its own. The commands you need:

• Control: pause speech, press again to resume
• VO+A: start reading
• VO+Right Arrow and VO+Left Arrow: next or previous item
• VO+Command+H: next heading, add Shift for the previous one
• VO+Command+L: next link
• VO+Command+J: next control
• VO+Command+G: next graphic
• VO+U: open the rotor

The rotor is VoiceOver’s counterpart to NVDA’s elements list. Use the left and right arrow keys to switch between lists such as headings, links or form controls, and press Return to jump to the selected item. In most lists, you can type to filter. In the headings list, for example, typing “3” shows only third-level headings. You can also reach landmarks through the rotor, provided the page has them.

Two features are especially useful for testing. The caption panel shows the spoken text on screen, similar to NVDA’s Speech Viewer. And the screen curtain (VO+Shift+Fn+F11) blacks out the display so you truly have to rely on speech alone. WebAIM recommends exactly that for honest testing.

On the iPhone, you turn VoiceOver on under Settings, Accessibility, VoiceOver. One important step before you do: set up the Accessibility Shortcut so you can turn VoiceOver off again by triple-clicking the side button. With VoiceOver on, all gestures change. The essential ones:

• A single tap selects an item and reads it aloud, a double tap activates it.
• Swiping right or left moves to the next or previous item.
• Rotating two fingers on the screen, as if turning a dial, opens the rotor. Choose, for example, “Headings” or “Links,” then swipe up or down to jump.
• Swiping up with two fingers reads everything from the top of the screen, and a two-finger tap stops speech.

The 20-minute routine

The following routine is meant for a single page or page type, such as the home page, a course detail page or a registration form. Use one combination of screen reader and browser per run, note both with their versions and, ideally, turn off the screen.

1. First impression: title and language (1 minute)

Load the page and listen to what the screen reader says first. Usually, that is the page title. “Home” or “Untitled” helps nobody who has several tabs open. Also listen to the pronunciation: if the text sounds as if it is read with the wrong accent, the page language is set incorrectly.

On the community college website, every course page was simply titled “Course details | College.” After the redesign, the course name comes first: “Spanish A1, evening class | Springfield Community College.”

2. Headings (4 minutes)

Open the elements list (NVDA+F7) or the rotor (VO+U) and display all headings. Then step through the page once with H or VO+Command+H. Three questions:

• Does the list of headings on its own work as a meaningful table of contents?
• Is there exactly one first-level heading that says what the page is about?
• Do the levels match the content structure, or were they chosen by font size?

On the course page, the team found two typical mistakes. The course name was visually large, but technically just bold text, not a heading. And “Dates,” “Instructor” and “Fees” were headings, but at level four, because the design called for a small font. Before the fix, a screen reader user heard “Subscribe to our newsletter” as the first heading in the list. Now the list starts with the course name at level one, followed by the sections at level two. For a broader look at structuring content, see How to Structure Content the Right Way.

3. Landmarks (2 minutes)

Jump through the landmarks with D in NVDA or via the rotor in VoiceOver. At a minimum, expect a header, a navigation, main content and a footer. If there are several navigation regions, they should have distinct names, such as “Main navigation” and “Footer navigation.” Also check whether there is a skip link that leads directly to the main content.

The community college site initially had no landmarks at all, because the layout consisted entirely of generic containers. After the fix, one jump takes you to the main content instead of listening your way past 40 navigation links.

4. Links and buttons (3 minutes)

Bring up the list of links. Every link should make sense on its own, because that is exactly how people encounter it in this list. “Learn more,” “Click here” or “Next” mean nothing without context.

Listen for roles at the same time: anything that triggers an action on the page should be announced as a button, anything that leads to another page as a link. And icon buttons need a name. A heart icon that is announced only as “button” does not reveal that it saves a course to your list.

• Before: In the course overview, “Learn more, link” five times, plus an unnamed “button” for the save icon.
• After: “Spanish A1, evening class, link” and “Save Spanish A1 to my list, button.” Visually, hardly anything changed, because the course title itself is now the link.

5. Images (2 minutes)

Jump through the graphics with G or VO+Command+G. Informative images need alt text that conveys their message. Decorative images should not be announced at all. Typical findings are file names like “IMG_4711.jpg,” alt text like “image” and images of text, such as a banner with the registration deadline whose information is missing from the alt text.

On the course page, the screen reader used to say “course-header-final-2, image.” Now the mood photo is marked as decorative and skipped, while the “Registration closes March 15” banner carries its text as alt text.

6. Forms (4 minutes)

Forms are where screen reader tests uncover the most serious problems. Go through the registration form once with Tab and once with F, and fill it out completely. For each field, the screen reader should announce the label, the field type and, where applicable, “required.” Placeholder text inside the field does not replace a label. Then submit the form with deliberate errors and listen: Is the error announced? Can you get to the field in question? Is the error message associated with the field so it is read out when the field receives focus?

• Before: “Edit, blank,” three times in a row. The labels “First name,” “Last name” and “Email” existed only as gray placeholder text. After submitting, invalid fields got a red border, and nothing was announced.
• After: “First name, required, edit.” After submitting, focus moves to an error summary at the top of the form that lists each error as a link to the field, and each field reads its error message when focused.

More rules for good forms, which help people without screen readers too, are in Forms Nobody Abandons.

7. Dynamic content and status messages (2 minutes)

Many websites change content without reloading the page: a filter updates the result list, a button adds something to the cart, a form reports “Sent successfully.” Sighted people notice the change. Screen reader users only find out if the message is marked up as a so-called live region, an area whose changes the screen reader announces on its own. Success criterion 4.1.3 of the WCAG (Status Messages) requires exactly this: status messages must be presentable to users by assistive technologies without receiving focus. The W3C’s explanatory material gives a message like “5 results returned” after a search and an updated cart count as examples.

So test every interaction that changes something on the page, and listen. On the community college site, nothing seemed to happen for screen reader users after pressing “Register.” The confirmation appeared above the form but was never announced. Now the screen reader immediately says “Registration successful. We have sent a confirmation to your email address.” The reverse also applies: not every little thing belongs in a live region. Hearing “3 suggestions available” after every keystroke gets annoying fast.

8. Dialogs and overlays (2 minutes)

Open every modal on the page, typically cookie banners, newsletter overlays or confirmation dialogs. The dialog pattern in the W3C’s ARIA Authoring Practices Guide describes what should happen: when the dialog opens, focus moves into it. Tab and Shift+Tab stay inside the dialog. Escape closes it. When it closes, focus returns to the element that opened it. Content behind the dialog is inert while it is open, and the dialog has a name, usually its visible heading.

In a screen reader test, you hear the errors right away. On the community college site, the “Course saved” dialog opened, but focus stayed behind the overlay and the screen reader cheerfully kept reading the page. After closing, focus landed at the top of the page. Now the screen reader announces “Course saved, dialog” on opening, reads the short text, and after closing, you continue at the same spot in the course list.

Recording findings so someone can fix them

A finding like “screen reader broken” helps nobody. For each finding, note what you did, what you heard, what you expected and which combination you used. For example: “Course page, moved through links with K. Heard: ‘Learn more, link’ five times. Expected: course name in the link text. NVDA with Firefox.”

Referencing the WCAG criterion makes the urgency clear, for example 1.1.1 for alt text, 1.3.1 for headings and form labels, 2.4.4 for link purpose or 4.1.2 for the name, role and value of controls. That helps especially when legal requirements apply, such as Germany’s BFSG, which implements the European Accessibility Act (see BFSG in Practice). Prioritize by impact: a form that cannot be submitted is more critical than a skipped heading level.

Limits: what a screen reader test cannot do

As useful as your own test is, it has clear limits, and you should know them.

You lack daily practice. In the WebAIM survey, 57.8 percent rate their screen reader proficiency as advanced. People who use a screen reader every day rely on shortcuts, high speech rates and their own strategies. You will miss some problems that are obvious to experienced users, and you will think some obstacles are worse than they are in practice.

Every combination behaves differently. NVDA with Firefox, JAWS with Chrome and VoiceOver with Safari can announce the same page differently. A test with one combination is a sample, not proof.

A screen reader test is not a complete audit. It tells you little about contrast, zoom, motion, plain language or keyboard use without a screen reader. People with low vision, motor impairments or cognitive disabilities have different needs. Why accessibility needs a broader view is covered in Why Accessibility Is More Than Contrast and Font Size.

It does not replace testing with disabled people. The W3C’s Web Accessibility Initiative stresses that evaluating with people with disabilities reveals problems a pure conformance check misses, and that it often surfaces general usability problems as well. At the same time, it warns against assuming that input from one person applies to everyone with the same disability. Your own test is therefore preparation, so that a usability test with screen reader users does not get stuck on basics.

Conclusion

Screen reader users do not read websites from top to bottom. They jump through headings, landmarks, links and form fields. Whether that works depends on things that are invisible in the layout: the heading structure, meaningful link text, labels, status messages and focus handling in dialogs.

With NVDA or VoiceOver, a handful of commands and 20 minutes per page type, you can find the worst problems yourself. On the community college site, none of the fixes changed the visual design, and yet registration now works for many more people.

Your own test is a start. You will only really know whether your website works once people who use a screen reader every day have tested it.

Checklist

• Screen reader and browser are paired realistically and noted with versions, for example NVDA with Chrome or Firefox, VoiceOver with Safari.
• The page title names the specific content, and the page language is set correctly.
• The list of headings works on its own as a table of contents with exactly one first-level heading.
• Header, navigation, main content and footer are reachable as landmarks, and a skip link leads to the main content.
• Every link makes sense in the links list without context, and icon buttons have a name.
• Informative images have meaningful alt text, decorative images are skipped.
• Every form field announces its label, type and required status, and errors are announced and associated with their fields.
• Status messages such as confirmations or result counts are announced without moving focus.
• Dialogs take focus, keep it, close with Escape and return it afterwards.
• The routine has also been run with VoiceOver on the iPhone.
• Findings are documented with action, what was heard, what was expected and the combination used.
• A test with people who use a screen reader every day is planned.

Sources

• WebAIM (2026): Screen Reader User Survey #11 Results. WebAIM, Utah State University
• WebAIM (2024): Screen Reader User Survey #10 Results. WebAIM, Utah State University
• WebAIM: Using NVDA to Evaluate Web Accessibility
• WebAIM: Using VoiceOver to Evaluate Web Accessibility
• NV Access (2026): NVDA 2026.2 User Guide
• NV Access: About NVDA
• Apple: Turn VoiceOver on or off on Mac
• Apple: VoiceOver search commands on Mac
• Apple: Use the VoiceOver rotor on Mac
• Apple: Navigate web pages by landmarks with VoiceOver on Mac
• Apple: Use the screen curtain with VoiceOver on Mac
• Apple: About the VoiceOver rotor on iPhone or iPad
• Apple: About the Accessibility Shortcut for iPhone, iPad, and iPod touch
• W3C (2024): Understanding Success Criterion 4.1.3: Status Messages
• W3C (2024): Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 12 December 2024
• W3C: ARIA Authoring Practices Guide, Dialog (Modal) Pattern
• Shawn Lawton Henry, W3C WAI (2024): Involving Users in Evaluating Web Accessibility