How to Test a Website with a Screen Reader: A Beginner's Guide

Automated scanners catch 30 to 57 percent of accessibility issues. That is a published number from real research, not a marketing claim. It means a scan like PageAudit will find most of the structural problems on your site (missing alt text, contrast failures, unlabeled form inputs, broken heading order), but it will miss the usability problems that only appear when you actually try to use the page.

The single highest-leverage manual test you can do is screen reader testing. It takes 15 minutes to set up, the software is free, and it reveals problems no automated tool will ever catch. This guide walks you through installing a screen reader, running your first 5-minute test, and knowing what to listen for.

No prior experience with assistive technology required. If you have run an automated scan and want to understand what your site actually feels like for a blind user, start here.

Why Screen Reader Testing Matters

A screen reader does not look at the page. It reads the HTML. That gap between what you see and what the screen reader says is where most accessibility bugs live.

Here are real examples of issues that pass every automated scan and still make a site unusable:

• A "Learn more" link on every feature card. Visually clear (each card has its own image and heading above the link). A screen reader reads each card as "Learn more, link. Learn more, link. Learn more, link." with no way to tell which one goes where.
• A date picker that "works" with the keyboard. Tab gets you to the field, arrow keys open the picker, Enter selects the date. But the screen reader announces nothing when the picker opens, nothing when focus moves, and the selected date is invisible until you Tab off the field.
• A form error that shows in red above the submit button. Visually obvious. A screen reader user who submits the form hears "Submit, button" followed by silence, then wonders why the form did not submit. The error message is invisible because it does not announce when it appears.
• A modal dialog that opens on top of the page. Visually correct: the modal is focused, the background is dim. A screen reader user hears the button they clicked, then the screen reader continues reading whatever comes next in the underlying page, completely unaware the modal exists.

None of those are WCAG rule violations that an automated scanner can detect. All of them are bugs a screen reader user would catch in the first 30 seconds. This is why manual screen reader testing is not optional if you care about real usability.

Which Screen Reader Should You Use?

There are six screen readers you will encounter in accessibility work. You do not need to learn all of them. You need to pick one, become comfortable with it, and use that one consistently.

Screen Reader	OS	Cost	Market Share (approx)
VoiceOver	macOS, iOS	Free, built in	~9% (macOS), ~75% on iOS
NVDA	Windows	Free	~37%
JAWS	Windows	~$1,200/year	~40%
Narrator	Windows	Free, built in	~1%
TalkBack	Android	Free, built in	~90% on Android
Orca	Linux	Free	under 1%

The practical recommendation:

• On macOS: Use VoiceOver. It is built in, free, and matches the experience of every Mac, iPhone, and iPad user.
• On Windows: Install NVDA. It is free, covers 37% of Windows screen reader users, and is close enough to JAWS that findings usually translate. Skip JAWS unless your employer has a license.

You do not need to test with every screen reader. Pick one, learn it well, and run a second pass later with a different one if you want broader coverage. For beginners, VoiceOver on macOS or NVDA on Windows is the right starting point.

Setting Up VoiceOver on macOS

VoiceOver is already installed. You just need to turn it on.

1. Press Command + F5 (or Command + fn + F5 on some MacBooks). VoiceOver starts speaking immediately.
2. If it is your first time, run the VoiceOver Quick Start tutorial by pressing Control + Option + Command + F8. It takes about 20 minutes and is the fastest onboarding.
3. To turn VoiceOver off, press Command + F5 again.

The key modifier for VoiceOver commands is VO (Control + Option). Every VoiceOver command uses VO plus another key. For example, "VO + Right Arrow" means "Control + Option + Right Arrow".

You can also enable "VoiceOver lock" by pressing Control + Option + semicolon. This lets you hold just VO without pressing two modifier keys for every command. Highly recommended once you are comfortable.

Setting Up NVDA on Windows

NVDA is not preinstalled. You download it once.

1. Go to nvaccess.org and click Download NVDA.
2. Run the installer. Choose whether to install permanently or run portably.
3. Launch NVDA. It announces itself immediately.
4. NVDA's modifier key is either CapsLock or Insert. Pick one during setup. Most commands are "NVDA key + letter".
5. To turn NVDA off, press NVDA + Q.

NVDA also includes a built-in tutorial. Press NVDA + N, then go to Help, then Basic Training for NVDA. It is ~3 hours end to end, but you can stop after the first hour and already have the essentials.

Your First 5-Minute Screen Reader Test

You do not need hours of training before you start catching bugs. Here is a 5-minute test you can run on any page right now.

Step 1: Turn off your monitor (or close your eyes)

This is the hardest instruction in the guide. Most beginners watch the screen while the screen reader talks, and their eyes fill in everything the screen reader does not announce. You will never catch the bugs that way.

