Screen Reader Testing for Developers: A Practical Getting Started Guide

Automated accessibility scanners are indispensable. They catch missing alt text, broken ARIA attributes, insufficient color contrast, and dozens of other WCAG violations in seconds. But automated tools can only detect roughly 30-40% of WCAG 2.1 success criteria. The remaining 60-70% requires manual testing, and the single most important manual test you can run is navigating your site with a screen reader.

Screen reader testing reveals problems that no automated scanner can catch. It tells you whether your page actually makes sense when read aloud in sequence, whether interactive components announce their state correctly, and whether a blind user can complete a checkout flow or fill out a contact form. These are the issues that determine whether a website is genuinely usable or merely passes a scan report.

If you are a developer at a web agency and you have never tested with a screen reader before, this guide will get you from zero to productive. You will set up a free screen reader, learn the core keyboard commands, follow a repeatable testing workflow, and know how to document what you find. By the end, you will have a manual testing skill that directly complements your automated scans and dramatically improves the quality of the accessibility work you deliver to clients.

Why Screen Reader Testing Matters Even with Automated Scanners

Automated scanners are excellent at structural analysis. They parse your HTML, evaluate your CSS, and check whether specific attributes exist and contain valid values. What they cannot do is understand context, intent, or user experience.

Reading order versus visual order

CSS Grid and Flexbox make it trivial to reorder elements visually without changing the DOM order. A sighted user sees a logical layout. A screen reader user hears content in DOM order, which may be completely incoherent. No automated tool checks whether reading order makes semantic sense.

Meaningful link and button text

An automated scanner can verify that a link has accessible text. It cannot tell you whether that text is useful. A page with twenty links all labeled "Read more" passes every automated check. A screen reader user pulling up the links list hears "Read more, Read more, Read more" with no way to distinguish between them.

Dynamic content and live regions

When a form submission fails and an error message appears, does the screen reader announce it? ARIA live regions control this behavior, and whether they actually work depends on the screen reader, the browser, the timing of the DOM update, and the politeness setting. Automated scanners can check whether aria-live is present in your markup. They cannot verify that the announcement actually fires at the right moment.

Custom component state

If you build a custom dropdown, accordion, or modal, automated tools can check that certain ARIA attributes exist. They cannot tell you whether the screen reader announces "expanded" when you open a dropdown and "collapsed" when you close it. They cannot tell you whether focus moves into a modal when it opens and returns to the trigger when it closes. These interaction patterns require a human operating a screen reader to verify.

Form labeling in context

A form field can have a valid <label> element and still be confusing to a screen reader user. If your label says "Name" but there are three fields on the page labeled "Name" (one for the user, one for a billing contact, one for a shipping contact), the screen reader user has no way to know which "Name" they are currently editing without surrounding context that may not be programmatically associated.

The takeaway is straightforward: automated scanners and screen reader testing are complementary. Automated tools give you speed and coverage. Screen reader testing gives you accuracy and confidence. You need both. If you have not yet run an automated scan, start there. A11yScope's free scanner will give you a baseline report in minutes. Then use this guide to go deeper.

Setting Up Your Screen Reader

You do not need to buy anything. The two screen readers you should learn are both free, and you almost certainly already have one of them on your machine.

NVDA on Windows

NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows. It is the standard tool for developer testing because it costs nothing and receives regular updates.

Installation:

Download NVDA from the official site at nvaccess.org.
Run the installer. It takes under a minute.
NVDA starts automatically after installation. You will hear a voice begin speaking immediately.
Launch NVDA at any time from the Start menu or by pressing Ctrl + Alt + N.

Essential configuration:

Set your modifier key. NVDA uses a modifier key (called the "NVDA key") for most commands. By default, this is the Insert key. On laptops without an Insert key, you can configure NVDA to use Caps Lock as the modifier instead. Open NVDA preferences with NVDA + N, then navigate to Preferences, Settings, Keyboard, and check "Use Caps Lock as an NVDA modifier key."
Choose a speech synthesizer. NVDA ships with the eSpeak NG synthesizer, which works well for testing. If you find it difficult to understand, you can switch to Windows OneCore voices in the Synthesizer settings.
Turn on focus highlighting. In Preferences, Settings, Vision, enable "Focus Highlight" so you can see which element NVDA is currently focused on. This is extremely helpful when you are learning.

