Screen Reader Testing: How to Test Your Website Step by Step

Screen reader testing means using your website the way a blind or low-vision visitor does: with the screen reader announcing content aloud and the keyboard (or touch gestures) doing the navigating. It is the fastest way to discover problems that automated tools miss, such as confusing link text, unlabelled buttons and a reading order that makes no sense. You don't need to be an expert. With one free tool and about 30 minutes, you can learn enough to find the most serious issues on your own site.

This guide covers which screen readers to use, the basic commands, what to listen for, the most common problems and a checklist you can reuse.

Which screen reader should you test with?

Different people use different screen readers, and each one behaves slightly differently with browsers. Here are the four you are most likely to meet.

If you can only test with one, start with NVDA on Windows (free) or VoiceOver on a Mac or iPhone (already installed). Then add mobile testing, because many screen reader users browse on phones.

Getting started with screen reader testing

Before you begin, lower your expectations of speed. The voice will talk fast and feel overwhelming at first. You can slow it down in the settings. Turn off your monitor or close your eyes for part of the test once you are comfortable — it shows how dependent your page is on visuals.

NVDA (Windows)

Download NVDA from the official NV Access website and install it. The "NVDA key" is Insert by default (Caps Lock can be enabled as well).

• Ctrl — stop speaking
• Down arrow — read the next line
• NVDA + Down arrow — read everything from here
• H / Shift + H — next / previous heading
• 1 to 6 — jump to heading level 1 to 6
• K — next link
• F — next form field
• B — next button
• D — next landmark
• T — next table
• G — next graphic
• NVDA + F7 — elements list (links, headings, landmarks)
• Tab — move between focusable elements
• NVDA + Space — toggle between browse mode and focus mode
• NVDA + Q — quit NVDA

JAWS (Windows)

JAWS uses very similar single-letter navigation keys in its virtual cursor: H for headings, F for form fields, B for buttons, T for tables and R for regions (landmarks). Insert + F6 lists headings and Insert + F7 lists links. Because NVDA and JAWS share so many conventions, testing in NVDA first covers a lot of ground.

VoiceOver (Mac)

Press Cmd + F5 to turn VoiceOver on or off. The "VO keys" are Control + Option.

• VO + Right / Left arrow — next / previous item
• VO + A — read from here
• VO + U — open the rotor (lists of headings, links, landmarks, form controls); use left/right arrows to change list
• VO + Cmd + H — next heading
• VO + Space — activate an item
• Tab — next focusable element

VoiceOver (iPhone) and TalkBack (Android)

On iPhone, enable VoiceOver in Settings, Accessibility. Swipe right or left to move between items, double tap to activate, and use the rotor (twist two fingers on the screen) to jump by headings or links.

On Android, enable TalkBack in Settings, Accessibility. Swipe right or left to move, double tap to activate, and use the TalkBack menu or reading controls to navigate by headings, links or controls. Exact gestures vary slightly between Android versions, so check the built-in tutorial.

What to listen for

When you test, you are checking that every piece of content and every control has the right name, role and state. For example, "Search, edit text" or "Menu, button, collapsed".

Page title and language

The first thing announced should be a meaningful page title. If the page is in English but the language attribute is wrong, the voice may use the wrong pronunciation.

Headings and landmarks

Pull up the headings list. Does it read like a table of contents? Is there one clear main heading? Are levels logical? Then check landmarks: header, navigation, main and footer should all be present.

Links and buttons

Open the links list. Each link should make sense out of context. "Click here", "Read more" and "Learn more" repeated ten times are useless. Buttons, especially icon buttons like a search magnifier or a hamburger menu, must announce a clear name.

Images

Informative images should announce helpful alt text. Decorative images should be silent. Listen for file names like "IMG_2041.jpg" — a sure sign of missing alt text. Our alt text guide explains how to fix this.

Forms

Each field should announce its label, its type and whether it is required. Error messages must be announced when they appear, not only shown in red. See our guide to accessible forms for patterns that work.

Dynamic content

Open menus, modals, accordions, tabs and carousels. Does the screen reader announce that something expanded? Does focus move into a dialog and return when it closes? Are "Added to cart" or "Saved" messages announced?

Common screen reader problems

• Unlabelled icon buttons announced as just "button".
• Images without alt text reading out file names or URLs.
• Fake buttons built from a div or span that can't be reached with Tab or activated with Enter.
• Skipped or missing headings, making it hard to scan the page.
• Placeholder used as a label, which disappears once the user types.
• Modals that don't trap focus, so the user ends up reading the page behind.
• Hidden content still read out, such as off-screen menus that are visually hidden but not hidden from assistive technology.
• Reading order that differs from visual order because of CSS positioning.
• Overuse of ARIA, such as aria-label on elements that already have visible text, causing mismatches.

Many of these overlap with keyboard issues, so pair this test with our keyboard accessibility guide.

Screen reader testing checklist

Use this list on each key template: home page, product or article page, form and checkout.

1. The page title is announced and describes the page.
2. A "skip to main content" link works.
3. The headings list gives a clear outline with one main heading.
4. Header, navigation, main and footer landmarks exist.
5. Every link is understandable on its own.
6. Every button, including icon buttons, has a clear name.
7. Informative images have useful alt text; decorative images are silent.
8. Every form field announces its label and required state.
9. Errors are announced and explain how to fix them.
10. Menus, accordions and tabs announce expanded or collapsed state.
11. Dialogs receive focus, keep it inside and return it when closed.
12. Status messages (cart updates, saves) are announced.
13. Tables have header cells that are announced with data.
14. Reading order matches the visual order.
15. Nothing important is conveyed by colour or visual position only.

Combine manual and automated testing

Screen reader testing is slow, so don't spend it on problems a machine can find. Run an automated scan first to catch missing alt text, empty buttons, missing labels and contrast issues, then use the screen reader for the things only a human can judge. The Openwise free accessibility checker loads your page in a real browser and runs 20+ WCAG 2.2 checks with fix tips, which is a good first pass before you turn on NVDA or VoiceOver. Pair this with the full WCAG checklist for complete coverage.

Remember that you are not a regular screen reader user. If you can, include disabled users in usability testing — they will find things you won't.

Frequently asked questions

Which screen reader is best for testing?

There is no single best one. NVDA is free and widely used on Windows, VoiceOver is built into every Mac and iPhone, and JAWS is common in workplaces. Test with at least one desktop and one mobile screen reader for reasonable coverage.

Do I need to buy JAWS to test my website?

No. JAWS offers a time-limited demo mode, and NVDA is free and shares many of the same navigation conventions. Most teams start with NVDA and VoiceOver and add JAWS testing for important releases or enterprise clients.

How long does screen reader testing take?

Learning the basic commands takes an hour or two. After that, testing a single page template carefully usually takes 15 to 30 minutes. Testing templates rather than every page keeps the effort manageable.

Can automated tools replace screen reader testing?

No. Automated tools can detect missing attributes, but they cannot tell whether alt text is accurate, whether link text makes sense or whether a custom widget is usable. Use both: automation for breadth, screen readers for real-world experience.

Should I test on mobile as well as desktop?

Yes. Many screen reader users browse on smartphones, and mobile layouts often hide menus and content in ways that break for VoiceOver or TalkBack. Always test your mobile navigation and key forms on a phone.

Conclusion

Screen reader testing turns accessibility from an abstract checklist into something you can hear. Learn a handful of commands, check headings, links, images, forms and dynamic content, and fix the problems you find. Start with an automated scan so your manual time goes further: try our free accessibility checker today.