How to Test Websites with Screen Readers

Screen reader testing matters because a website can look completely usable and still be difficult to navigate without sight. Missing labels, poor heading structure, unclear focus order, or controls that are never announced can block users even when the page passes a basic visual check.

That makes screen reader testing an important part of accessibility work. It shows how content is actually exposed to assistive technology and whether users can move through forms, links, menus, and interactive components in a meaningful order.

This guide explains how to test websites with screen readers, what to listen for during navigation, which issues commonly appear, and how to make those checks part of a broader accessibility testing process.

What are Screen Readers?

Screen readers are assistive technologies that convert on-screen content into speech or Braille, helping users navigate websites and applications without relying on visual cues.

When you use a screen reader, you can move through headings, links, buttons, form fields, images, and other page elements while hearing or reading the information exposed by the interface. You will also get details such as an element’s role, label, state, and position within the page structure.

For testing teams, this helps you understand whether the page makes sense beyond its visual design. You can catch missing labels, unclear link text, poor heading structure, and other accessibility issues that may not be obvious through visual checks alone.

How Website Navigation Works with Assistive Technology

When you navigate a website with assistive technology, you do not move through the page in the same way as someone using a mouse. Instead, you rely on keyboard commands, page structure, and spoken or Braille feedback to understand what is on the screen and where to go next.

1. Start the assistive technology: You can launch a tool such asNVDA, JAWS, or VoiceOver and then open the website you want to use.
2. Understand the page structure: The tool uses the accessibility information exposed by the page to announce elements such as the page title, headings, landmarks, links, buttons, and form fields. This gives you a sense of how the page is organized.
3. Move through the page: You can navigate using the keyboard, headings, landmarks, links, or other shortcuts instead of moving visually through the interface. The focused element is announced as you go.
4. Interact with controls: When you reach a button, link, checkbox, input field, or menu, you will hear details such as its label, role, state, or value. This tells you what the control does and whether it can be used.
5. Receive feedback as the page changes: Error messages, alerts, validation updates, and other dynamic content can be announced when the website exposes them correctly to assistive technology.
6. Adjust the experience: You can change speech rate, verbosity, navigation shortcuts, and other settings to make browsing faster or easier, especially on longer or more complex pages.

Why Testing with Assistive Technology Matters

A website can meet many visual and functional requirements while still being difficult to use without sight. Testing with assistive technology helps you experience the page through the same labels, structure, focus order, and feedback that users depend on.

• Inclusive of wider audience: The World Health Organization estimates that at least 2.2 billion people worldwide have a near or distance vision impairment. Not everyone with vision impairment uses a screen reader, but the figure shows why non-visual access cannot be treated as a niche requirement.
• Catch barriers that automated checks can miss: Manual testing lets you hear whether a page actually makes sense when navigated without sight. WebAIM also notes that automated tools cannot detect every accessibility failure, so passing an automated scan does not mean a page is fully accessible.
• Find issues that remain common across the web: WebAIM’s 2026 analysis of one million home pages found detectable WCAG failures on 95.9% of pages. Missing alternative text appeared on 53.1% of home pages and missing form labels on 51%, both issues that can directly affect what users hear while navigating.
• Check whether important journeys are actually usable: You can test whether users can understand headings, complete forms, activate buttons, follow links, recover from errors, and respond to dynamic updates without relying on visual cues.
• Support accessibility requirements: Accessibility obligations vary by region, but WCAG is widely used as a technical benchmark. For example, the U.S. Department of Justice’s Title II rule sets WCAG 2.1 Level AA as the standard for state and local government web content and mobile apps. The European Accessibility Act also places accessibility requirements on key products and services across the EU.

Testing this way goes beyond checking whether accessibility markup exists. It helps you understand whether someone relying on assistive technology can actually understand the page, move through it, and complete the same tasks as other users.

Screen reader testing works best when you follow the page the way a user would rather than checking isolated elements. Start with the main journeys, move through the interface using keyboard and screen reader commands, and listen for anything that makes the experience unclear or difficult to complete.

