TL;DR:

To test your website with a screen reader, turn one on (NVDA is free on Windows, VoiceOver is built into Mac and iPhone), then navigate your site without looking at the screen and listen to whether everything still makes sense. You are checking that images have meaningful alt text, headings are in a logical order, links make sense on their own, forms have labels, and you can reach everything with the keyboard. It takes about 15 minutes to learn the basics, and it will surface issues no automated tool can catch.

This guide is for testing and education. It is not legal advice.

Automated accessibility scanners are useful, but they only catch part of the picture. Many of the issues that actually stop a person from using your site, confusing link text, a form field with no label, a modal that traps focus, can only be found by experiencing the site the way a screen reader user does.

The good news: you do not need to be an expert, and the tools are free. Here is how to test your site with the two most common screen readers, and what to listen for.

Why screen reader testing matters

A screen reader reads a web page aloud and lets a person navigate it with the keyboard instead of a mouse. Millions of people rely on one every day.

When you test with a screen reader, you stop seeing your site and start hearing it. Suddenly a button labeled only with an icon says nothing useful. An image with no alt text is skipped or read as a filename. A heading structure that looked fine visually turns out to make no sense in sequence. These are the issues that matter most, and they are exactly the ones automated tools tend to miss.

Setting up NVDA (Windows, free)

NVDA is a free, open-source screen reader from NV Access. It is the most widely used option for testing on Windows.

1. Download it from the NV Access website and install it.
2. Start NVDA. It will begin reading whatever is focused.
3. Learn the modifier key. NVDA uses a key called the "NVDA key," which is the Insert key by default (you can also set it to Caps Lock).

A few commands to get started:

• Read from here: NVDA key + Down arrow
• Stop speech: Control
• Next heading: H (and Shift + H for the previous one)
• Next link: K
• Next form field: F
• Open the elements list (all headings, links, landmarks): NVDA key + F7

Test in Chrome or Firefox, since those are the most common pairings NVDA users rely on.

Setting up VoiceOver (Mac and iPhone, built in)

VoiceOver comes built into every Mac and iPhone, so there is nothing to install.

On a Mac:

1. Turn it on with Command + F5.
2. VoiceOver uses two keys together, Control + Option, called the "VO" keys.

Starter commands:

• Move to the next item: VO + Right arrow
• Read everything from here: VO + A
• Jump by heading: VO + Command + H
• Open the Rotor (a menu of headings, links, form controls, and more): VO + U

Test VoiceOver on a Mac using Safari, which is its best-supported browser.

On an iPhone:

1. Turn it on in Settings, under Accessibility, then VoiceOver (or set up a triple-click shortcut).
2. Swipe right or left to move between items, and double-tap to activate the selected item.
3. Use the Rotor by rotating two fingers on the screen to switch how you navigate.

Testing on mobile matters, because a large share of accessibility complaints involve mobile experiences.

How to actually run the test

The technique is simple: navigate your site the way a screen reader user would, and pay attention to whether it still makes sense.

• Turn on the screen reader and, if you can, look away from the screen or close your eyes.
• Move through the page in order, then try jumping by headings, by links, and through the form fields.
• Try to complete a real task: find a product, fill in a form, open and close a menu, submit an inquiry.
• Notice every moment where you would be confused, lost, or stuck if you could not see the screen.

Those moments of confusion are your test results.

What to listen for

Run through this checklist as you go:

• Images: does every meaningful image have alt text that describes it, and are decorative images correctly skipped?
• Headings: do they read in a logical order (one H1, then H2s and H3s that make sense in sequence)?
• Links and buttons: does each one make sense on its own? "Read more" and "click here" tell a screen reader user nothing.
• Forms: does every field announce a clear label, and are errors read out when something goes wrong?
• Keyboard access: can you reach and operate everything without a mouse, and is the focus order logical?
• Dynamic content: when something changes on the page (a menu opens, a message appears), is it announced?

If any of these break, you have found a real issue that likely affects real users.

Common problems screen reader testing reveals

These are the issues we see most often when a site is tested with a screen reader for the first time:

• Icon-only buttons with no accessible label
• Images with missing or unhelpful alt text
• Headings used for styling rather than structure
• Form fields with placeholder text but no real label
• Menus and modals that trap keyboard focus or cannot be closed
• Custom components (sliders, tabs, dropdowns) that a screen reader cannot operate

Screen reader testing is one layer, not the whole job

Testing with a screen reader is one of the most valuable things you can do, and it is not the only thing. A complete accessibility approach combines a few layers:

• Automated scans to catch the obvious, high-volume issues quickly
• Manual testing, including screen reader and keyboard testing, for the issues tools miss
• Real user feedback from people who use assistive technology every day
• A personalization layer like AccessBit, which lets visitors adjust contrast, motion, text, and reading preferences to suit their needs

No single layer makes a site accessible on its own. Real accessibility comes from fixing issues in the code, testing the experience, and giving users control, together.

Frequently asked questions

1. What is the best free screen reader for testing?

NVDA on Windows is free and the most widely used for testing. On Mac and iPhone, VoiceOver is built in at no cost. Testing with both covers the majority of real-world screen reader use.

2. Do I need to be blind to test with a screen reader?

No. Anyone can test by turning the screen reader on and navigating without looking at the screen. You will not use it as fluently as a daily user, but you will quickly find the issues that break the experience.

3. Does a screen reader test replace automated accessibility tools?

No, they complement each other. Automated tools catch obvious issues fast. Screen reader and keyboard testing catch the experience-level problems that tools cannot detect. You need both.

4. How long does a basic screen reader test take?

You can learn the basic commands in about 15 minutes, and a focused test of your key pages and flows takes an hour or two, depending on the site.

5. Can an accessibility overlay make my site pass a screen reader test?

No. An overlay or personalization layer can help users adjust their experience, but it does not fix underlying code issues like missing labels or bad heading structure. Those still have to be corrected in the site itself.

Want help closing the gaps a screen reader test reveals?

Testing is the easy part. Fixing the issues, and giving users real control over their experience, is where it counts. AccessBit is the personalization layer that sits on top of properly remediated code, so your visitors can tailor contrast, motion, and readability to their needs.