How to Test Your Website With a Screen Reader

Automated accessibility tools catch only part of the problems on a page. Hearing your site through a screen reader reveals issues those tools miss: confusing links, missing labels, and strange reading order. A basic test is quick, and you don't need to be an expert.

Choose a screen reader

• NVDA is free on Windows
• VoiceOver is built into Mac, iPhone, and iPad
• TalkBack is built into Android
• Narrator is built into Windows

Test with at least one on a desktop and, if possible, one on a phone. Real users have varying setups, so aim for the most common combos for your audience.

Get comfortable first

Spend ten minutes learning the basics before testing your site. Use the screen reader's built-in tutorial if there is one. Key commands differ by tool and settings, so check each tool's documentation. Common ideas:

• A modifier key (such as Caps Lock or Insert for NVDA, or Control plus Option for VoiceOver) is used for many commands
• Browse mode lets you move through content by headings, links, landmarks, and form fields using single-key shortcuts
• Tab moves between interactive elements
• A command lists headings, links, and landmarks

Practice on a site you know, and turn the volume to a comfortable level. Many testers also like to display the speech text so they can read along.

A basic test routine

For each key page, such as the homepage, a service page, the contact page, and checkout, try this:

1. Load the page and listen to the title. Does it describe the page?
2. Look for a skip link. Press Tab once. See skip links and landmarks
3. List the headings. Do they form a sensible outline? See how to use headings for SEO
4. List the landmarks. Is there a main region, navigation, and footer?
5. List the links. Do the names make sense out of context? "Read more" repeated ten times isn't helpful.
6. Go through the content in order. Does the reading order match the visual order?
7. Check images. Is the alt text useful, and are decorative images ignored? See alt text best practices
8. Operate the navigation menu. Can you open submenus and find the current page? See accessible navigation menus
9. Fill in a form. Are labels announced? Are required fields and errors explained? See accessible forms
10. Open a popup or dialog. Does focus move into it and return when it closes? See accessible modals and popups
11. Try interactive widgets, such as accordions, tabs, and carousels. Are states announced, like expanded or collapsed?
12. Play a video. Are controls labeled? Are captions available? See video captions and transcripts

Record what you find

Note the page, the problem, what you heard, and what you expected. Prioritize problems that block key tasks, such as submitting the contact form or completing a purchase.

Also test without a mouse

Navigate your site by keyboard only. See keyboard navigation and focus.

Limits of your testing

If you're new to screen readers, you'll use them differently from experienced users, who move much faster and know shortcuts. Treat your test as a way to find obvious barriers, not a final verdict. For important sites, consider paying people who use assistive technology daily to test with you. See user testing on a budget.

Fix and retest

Fix issues at the source, in the HTML and content, rather than adding patches. See ARIA basics.

The bottom line

Spend an hour listening to your key pages. You'll quickly find the issues that matter most, and you'll build empathy for the people who rely on them.