Core NVDA keyboard commands:

NVDA + Space — Toggle between browse mode (read content) and focus mode (interact with controls).
Tab / Shift + Tab — Move to the next or previous focusable element.
Up Arrow / Down Arrow — In browse mode, read the previous or next line.
H / Shift + H — Jump to the next or previous heading.
D / Shift + D — Jump to the next or previous landmark region.
K — Jump to the next link.
F — Jump to the next form field.
T — Jump to the next table.
Enter — Activate a link or button.
Space — Activate a button or toggle a control.
NVDA + F7 — Open the Elements List (links, headings, form fields, buttons, or landmarks on the page).
Ctrl — Stop speech immediately.
NVDA + Q — Quit NVDA.

Testing browser: Use NVDA with Firefox for best compatibility. Chrome also works well for most scenarios.

VoiceOver on macOS

VoiceOver is Apple's built-in screen reader, already installed on every Mac.

Launching VoiceOver:

Press Cmd + F5 to toggle VoiceOver on and off.

The VoiceOver modifier key:

VoiceOver commands use a modifier called the "VO key," which is Ctrl + Option pressed together. In this guide, VO is shorthand for Ctrl + Option.

Core VoiceOver keyboard commands:

VO + Right Arrow / VO + Left Arrow — Move to the next or previous element.
VO + Space — Activate the current element.
Tab / Shift + Tab — Move to the next or previous focusable element.
VO + U — Open the Rotor (VoiceOver's equivalent of NVDA's Elements List). Use Left/Right arrows to switch categories, Up/Down to navigate within a category.
VO + Cmd + H / VO + Cmd + Shift + H — Jump to the next or previous heading.
VO + Cmd + L — Jump to the next link.
VO + Cmd + J — Jump to the next form control.
VO + Cmd + T — Jump to the next table.
Ctrl — Stop speech immediately.
VO + A — Start reading from the current position.
Cmd + F5 — Turn off VoiceOver.

Testing browser: Use VoiceOver with Safari. Apple develops VoiceOver and Safari together, and the combination has the best ARIA support on macOS.

Which screen reader should you use?

Test with the screen reader that matches your operating system. If you are on Windows, use NVDA with Firefox. If you are on macOS, use VoiceOver with Safari. For agency work where cross-platform coverage matters, test with both.

The Screen Reader Testing Workflow

Turning on a screen reader and randomly navigating is not testing. Use the following structured workflow for every page you test.

Step 1: Test the page title

When you load a page, the screen reader announces the <title> element. Verify that the title is descriptive and unique. "Home - CompanyName" is fine. "Untitled" or a duplicated title across pages is a failure.

Step 2: Navigate by landmarks

Use landmark navigation (D in NVDA, or the Rotor landmarks category in VoiceOver) to move through the page's landmark regions. A well-structured page should have:

banner — The site header (<header> as a direct child of <body>).
navigation — The primary navigation (<nav>). Multiple nav elements should each have a unique aria-label.
main — The main content area (<main>). There should be exactly one.
contentinfo — The site footer (<footer> as a direct child of <body>).

Missing landmarks or multiple navigation landmarks with no distinguishing labels are findings to document.

Step 3: Navigate by headings

Use heading navigation (H in NVDA, VO + Cmd + H in VoiceOver) to move through the hierarchy. Open the headings list (NVDA + F7 then select Headings, or VO + U then arrow to Headings) to see the full outline. Check for:

Exactly one <h1> that describes the page content.
No skipped levels in the heading hierarchy (e.g., <h2> jumping to <h4>).
Descriptive heading text. "Shipping Options" is useful. "Section" is not.
Content sections without headings that screen reader users cannot jump to.