1. Learn the basic controls: Get familiar with the main commands for the screen reader you are using, including how to move by headings, links, landmarks, form fields, and other controls.
2. Start with important user journeys: Test flows such as navigation, login, search, form submission, checkout, or account creation. This helps you see whether someone can complete meaningful tasks without relying on visual cues.
3. Check page structure: Move through headings, lists, landmarks, and forms to see whether the content follows a logical order. Semantic HTML should give users enough structure to understand where they are on the page.
4. Listen to names, roles, and states: Check whether buttons, links, inputs, checkboxes, and other controls are announced clearly. Images and meaningful icons should also have appropriate alternative text.
5. Test keyboard interaction: Make sure every interactive element can be reached and operated without a mouse. Watch for skipped controls, trapped focus, or focus moving somewhere unexpected.
6. Check errors and dynamic updates: Trigger validation messages, alerts, menus, dialogs, and other changing content. Important updates should be announced when they appear instead of relying only on color, position, or animation.
7. Combine it with other accessibility checks: Screen reader testing should sit alongside automated scans and other manual testing. Each method catches different issues, so using them together gives you a much clearer picture of the experience.

The goal is not simply to hear every element announced. You should be able to move through the page, understand what each control does, and complete the same tasks available to users navigating visually.

WCAG gives you the accessibility requirements, but screen reader testing helps you see whether those requirements actually work for someone navigating the page without sight. The easiest way to do this is to test complete tasks and listen for the points where the experience becomes unclear, incomplete, or difficult to control.

1. Check keyboard navigation and focus

Scenario: A user moves through a form without using a mouse.

• Make sure every interactive element can be reached with the keyboard.
• Check that focus moves in a logical order.
• Listen for whether the focused control is announced clearly enough to understand what it does.
• Watch for focus getting trapped or disappearing when menus, dialogs, or other components open.

2. Test forms from start to finish

Scenario: A user completes and submits a form.

• Check that each field has a clear label.
• Confirm that required fields and instructions are announced.
• Submit incomplete or invalid data and listen for the error messages.
• Make sure users can understand what went wrong and move back to the field that needs attention.

3. Review images and media

Scenario: A user reaches an image, chart, or media element.

• Check that meaningful images have useful alternative text.
• Make sure decorative images do not create unnecessary announcements.
• For video or audio content, check whether captions, transcripts, or descriptions are available where needed.
• Listen to the experience rather than judging the alt text only by how it looks in the markup.

4. Navigate by headings and landmarks

Scenario: A user wants to understand the page before reading everything.

• Move through the page using headings and landmarks.
• Check that headings describe the sections they introduce.
• Make sure the hierarchy feels logical and does not skip around unexpectedly.
• Confirm that landmarks such as navigation and main content help users jump to important areas quickly.

5. Listen to links and buttons out of context

Scenario: A user moves through only the interactive controls on a page.

• Check whether links and buttons still make sense when heard on their own.
• Replace vague labels such as “Click here” or “More” when the purpose is unclear.
• Make sure icon-only controls expose an accessible name that describes the action.

6. Trigger dynamic updates

Scenario: A user opens a menu, adds an item to a cart, or causes content to update without a page reload.

• Check whether important changes are announced when they happen.
• Make sure status messages, loading states, and confirmations do not rely only on visual changes.
• Avoid announcing every minor update, since too much feedback can make the page harder to follow.

7. Test error recovery

Scenario: A user submits something incorrectly and needs to fix it.

• Check that the error is announced at the right time.
• Make sure the message explains what needs to change.
• Confirm that the user can find the affected field without searching through the entire page again.

8. Read tables as data, not just rows of text

Scenario: A user navigates a table containing several rows and columns.

• Check that column and row headers are marked correctly.
• Move through the cells and listen for whether the headers give enough context to understand each value.
• For complex tables, make sure relationships between headers and data remain clear as the user navigates.

The goal is not to make every screen reader announce the page in exactly the same way. You are checking whether a user can understand the content, move through it, operate the controls, and recover from errors while meeting the relevant WCAG requirements.