Turn the brightness all the way down. Close your eyes. Or drape a sheet of paper over the top half of your monitor. The audio output is the only signal that matters.

Step 2: Start at the top of the page

Open the page you want to test. With VoiceOver, press VO + Home to jump to the top. With NVDA, press Ctrl + Home.

Ask the screen reader to read from the top. VoiceOver: VO + A. NVDA: NVDA + Down Arrow. The screen reader will read the entire page from the top.

Step 3: Listen for the page title

The first thing you hear should tell you what page you are on. If it says "PageAuditors" (because that is just the site name in the tab) and then immediately jumps to "Navigation", you are missing an h1 at the top of the page. Every page should announce its main heading early.

Step 4: Tab through every interactive element

Press Tab. Listen for what the screen reader announces. It should say something like "Sign up, button" or "Pricing, link". If it says "button" with no description, or "link" with no text, you have a violation.

Repeat Tab 20 times. Count how many elements are missing accessible names. On a poorly built page, you will hear "link, link, link" with no differentiation. On a good page, every Tab lands on something that clearly describes itself.

Step 5: Navigate by headings

VoiceOver: VO + Command + H jumps to the next heading. NVDA: just press H.

A well-structured page sounds like a table of contents: h1, h2, h2, h3, h3, h2, h2. A poorly structured page has headings that do not exist (the screen reader never finds any), duplicate headings, or a weird order like h1 → h4 → h2. Heading order is how most screen reader users skim a page. If your headings are broken, your page is unusable.

Step 6: Fill out a form

Find any form on the page (search box, newsletter signup, contact form). Tab into the first field. The screen reader should announce "First name, edit text" or "Email address, required, edit text". If it just says "edit text", the field has no label and you have a WCAG 1.3.1 and 4.1.2 violation.

Now type something invalid (empty field, bad email format) and submit. Did the screen reader announce an error? A lot of forms show errors visually and stay completely silent for screen reader users, which is one of the most common real-world bugs you will find.

Step 7: Click a link and navigate to a new page

Pick any link, press Enter or VO + Space (VoiceOver) / Enter (NVDA). Listen for what happens. A well-built page announces the new page's title immediately. A poorly built page dumps you into the middle of the new page with no context, and the screen reader continues reading from wherever it left off.

That's the whole test. Once you have done this on one page, you will already understand more about your site's real accessibility than most developers ever do.

Essential Commands Cheat Sheet

VoiceOver (macOS)

Action	Command
Toggle VoiceOver on/off	Command + F5
VoiceOver Tutorial	Control + Option + Command + F8
Stop speaking	Control
Read from top	VO + A
Read next item	VO + Right Arrow
Read previous item	VO + Left Arrow
Next heading	VO + Command + H
Next link	VO + Command + L
Next form control	VO + Command + J
Interact with an item	VO + Shift + Down Arrow
Stop interacting	VO + Shift + Up Arrow
Open Rotor (list of headings/links/etc)	VO + U
Click current item	VO + Space

VO = Control + Option.

NVDA (Windows)

Action	Command
Start NVDA	Ctrl + Alt + N
Stop NVDA	NVDA + Q
Stop speaking	Ctrl
Read from top	NVDA + Down Arrow
Read next line	Down Arrow
Next heading	H
Heading level 1, 2, 3, etc	1, 2, 3
Next link	K
Previous link	Shift + K
Next form field	F
Next button	B
Elements list (all links, headings, etc)	NVDA + F7
Read current line	NVDA + Up Arrow

NVDA = CapsLock or Insert, depending on your setup.

Navigation Keys Both Screen Readers Share

These browser-level shortcuts work the same in both:

Key	What It Does
Tab	Next focusable element
Shift + Tab	Previous focusable element
Enter	Activate link or button
Space	Click button, toggle checkbox
Arrow keys	Move within text or menus
Escape	Close modal, menu, or dropdown

What to Listen For: The Top 10 Things to Check

Here is what experienced accessibility testers listen for on every page. You do not need to memorize this; bookmark the list and use it as a checklist.

1. Page title. Does the screen reader announce a meaningful h1 at the top of the page? If the first heading you hear is a sidebar or a card title, the page has no real h1.

2. Skip links. Does pressing Tab as soon as the page loads land on a "Skip to main content" link? Without a skip link, screen reader users Tab through the entire nav every time they load a page.

3. Link text. Does every link make sense out of context? A link that says "click here" or "learn more" tells the user nothing.

4. Image alt text. Does every meaningful image announce a useful description? You can also pre-fix this by running a PageAudit scan and using the alt text best practices guide to fix the violations automatically.

5. Form labels. Does every input field announce what it is? "Edit text" with no label is always a bug.