Step 4: Test interactive elements with the keyboard

Press Tab to move through every interactive element. For each one, check:

Is it reachable with Tab? Unreachable elements are completely inaccessible.
Does it have a descriptive accessible name? "Submit order" is good. "Button" alone is a failure.
Is the focus order logical? Watch for focus jumping past main content.
Is the focus indicator visible? If you cannot tell which element is focused, sighted keyboard users cannot either.
Does the role match the behavior? Something that looks like a button should be announced as a button, not a link.

Step 5: Test forms

Forms are where screen reader testing delivers the most value. For each form:

Are all fields labeled? The screen reader should announce a descriptive label for each input.
Are required fields announced as required? The required attribute or aria-required="true" handles this.
Do error messages get announced? Submit invalid data and listen. If errors appear visually but the screen reader stays silent, you have a live region problem.
Is error association correct? Error messages should be linked to fields using aria-describedby.
Do grouped fields have group labels? Radio buttons should be in a <fieldset> with a <legend>.
Do custom controls work? Test that custom dropdowns, date pickers, and other custom components can be operated and announce their state correctly.

Step 6: Test dynamic content

Interact with every component that changes the page without a full reload:

Modals: Does focus move into the modal? Can you Tab without focus escaping behind it? Does focus return to the trigger when it closes?
Accordions: Does the screen reader announce "expanded" and "collapsed"?
Tab panels: Can you navigate between tabs with arrow keys?
Notifications and alerts: Does the screen reader announce toast messages without the user navigating to find them? This requires aria-live or role="alert".

Step 7: Test images and media

Informative images should have meaningful alt text describing content or purpose.
Decorative images with alt="" should not be announced at all.
Videos should have captions available.
Audio players should have keyboard-accessible, labeled controls.

Common Problems You Will Discover

After testing dozens of sites, you will notice the same issues repeatedly. Knowing what to expect makes testing faster.

Meaningless link text

Links that say "click here," "read more," or "learn more" are meaningless out of context. Screen reader users navigate by pulling up a list of all links (NVDA + F7 or the VoiceOver Rotor). Twenty links labeled "Read more" make the page unusable for link-based navigation.

The fix: Make every link's text describe its destination. If changing the visible text is not possible, use aria-label or a visually-hidden text pattern.

Missing or broken live regions

When dynamic content appears (form errors, cart updates, notifications), screen reader users will not know it exists without ARIA live regions. Common failures:

No live region at all. Content appears visually but the screen reader says nothing.
Live region added dynamically. The aria-live container must exist in the DOM before the content changes, or some screen readers miss the announcement.
Wrong politeness setting. aria-live="assertive" or role="alert" interrupts immediately (use for errors). aria-live="polite" waits for the current announcement to finish (use for status updates).

Broken tab order

CSS layout changes and absolute positioning frequently cause the tab order to diverge from visual order. Focus jumps to unexpected locations, which is disorienting for all keyboard users.

The fix: Never use positive tabindex values (like tabindex="2"). Ensure DOM order matches visual order. If you use CSS Grid or Flexbox order properties, verify that the resulting tab order still makes sense.

Unlabeled form controls

Automated scanners catch inputs with no <label>, but they miss labels that are technically present but misleading: identical labels for different fields, placeholder text as the only label, or icon buttons with no aria-label announced simply as "button."

Focus management failures

When a modal dialog opens, keyboard focus must move into the modal. When the modal closes, focus must return to the triggering element. In single-page applications, when a route change occurs, focus should move to the new page's main content or heading so the screen reader user knows the page has changed. These focus management patterns are almost never handled correctly without deliberate implementation, and they are impossible for automated scanners to verify.

Tables without proper headers

Data tables need <th> elements for column and row headers, and complex tables need scope attributes or headers/id associations. Without these, a screen reader user hearing "John, 42, New York" has no idea that "John" is a name, "42" is an age, and "New York" is a city. The screen reader simply reads the cell contents in sequence with no context.

