How to test website with screen reader starts with understanding that screen readers navigate differently than visual browsers. You'll use keyboard commands instead of mouse clicks and rely entirely on audio feedback. This guide will teach you to set up screen readers, run systematic tests, and identify accessibility issues that affect millions of users.
After reading this guide, you'll confidently test any website with screen readers, document issues systematically, and integrate accessibility testing into your development workflow.
Why Screen Reader Testing Matters for Developers
Screen reader testing reveals how assistive technology users experience your website. Screen readers are software programs that convert digital text and interface elements into synthesized speech or braille output.
Visual testing misses critical accessibility barriers. A button might look perfect but remain completely unusable to screen reader users if it lacks proper labeling.
Testing with actual assistive technology provides authentic user experience insights. You'll discover navigation patterns, content structure issues, and interaction problems that automated tools can't detect.
Screen Reader Options and Setup
NVDA for Windows
NVDA is a free screen reader available for download for Windows that reads aloud page content and relevant semantic info such as headings, lists, and links, according to Digital Accessibility Services at Harvard University.
Download NVDA from the official website and install with default settings. The installation includes comprehensive documentation and keyboard shortcuts reference.
Launch NVDA before opening your browser. The screen reader will announce when it's active and ready for testing.
Built-in Screen Readers
VoiceOver comes pre-installed on Mac computers and iOS devices. Press Command + F5 to activate VoiceOver on Mac systems.
Narrator is Windows' built-in screen reader. Press Windows key + Ctrl + Enter to launch Narrator on Windows 10 and 11.
TalkBack provides screen reader functionality on Android devices. Enable TalkBack through Settings > Accessibility > TalkBack.
Browser Considerations
Different browsers interact uniquely with screen readers. Test your primary target browsers first, typically Chrome, Firefox, Safari, and Edge.
Firefox often provides the most reliable screen reader experience for testing. Chrome works well with most screen readers but may have timing issues with dynamic content.
How to Test Website with Screen Reader: Step-by-Step Process
Step 1: Prepare Your Testing Environment
Close unnecessary applications to reduce audio distractions. Put on headphones to focus entirely on screen reader output.
Using a screen reader is very different than using a monitor and mouse; while testing with a screen reader, never use a mouse, and rely only on what you can hear, according to the Illinois Department of Innovation & Technology.
Turn off your monitor or look away from the screen during testing. This forces you to experience the website exactly as screen reader users do.
Why this matters: Visual cues can unconsciously influence your testing approach and mask accessibility issues.
Common mistake: Peeking at the screen when confused instead of figuring out the audio-only navigation.
Step 2: Navigate with Keyboard Only
Use Tab key to move between interactive elements. Shift + Tab moves backward through the tab order.
Press Enter to activate buttons and links. Use Space bar to check boxes and activate some buttons.
Arrow keys navigate within menus, radio button groups, and other component sets.
Why this matters: Screen reader users rely entirely on keyboard navigation patterns.
Common mistake: Using mouse clicks when stuck instead of learning proper keyboard commands.
Step 3: Test Heading Structure
Press H key to jump between headings. Numbers 1-6 jump to specific heading levels (H1, H2, etc.).
Listen for logical heading hierarchy. H1 should be the main page title, followed by H2 section headings, then H3 subsections.
Note missing headings or incorrect heading levels. Pages should have exactly one H1 element.
Why this matters: Headings provide the primary navigation structure for screen reader users.
Common mistake: Assuming visual heading styles match semantic heading levels.
Step 4: Check Link and Button Labels
Press K to jump between links. Listen to each link's announced text.
Press B to navigate between buttons. Verify each button clearly describes its action.
Note vague labels like "click here," "read more," or "learn more" without context.
Why this matters: Screen reader users often navigate by link lists, so each link must make sense independently.
Common mistake: Accepting ambiguous link text that only makes sense with visual context.
Step 5: Test Form Controls
Press F to jump between form fields. Listen for clear labels and instructions.
Tab through forms in logical order. Each field should announce its label, type, and current value.
Test error messages by submitting incomplete forms. Error announcements should be clear and actionable.
Why this matters: Forms are critical interaction points that must work flawlessly for screen reader users.
Common mistake: Relying on placeholder text instead of proper labels.
Step 6: Verify Dynamic Content
Trigger content updates like dropdown menus, modal dialogs, or live regions. Listen for appropriate announcements.
Test loading states and progress indicators. Screen readers should announce when content is loading or updating.
Verify focus management when content changes. Focus should move logically to new content.
Why this matters: Dynamic content often breaks screen reader functionality if not properly implemented.
Common mistake: Assuming visual animations communicate status to screen reader users.
Step 7: Check Images and Media
Navigate to images and listen for alternative text descriptions. Decorative images should be ignored by screen readers.
Test video and audio controls. Media players should be fully keyboard accessible.
Verify captions and transcripts are available and properly linked.
Why this matters: Visual content needs text alternatives to be accessible to screen reader users.
Common mistake: Writing alt text that describes visual appearance instead of content meaning.
Step 8: Test Page Landmarks
Press D to jump between landmark regions like main content, navigation, and complementary sections.
Listen for clear landmark labels that distinguish similar regions.
Verify skip links work properly to bypass repetitive navigation.
Why this matters: Landmarks provide efficient page navigation for experienced screen reader users.
Common mistake: Using generic landmark labels that don't help users understand page structure.
What to Listen For: Red Flags and Success Indicators
Success Indicators
Clear announcements describe each element's purpose and current state. Users understand what they can do at each step.
Logical reading order follows the visual layout and content hierarchy. Information flows naturally from one section to the next.
Consistent navigation patterns work the same way across different pages. Users can predict how interactions will behave.
Red Flags
Silent elements that should be announced indicate missing accessibility markup. Interactive elements without labels create confusion.
Repetitive announcements suggest redundant or poorly structured content. Users shouldn't hear the same navigation menu multiple times.
Confusing focus behavior where Tab key jumps unpredictably or focus disappears entirely signals serious accessibility problems.
The most critical red flag is when you feel lost or confused during testing. If you can't figure out how to complete a task, neither can your users.
Troubleshooting Common Issues
Screen Reader Not Announcing Content
Restart the screen reader software and refresh your browser. Some combinations require specific loading order.
Check if content is hidden with CSS display: none or visibility: hidden. Screen readers ignore visually hidden content.
Verify semantic HTML elements are used correctly. Div and span elements need additional ARIA markup to be announced.
Navigation Seems Broken
Confirm you're using correct keyboard shortcuts for your specific screen reader. Commands vary between NVDA, JAWS, and VoiceOver.
Check if focus is trapped in a modal dialog or dropdown menu. Press Escape to close overlays.
Verify JavaScript isn't interfering with keyboard navigation. Disable JavaScript temporarily to isolate issues.
Content Updates Not Announced
Look for ARIA live regions around dynamic content. Status messages need proper markup to be announced.
Check timing of content changes. Very rapid updates may be missed by screen readers.
Test with different screen readers. Some handle dynamic content better than others.
Testing Checklist and Documentation
Essential Testing Points
- Page structure: Logical heading hierarchy with single H1
- Navigation: All interactive elements reachable by keyboard
- Links: Descriptive link text that makes sense out of context
- Forms: Clear labels, instructions, and error messages
- Images: Appropriate alternative text or marked as decorative
- Dynamic content: Proper announcements for status changes
- Focus management: Visible focus indicator and logical tab order
Documentation Format
Record each issue with specific location, expected behavior, and actual behavior. Include steps to reproduce the problem.
Note which screen reader and browser combination revealed each issue. Some problems only appear with specific combinations.
Prioritize issues by severity. Critical issues prevent task completion, while minor issues cause confusion or inefficiency.
Issue Categories
- Critical: Cannot complete essential tasks
- Major: Significant confusion or extra effort required
- Minor: Slight inconvenience but workarounds exist
- Enhancement: Improvements that would help usability
Advanced Testing Scenarios
Complex Interactive Components
Test custom dropdown menus, date pickers, and autocomplete fields. These components often require extensive ARIA markup.
Verify carousel and slider controls work with keyboard navigation. Users should be able to pause, navigate, and control playback.
Check data tables with sorting and filtering. Column headers should be properly associated with data cells.
Single Page Applications
Test route changes and navigation updates. Screen readers should announce page changes clearly.
Verify loading states during asynchronous content updates. Users need feedback about what's happening.
Check that browser back button works correctly with screen readers.
Mobile Testing Considerations
Test with mobile screen readers like VoiceOver on iOS and TalkBack on Android. Touch navigation patterns differ from desktop.
Verify swipe gestures work correctly for navigation. Mobile users rely heavily on gesture-based interaction.
Check that responsive design changes don't break screen reader functionality.
Integration with Development Workflow
Automated Testing Foundation
Use automated accessibility testing tools as a first pass. Tools like axe-core catch obvious markup issues quickly.
Set up continuous integration checks for accessibility violations. Automated tests prevent regression of known issues.
Remember that automated tools only catch about 30% of accessibility issues. Manual screen reader testing remains essential.
Regular Testing Schedule
Weekly testing: Test new features and components during development.
Sprint reviews: Include accessibility testing in definition of done.
Release testing: Full screen reader audit before major releases.
Team Training
Train all developers on basic screen reader usage. Everyone should understand fundamental navigation patterns.
Create shared documentation of common issues and solutions. Build institutional knowledge about accessibility patterns.
Schedule regular team testing sessions. Group testing reveals different perspectives and catches more issues.
Frequently Asked Questions
Question: Which screen reader should I use for testing?
Start with NVDA on Windows or VoiceOver on Mac since they're free and widely used. Test with multiple screen readers for comprehensive coverage, but one thorough test beats multiple shallow tests.
Question: How long should screen reader testing take?
Plan 30-60 minutes for thorough testing of a typical webpage. Complex applications may require several hours. Factor testing time into project estimates from the beginning.
Question: Can I test effectively without being a regular screen reader user?
Yes, but acknowledge your limitations. Focus on obvious usability issues and technical problems rather than subtle user experience preferences. Consider hiring users with disabilities for more nuanced feedback.
Question: What if I find too many issues to fix?
Prioritize critical issues that prevent task completion. Fix major navigation and form problems first. Create a remediation plan that addresses issues systematically over time.
Question: How do I know if my fixes actually work?
Retest with screen readers after making changes. Small markup changes can have significant impacts on screen reader behavior. Always verify fixes don't create new problems.
Question: Should I test with multiple browsers and screen readers?
Yes, but be strategic. Test your primary target combinations first. NVDA with Firefox and Chrome covers most Windows users. VoiceOver with Safari covers Mac users.
Key Takeaways
- Screen reader testing requires keyboard-only navigation and audio-only feedback
- NVDA provides free, comprehensive screen reader testing for Windows users
- Test systematically through headings, links, forms, and dynamic content
- Document issues with specific reproduction steps and severity levels
- Focus on critical usability problems before minor enhancements
- Integrate screen reader testing into regular development workflow
- Multiple screen reader and browser combinations reveal different issues
- Automated tools supplement but cannot replace manual screen reader testing
Start Testing Your Website Today
Screen reader testing transforms how you think about web accessibility. Download NVDA or enable your system's built-in screen reader right now. Pick one page from your current project and work through the eight-step testing process.
Start with your homepage or most critical user flow. Document what you discover and share findings with your team. Get started with comprehensive accessibility testing using our WCAG Conformance Suite to identify issues before they reach your users.