Test with Screen Readers
How to test your site with VoiceOver and NVDA.
What this covers: How to test your site with VoiceOver and NVDA, including voiceover (mac), nvda (windows).
Who it’s for: Site owners and developers who need to meet accessibility standards and avoid legal risk.
Key outcome: You’ll have all page headings form a logical outline (h1 then h2 then h3) with no skipped levels — verify in voiceover rotor, and every image has meaningful alt text (or empty alt=”” for decorative images) read correctly by the screen reader.
Time to read: 6 minutes
Part of: Accessibility series
1 shows you what blind users experience—and you’ve probably never done it.
You want to test accessibility but you’ve never used a screen reader in your life. VoiceOver? NVDA? JAWS? These sound like character names from a sci-fi movie. Here’s how to actually test with them.
Why bother? Because automated accessibility tools catch only significant of issues. The rest require human testing—specifically, testing the way real users experience your site. If you’ve never heard your site read aloud, you don’t know how broken it sounds. Ten minutes with VoiceOver will teach you more than any accessibility audit report.
VoiceOver (Mac)
Built into every Mac. Free. No installation.
Start Testing
- Press Cmd + F5 to turn on VoiceOver
- Open Safari (VoiceOver works best with Safari)
- Navigate to your site
- Use VO + Right Arrow to move through elements (VO = Control + Option)
necessary Commands
- VO + Right/Left: Move through page elements
- VO + Space: Click/activate current element
- VO + U: Open the rotor (navigate by headings, links, forms)
- Cmd + F5: Turn VoiceOver off
NVDA (Windows)
Free, open-source, used by many blind users. Download NVDA.
Start Testing
- Install NVDA (takes 2 minutes)
- Press Ctrl + Alt + N to start
- Open Chrome or Firefox
- Press Tab or Down Arrow to navigate
necessary Commands
- Down/Up Arrow: Move through content
- Tab: Move between interactive elements
- H: Jump to next heading
- Insert + F7: List all links
- Insert + Q: Quit NVDA
What to Test
Navigate your site and check:
- Can you understand where you are on the page? ?
- Do buttons and links describe their purpose? ?
- Can you complete key tasks (signup, checkout, contact)? ?
- Do forms announce errors ? ?
- Is the reading order logical? ?
Common Problems You’ll Find
1. “Button” with No Name
Icon-only buttons without aria-label. Fix: Add aria-label="Search".
2. “Link Link Link”
Multiple “Click here” or “Read more” links. Fix: Use descriptive link text.
3. Skipped Heading Levels
Jumping from H1 to H4. Screen reader users navigate by headings. Fix: Use sequential heading levels.
4. Images with No Alt Text
You hear nothing, or the filename. Fix: Add descriptive alt text, or alt=”” for decorative images.
The 5-Minute Test
- Turn on screen reader
- Close your eyes (seriously)
- Try to find and click your main CTA
- Try to complete your signup form
- Note everything that confused you
If you got lost, so will your users.
JAWS (Windows, Paid)
JAWS is the most widely used screen reader among blind professionals. It costs $95/year, but if your audience includes enterprise or government users, JAWS compatibility matters. It behaves differently from NVDA in how it handles forms, tables, and ARIA live regions. A site that works in NVDA can still break in JAWS. If budget allows, test critical flows in JAWS at least once per quarter.
Targeted Testing Scenarios
Forms
Navigate to a form using Tab. Each field should announce its label, whether it is required, and its current value. Submit the form with intentional errors. The screen reader must announce the error messages—if it stays silent after a failed submission, your error handling is invisible to blind users. Test date pickers, dropdowns, and multi-step forms separately; these are where most failures hide.
Navigation Menus
Tab to your main navigation. Dropdown menus must announce their expanded or collapsed state. Arrow keys should move between menu items. If a submenu opens on hover only, keyboard users cannot reach those links at all. Test the mobile menu too—hamburger menus often lack aria-expanded and trap focus incorrectly.
Dynamic Content
Add an item to a cart, submit a form, or trigger a notification. If the screen reader says nothing, your dynamic updates are invisible. Use aria-live="polite" on containers that update without a page reload. Test toast notifications, loading spinners, and inline validation messages—all should be announced when they appear.
The Screen Reader Test Checklist
- You’ve tested key flows with VoiceOver or NVDA
- All content is announced in logical order
- Images have descriptive alt text
- Dynamic content changes are announced
Sources
Screen Reader Testing Questions Answered
Which screen reader should I test with?
Test with VoiceOver on Mac (built-in, Cmd+F5) and NVDA on Windows (free download). These cover the two most-used screen readers. For mobile, test with VoiceOver on iOS and TalkBack on Android. Testing with one desktop and one mobile reader catches most issues.
Do I need to be a screen reader expert to test my site?
No. Learn four commands: navigate by headings (VO+Cmd+H on Mac), navigate by links, read the current element, and activate a link/button. Spend 30 minutes learning these basics, then navigate your own site as a screen reader user. Most critical issues become immediately obvious.
What are the most common screen reader issues on websites?
Missing alt text on images, unlabeled form inputs, headings that skip levels (H1 to H3), links that all say “click here” or “read more,” and custom widgets (modals, dropdowns, tabs) that are invisible to screen readers because they lack ARIA roles.
How often should I test with a screen reader?
Test key pages after every major design change or feature addition. Run a full-site screen reader audit quarterly. Include screen reader testing in your QA process for new pages and templates. Automated tools catch only 30-40% of accessibility issues; manual screen reader testing catches the rest.
✓ Your Screen Reader Testing Is Complete When
- All page headings form a logical outline (H1 then H2 then H3) with no skipped levels — verify in VoiceOver rotor
- Every image has meaningful alt text (or empty alt=”” for decorative images) read correctly by the screen reader
- Form fields announce their label, required state, and error messages when focused
- Navigation menus read in correct order and announce expanded/collapsed state for dropdowns
- You’ve tested with at least two screen readers (e.g., VoiceOver on Mac + NVDA on Windows)
Test it: Turn on VoiceOver (Cmd+F5 on Mac), close your eyes, and complete your site’s core user journey — if you can navigate, read content, and submit a form, your screen reader support works.