Recording and Documenting Screen Reader Findings

Screen reader testing is only useful if you document findings in a way that other developers can act on.

What to record for each issue

Page URL where the issue occurs.
Issue description. "The 'Add to cart' button is announced as 'button' with no accessible name" is actionable. "Button is broken" is not.
Steps to reproduce. Exact navigation steps to encounter the issue.
Screen reader and browser. Always note the combination, e.g., "NVDA 2025.1, Firefox 135."
WCAG success criterion. Reference the specific criterion violated (e.g., 4.1.2 for unlabeled controls).
Severity. Critical (blocks a task), serious (very difficult), moderate (confusing but completable), or minor (best practice).
Recommended fix. A specific code-level suggestion.

Documentation tools

Screen recording with audio captures the screen reader output. Use OBS, the macOS recorder (Cmd + Shift + 5), or the Windows Snipping Tool recorder.
Browser DevTools Accessibility Inspector shows computed accessible names and roles, supplementing what you hear.
Issue templates in a spreadsheet or tracker ensure consistency across your team.

Prioritizing findings

Critical: Users cannot complete a primary task. Fix immediately.
Serious: Task completion with significant difficulty. Fix this sprint.
Moderate: Suboptimal but functional. Schedule for next sprint.
Minor: Best-practice improvements. Add to backlog.

For a deeper look at systematic auditing that combines automated and manual findings, see our website accessibility audit guide.

Combining Automated and Manual Testing for Full Coverage

The most effective workflow uses automated scanning as the foundation and screen reader testing as the verification layer.

Start with an automated scan

Run your site through an automated scanner first. This catches missing alt text, empty links, form label issues, color contrast failures, and invalid ARIA attributes. Fix these before manual testing. There is no point in firing up a screen reader to find issues a scanner catches in milliseconds.

If you are not already running automated scans, A11yScope's free scanner will analyze your pages against WCAG 2.1 and give you a prioritized violation list. Address automated findings first, then move to the manual testing workflow in this guide.

Layer in screen reader testing

Once your scan results are clean, begin the screen reader workflow. Focus on areas where automation is blind: reading order, link text quality in context, form interaction flows, dynamic content announcements, focus management, and custom component interaction patterns.

Retest after fixes

After developers implement fixes, retest with the screen reader. A scanner can verify that an aria-label was added, but only a screen reader test confirms the announcement sounds correct in context.

Make it part of your process

During development: Test new components with a screen reader before merging. It takes five minutes.
During QA: Include screen reader checkpoints in your QA checklist.
During client handoffs: Include screen reader testing notes in your accessibility documentation.
Ongoing monitoring: A11yScope's Pro plan provides continuous automated monitoring that alerts you when new issues appear, so you know when to run manual verification again.

For a practical guide on fixing automated scanner findings before beginning manual testing, see our article on how to fix accessibility issues found by automated scanners.

Getting Started Today

You do not need to become a screen reader expert overnight. Start with these steps:

Install NVDA or turn on VoiceOver. Spend ten minutes navigating a website you know well. Get comfortable with Tab, arrow keys, heading jumps, and the elements list or Rotor.
Test one page on a current project. Follow the seven-step workflow in this guide. Document every issue you find.
Fix the critical issues. Then retest to confirm the fixes work.
Run an automated scan. Use A11yScope's free scanner to catch everything the screen reader testing did not cover, and compare the two sets of results.
Make it routine. Add screen reader testing to your definition of done for new components and features. Five minutes of testing during development saves hours of remediation after launch.

Screen reader testing is a skill that improves with practice. The first time you use a screen reader, it will feel slow and unfamiliar. By your tenth session, you will be navigating pages fluently and spotting issues instantly. The developers who invest in learning this skill deliver genuinely accessible websites, not just websites that pass an automated scan.

The combination of automated scanning for breadth and screen reader testing for depth is what separates adequate accessibility work from excellent accessibility work. Start with automation, layer in manual testing, and you will be delivering a level of quality that most agencies never reach.