How to Test Your Website with a Screen Reader
You can't really know if your site is accessible until you hear it through a screen reader. Automated scanners, including ours, catch maybe 30-40% of issues. But does your content actually make sense read aloud? Do your widgets announce themselves properly? You won't know until you listen. Here's how I test, and how you can start today.
In This Article
Why Manual Testing Matters
Don't get me wrong. I love automated tools (I built one). They're great at catching the mechanical stuff: missing alt text, bad color contrast, missing form labels, broken ARIA. But here's what no scanner can tell you:
- Alt text actually describes the image meaningfully
- Heading structure communicates the page hierarchy correctly
- Dynamic content (modals, accordions, live updates) is announced properly
- Custom widgets are operable and understandable
- The reading order makes logical sense
- Focus management in single-page apps works correctly
That's exactly what screen reader testing is for. And here's the thing: you don't need to become an expert. Even 15 minutes on a single page will reveal problems that no automated tool would ever catch.
Choosing a Screen Reader
Don't overthink this. You don't need to test with every screen reader out there. Just start with the one that's already on your computer:
| Screen Reader | Platform | Cost | Best For |
|---|---|---|---|
| VoiceOver | macOS, iOS | Free (built-in) | Mac/iPhone users, Safari testing |
| NVDA | Windows | Free (download) | Most popular free option, Firefox/Chrome testing |
| JAWS | Windows | Paid ($90/yr+) | Enterprise standard, most feature-rich |
| Narrator | Windows | Free (built-in) | Quick testing, Edge browser |
| TalkBack | Android | Free (built-in) | Mobile Android testing |
Recommendation
On a Mac? Start with VoiceOver. It's already there, no install needed. On Windows, grab NVDA (it's free and open-source). Between those two, you're covering how most real screen reader users actually browse the web.
Getting Started with VoiceOver (Mac)
Turning It On
Press Cmd + F5 and VoiceOver kicks in. You'll immediately hear a voice start reading things. Don't panic! Just press the same shortcut to turn it off whenever you want.
Essential Commands
VoiceOver uses "VO keys" (Control + Option) as a modifier. Here are the only commands you need to get started:
| Action | Keys |
|---|---|
| Move to next element | VO + Right Arrow |
| Move to previous element | VO + Left Arrow |
| Activate (click) element | VO + Space |
| Read from current position | VO + A |
| Open Rotor (navigate by type) | VO + U |
| Next heading | VO + Cmd + H |
| Stop speaking | Control |
The Rotor (VO + U) is my favorite feature. It pulls up lists of headings, links, form controls, and landmarks so you can jump to any element type instantly. Once you try it, you'll wonder how you tested without it.
Getting Started with NVDA (Windows)
Installation
Head over to nvaccess.org and download NVDA for free. Install, launch, and you're good to go. It uses the Insert key as its modifier (called the "NVDA key").
Essential Commands
| Action | Keys |
|---|---|
| Toggle browse/focus mode | NVDA + Space |
| Read next line | Down Arrow |
| Read previous line | Up Arrow |
| Next heading | H |
| Next link | K |
| Next form field | F |
| Next landmark | D |
| Elements list (like Rotor) | NVDA + F7 |
| Stop speaking | Control |
Browse Mode vs. Focus Mode
This trips people up at first. Browse mode lets you read the page and navigate by headings, links, etc. Focus mode passes your keystrokes directly to form controls. NVDA switches automatically when you enter a form field, but if things feel weird, try toggling with NVDA + Space.
What to Test For
Don't try to test everything at once. You'll get overwhelmed. Instead, focus on these high-impact areas that I always check first:
1. Page Load Announcement
When the page loads, the screen reader should announce the page title. If you hear "Untitled" or something generic, that's your <title> element, and it needs fixing right away.
2. Heading Navigation
Use heading navigation (H key in NVDA, VO + Cmd + H in VoiceOver) to jump through headings. Ask yourself:
- Is there an H1 that describes the page?
- Do headings form a logical outline?
- Can you understand the page structure from headings alone?
3. Images
Navigate to your images and just listen. Decorative images should be silent (empty alt). But meaningful images? They should describe what a sighted user would see. If you hear "image" with no description, that's a problem. Check out the alt text guide for how to write good descriptions.
4. Links
Pull up the links list (NVDA + F7, or Rotor) and read through it. Can you tell where each link goes from its text alone? If you see a bunch of "Click here" and "Read more" entries, that's a big red flag.
5. Forms
Tab through every form. Each field should announce its label when focused. Required fields should be indicated. Error messages should be announced. See our accessible forms guide.
6. Dynamic Content
This is the big one. Test anything that changes without a full page reload: modals, accordions, tabs, live updates, add-to-cart confirmations. If the screen reader stays silent when something pops up on screen, your users are missing it entirely.
Most of these components rely on ARIA attributes to communicate state changes. A modal needs role="dialog" and a label. A live update needs aria-live="polite" so the screen reader knows to announce it. If you're not sure how these attributes work, our ARIA labels guide breaks it all down. Getting ARIA right is the difference between a widget that works and one that's completely invisible.
7. Media and Video
If your site has video or audio content, fire up the screen reader and check that media players are fully operable. Can you reach the play button, adjust volume, and toggle captions without a mouse? Are captions actually present? Video players are notorious for trapping keyboard focus, so test that you can tab in and back out cleanly. For a full walkthrough on making media accessible, see our video accessibility guide.
8. Keyboard Traps
While testing with the screen reader, verify you never get stuck. You should always be able to move past any component. See our keyboard accessibility guide.
A Practical Testing Workflow
Here's the workflow I actually use. It combines automated and manual testing so you catch as much as possible without burning out:
Step 1: Automated Scan First
Run a free automated scan first to catch the easy stuff. Fix those issues before you do anything else. There's no point manually testing a page with 50 missing alt texts when a scanner already told you about them.
Step 2: Keyboard-Only Navigation
Put your mouse away and tab through the entire page. Can you reach everything? Can you see where focus is? This is faster than screen reader testing and catches a lot of the same issues. I always do this step before turning on a screen reader.
Step 3: Screen Reader Walkthrough
Turn on your screen reader and go through the page from top to bottom. Listen for:
- Does the page title make sense?
- Is the skip link announced?
- Do headings create a logical outline?
- Are images described appropriately?
- Do forms announce labels and errors?
Step 4: Test Key User Flows
Now, with the screen reader still going, try to actually use your site. Search for something. Fill out a form. Go through a checkout. These are the tests that reveal the real-world problems your users actually hit.
Step 5: Document and Fix
Write down every issue: the page URL, the element, and what went wrong. Then prioritize: anything that blocks a task comes first, confusing announcements next, and minor annoyances last. Trust me, having this list makes fixing things so much easier.
Start Testing Today
Start with a quick automated scan to knock out the easy issues, then follow the screen reader workflow I described above. If you want the full testing protocol, I've got an ADA compliance checklist that covers everything. And to know what you're likely to find, read about the common WCAG 2.2 mistakes I see all the time.