Screen reader testing is one of the clearest ways to find accessibility barriers that automated scanners cannot fully evaluate. A scanner may tell you that a button has an accessible name or that headings exist in the markup. It cannot reliably tell you whether a blind user can understand the page structure, recover from a form error, follow a modal dialog, or complete a checkout flow without becoming disoriented.
This guide explains how website teams can test with three widely used screen readers: NVDA, JAWS, and VoiceOver. It focuses on practical website testing rather than memorizing every screen-reader command. The goal is to understand what to test, which combinations are useful, what common failures sound like, and how screen-reader findings fit into a broader website accessibility audit.
What is screen reader testing?
A screen reader converts information exposed by the operating system, browser, and accessibility APIs into speech or Braille output. On the web, that means users can navigate headings, links, buttons, form fields, tables, landmarks, and other structures without relying on the visual presentation of the page.
Screen reader testing evaluates whether the website exposes useful information in a usable order and whether interactive components behave predictably. It is not simply a test of whether text can be read aloud. A page can technically “read” and still be difficult or impossible to use.
Good testing asks questions such as:
- Can a user understand what page they are on and how it is structured?
- Do headings describe sections accurately?
- Do links and buttons have meaningful names?
- Can forms be completed and corrected after errors?
- Are expanded, selected, invalid, checked, and disabled states announced?
- Does focus move to the right place when dialogs and dynamic content appear?
- Can a user complete the same critical tasks available to a sighted mouse user?
NVDA, JAWS, and VoiceOver: what each one is
Screen readers depend on the structure and accessibility information exposed by the browser.NVDA
NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Microsoft Windows developed by NV Access. Its official documentation describes support for popular browsers and applications and explains how web pages are presented through browse mode, where users can navigate by headings, links, form controls, tables, and other structures.
NVDA is especially useful in accessibility testing because teams can install it without a software licensing cost. A practical Windows baseline is to test important flows with NVDA in a modern browser such as Chrome or Firefox, while keeping in mind that assistive-technology behavior can vary by browser and implementation.
JAWS
JAWS (Job Access With Speech) is a commercial Windows screen reader from Freedom Scientific. Its documentation and training materials cover web navigation by headings, links, form fields, regions, tables, and other HTML structures. Freedom Scientific also documents support for current versions of major Windows browsers.
JAWS matters because it is used in professional, education, government, and enterprise environments. If your product serves a broad or high-risk audience, including JAWS in the testing matrix can reveal differences that are not always visible with a single screen reader.
VoiceOver
VoiceOver is built into macOS and other Apple platforms. On the Mac, VoiceOver provides keyboard-driven navigation, speech output, and support for navigating web content and applications. For website testing, VoiceOver with Safari is a practical Apple-platform baseline.
VoiceOver is also relevant for mobile accessibility testing on iPhone and iPad. Website and app teams should treat desktop and mobile screen-reader behavior as related but separate test environments because touch gestures, focus behavior, and interaction patterns can differ substantially.
Do you need to test with all three screen readers?
A useful test plan defines representative pages, components, screen readers, browsers, and critical journeys.Not every project needs every possible screen-reader and browser combination. Testing should be based on the product, audience, risk, supported platforms, and critical user journeys. A small marketing site may use a narrower representative matrix. A complex SaaS application, e-commerce checkout, public-sector service, or product used by a large customer base may justify broader coverage.
The important mistake to avoid is treating one successful test in one environment as proof that every assistive-technology combination works. Browser accessibility APIs, screen-reader behavior, custom JavaScript components, and ARIA implementations can produce different results across combinations.
A practical approach is to establish a documented baseline, then expand testing where the product or audience requires it. Screen-reader testing should also be combined with keyboard-only testing, zoom and reflow checks, automated analysis, and manual inspection. See our guide to automated vs manual accessibility testing for the broader testing model.
What to test with a screen reader
1. Page title and initial orientation
When the page loads, the user should receive enough information to understand where they are. The document title should be meaningful and unique enough to distinguish the page. Unexpected focus jumps, auto-playing content, intrusive banners, and immediate dialogs can make orientation harder.
2. Heading structure
Screen-reader users often navigate by headings instead of reading every line from the top. Headings should represent the actual structure of the page. A visually large sentence is not automatically a heading, and a heading level should not be selected only because of its visual appearance.
During testing, navigate through the heading list and ask whether it gives a useful outline of the content. Missing headings, repeated generic headings, or incorrectly nested structure can make a long page difficult to understand.
3. Links and buttons
Links and buttons need meaningful accessible names. Repeated links such as “click here,” unlabeled icon buttons, or controls announced only as “button” provide little context. A user navigating a list of links or buttons should be able to understand what each control does without depending entirely on surrounding visual text.
Also verify that the role matches the action. A link is normally used for navigation; a button performs an action. Rebuilding everything with generic elements and JavaScript can create confusing or incomplete semantics.
4. Navigation and landmarks
Landmarks such as navigation, main content, complementary content, and footer regions can help users move efficiently through large pages. They should be used to improve orientation, not added in excessive numbers that create a different kind of clutter.
Skip links and other bypass mechanisms are especially useful when pages contain repeated navigation before the main content.
5. Forms and validation
Forms are one of the most important areas for screen-reader testing. Verify that each field has a meaningful label, required status is communicated, instructions are available before they are needed, and errors are programmatically associated with the relevant fields.
Do not stop after entering valid data. Submit the form with missing or incorrect information. Confirm that the user is told that an error occurred, can identify the affected fields, understands how to correct the problem, and can continue without losing entered data. For a deeper review, see Why Accessible Forms Still Fail.
6. Images and alternative text
Meaningful images should expose useful alternatives, while decorative images should not create unnecessary announcements. Test product images, charts, linked images, logos, icons, and image-based controls in context. The question is not merely whether an alt attribute exists; it is whether the announced information helps the user understand or operate the page.
7. Dynamic content and status messages
Modern websites update content without reloading the page. Search suggestions, shopping-cart updates, validation messages, loading states, saved confirmations, and filtered results may need to be announced when they change.
If a sighted user sees “Item added to cart” but a screen-reader user receives no equivalent feedback, the task may become uncertain even though the action technically succeeded.
8. Dialogs, menus, tabs, and custom widgets
Custom components are a frequent source of screen-reader failures. When a dialog opens, focus should move into it appropriately, the dialog should have an accessible name, background content should not create confusing navigation, and focus should return sensibly when the dialog closes.
Menus, tabs, comboboxes, accordions, date pickers, sliders, and autocomplete controls need predictable names, roles, states, and keyboard behavior. Incorrect ARIA can make these components harder to use than native HTML.
9. Tables and data relationships
Data tables should expose headers and relationships so users can understand what each cell represents. Complex tables may need careful structure beyond visual row and column styling. Layout tables should not create misleading data-table announcements.
10. Critical user journeys
The most valuable screen-reader tests follow real tasks from beginning to end. For an e-commerce site, that may include search, product selection, variant selection, cart, checkout, validation, payment, and confirmation. For SaaS, it may include login, navigation, creating an object, editing it, saving changes, and confirming success.
This is where screen-reader testing becomes more than a checklist. Individual components can appear correct in isolation while the complete flow still fails because of focus order, dynamic updates, session timeouts, authentication, or inconsistent component behavior.
What automated accessibility tools miss
Automated tools are useful for detecting certain patterns in code, but they cannot reliably judge the quality of a complete screen-reader experience. They may identify a missing accessible name, but they cannot always tell whether the name is useful. They can identify some structural problems, but they cannot determine whether a user understands the workflow.
Common problems that often require human review include:
- focus moving to an unexpected location after an action;
- a dialog technically exposed but difficult to navigate;
- duplicate or misleading accessible names;
- form errors announced without enough context;
- status changes that are visible but not announced;
- poor heading structure that still passes basic code checks;
- custom components with inconsistent keyboard and screen-reader behavior;
- a complete journey that becomes confusing even though individual controls look valid.
A practical screen reader testing workflow
Developer-ready findings should record the environment, steps, user impact, and expected behavior.Start with a defined scope. Identify the most important templates, components, and user journeys. Confirm the supported platforms and choose representative screen-reader/browser combinations.
- Run an initial keyboard pass. Screen-reader testing is much harder to interpret if basic keyboard access is already broken.
- Review page orientation and structure. Check title, headings, landmarks, links, and reading order.
- Test components. Forms, menus, dialogs, tabs, accordions, tables, and custom controls deserve focused review.
- Complete real tasks. Follow the same paths users depend on for registration, purchasing, booking, account management, or other key workflows.
- Record exact findings. Document the screen reader, browser, steps, expected behavior, actual announcement, and affected component.
- Remediate and retest. Fixes should be verified in the same environment and, where appropriate, additional combinations.
A developer-ready report should explain the user impact and reproduction steps, not just cite a WCAG number. That makes accessibility defects easier to prioritize and fix.
Screen reader testing and WCAG
Screen-reader testing supports evaluation across multiple WCAG requirements rather than mapping to one single success criterion. It can reveal issues involving semantic information and relationships, keyboard access, focus order, headings and labels, accessible names, error identification, status messages, and other requirements.
It is also important not to treat screen-reader testing as the whole accessibility audit. Users may rely on magnification, voice input, captions, keyboard-only operation, switch access, or other methods. A complete accessibility review combines multiple testing techniques.
When should a business request professional screen reader testing?
Professional testing is especially valuable when a website or application includes complex custom components, authenticated areas, checkout or payment, account management, frequent JavaScript updates, enterprise procurement requirements, or a history of accessibility complaints.
It is also useful before a major release, redesign, procurement review, VPAT/ACR effort, or remediation validation. In those cases, testing should produce prioritized findings that development teams can reproduce and retest.
If you need a broader evaluation, Ada Access Group’s website accessibility audit combines manual testing, keyboard review, screen-reader testing, automated checks, reporting, remediation guidance, and retesting based on the project scope.
Final takeaway
Screen reader testing is not about making a page “talk.” It is about verifying that users can understand the structure, operate controls, receive feedback, recover from errors, and complete meaningful tasks without depending on sight.
NVDA, JAWS, and VoiceOver provide strong representative environments for website testing across Windows and Apple platforms. The right test matrix depends on your audience and product, but the principle stays the same: test real journeys with real assistive technology, document the actual user impact, and retest after remediation.