6. Error messages. When you submit an invalid form, does the screen reader announce the error? Errors that only appear visually are invisible to screen reader users.

7. Required fields. Does the screen reader say "required" for fields that are required? If the asterisk is only visual, screen reader users do not know which fields are required.

8. Focus visibility. After clicking a button that opens a modal or panel, where does focus go? Silence after a click usually means focus is trapped or lost.

9. Dynamic content. When content appears or updates after a click (search results, filter results, tab panels), does the screen reader announce the change? Most sites stay silent.

10. Heading structure. Can you navigate the whole page by pressing H (NVDA) or VO + Command + H (VoiceOver) and get a clear sense of the page's outline? If the heading list is empty or nonsensical, the page has no structure.

Common Beginner Mistakes

These are the mistakes almost every developer makes in their first week of screen reader testing. Watch for them.

Mistake 1: Looking at the Screen

Covered above, but worth repeating. If your eyes are on the page, you are not testing the screen reader experience. Turn the monitor off, close your eyes, or cover the screen.

Mistake 2: Using a Mouse

Screen reader users navigate with the keyboard. If you click links with a mouse while testing, you are bypassing the exact thing you are supposed to test. Put your mouse aside and use only Tab, Shift + Tab, Enter, Space, and arrow keys.

Mistake 3: Testing Only the Happy Path

Tab through a working form and everything sounds fine. Submit an invalid form and the screen reader says nothing. You only find the real bugs by testing error states: empty forms, invalid inputs, expired sessions, failed network requests. These are where screen reader users get stuck.

Mistake 4: Speed-Running the Page

Screen readers are slower than reading with your eyes. That is the point. Your users cannot scan a page in half a second the way you can. If you blast through the page to "test it quickly", you will miss bugs that appear in the slow reading order.

Let the screen reader read each section at its normal pace. If something takes 45 seconds to read that a sighted user would consume in 5 seconds, that is a finding: your content is too verbose for audio.

Mistake 5: Assuming One Browser Represents All

VoiceOver works differently in Safari vs Chrome. NVDA works differently in Firefox vs Chrome vs Edge. A page that reads perfectly in Safari + VoiceOver may fall apart in Chrome + NVDA. For serious testing, cover at least two screen reader + browser combinations (VoiceOver + Safari on Mac, NVDA + Firefox on Windows is a common baseline).

Mistake 6: Skipping the Automated Scan First

Manual screen reader testing is labor-intensive. If you start there, you will spend an hour finding missing alt text and unlabeled buttons that an automated scan would have caught in 30 seconds. Always run a free PageAudit scan first to fix the structural violations, then use screen reader testing to catch the issues automation cannot.

How This Fits with Automated Scanning

Here is the two-pass accessibility workflow most experienced teams use:

Pass 1: Automated scanning. Run PageAudit or the PageAudit Chrome extension on every important page. Fix everything the scan flags. This catches 30-57% of WCAG violations in minutes and eliminates all the structural bugs (missing alt text, bad contrast, unlabeled inputs, heading order, etc) that would otherwise waste your manual testing time.

Pass 2: Manual screen reader testing. Walk through the same pages with VoiceOver or NVDA. Focus on the things automation cannot detect: announcement order, error message visibility, dynamic content changes, focus management, and whether the page actually makes sense when read aloud.

You will find roughly a 70/30 split: 70% of your issues come out of the automated pass and take minutes to fix. The remaining 30% come out of screen reader testing and take longer because they involve interaction design, not just markup. Both passes are necessary. Neither alone is sufficient.

What's Next

Once you can run a basic screen reader test, the next steps are:

• Fix what you found. Automated issues first (PageAudit makes this list for you), then screen reader issues. For alt text specifically, use the alt text best practices guide to handle the most common image issues.
• Test a second screen reader. If you started with VoiceOver, try NVDA on Windows. If you started with NVDA, borrow a Mac for an hour and try VoiceOver. The two behave differently enough that you will find new bugs each time.
• Work the seven most common WCAG errors. Most of these show up in screen reader testing too. Fixing them proactively is cheaper than finding them one page at a time.
• Set up recurring scans. A site that passed last month can regress this month. Automated scans on every deploy are the cheapest way to catch regressions before users do.

Manual screen reader testing is a skill that compounds. The first test takes 15 minutes and feels awkward. The hundredth test takes 3 minutes and feels natural. By that point, you will be catching accessibility bugs that would have shipped to users and earned you a lawsuit.

If you want to skip the manual labor for the issues a scanner can catch, run a free scan at PageAuditors or install the PageAudit Chrome extension. It takes under a minute, works on any page, and flags every WCAG 2.1 AA and 2.2 violation with the exact element location and a fix suggestion. Then come back here, turn your monitor off, and test the rest by ear.