How to test with a screen reader
Screen readers are specialist text-to-speech software typically used by people with visual and cognitive disabilties, to browse the web, read documents and emails, and much more. Along with converting text to speech, they provide many ways to navigate and consume content. Deafblind people can use them together with braille devices.
Using a screen reader to explore your site helps you spot potential barriers faced by people who rely on them. It can also be an eye-opening experience for sighted people doing it for the first time, as many websites don't offer a comparable experience for both sighted users and screen reader users.
While testing with a screen reader is valuable, it should never replace user testing with people who use screen readers in their daily lives.
New to screen reader testing?
Like any type of testing, there's a learning curve. If you're just getting started, take some time to understand the basics: how screen readers work, how they interpret web content, and the common keyboard commands. If possible, work alongside experienced screen reader users to build confidence and learn how they interact with websites.
Some screen readers provide visual output on screen (like macOS VoiceOver), or can show text output (like JAWS and NVDA), but they don't use a typical graphical interface. That can make them feel confusing at first, especially if you're used to testing visually.
Tetralogical have put together a handy screen reader HTML support look up tool where you can check how different HTML elements behave across various screen readers, and what kind of interaction or output you can expect.
How screen reader users experience websites
Screen readers offer multiple ways to navigate and consume content. Users can list and move between headings, links, landmarks (like headers, footers, and main content), and form elements. They can also read line by line.
Desktop screen readers are usually controlled with the keyboard rather than a mouse, especially when used by people with visual disabilities.
Like any software, people have their own preferences for how they use their screen reader and browse the web. The latest WebAIM screen reader user survey shows the most common ways of finding information are:
- 71.6% Navigating through headings
- 13.6% Using the browser's Find feature
- 6.4% Reading through the page content
- 4.8% Navigating through links
- 3.7% Navigating through the landmarks/regions of the page
Of course, people will use a combination of methods to achieve their goals.
This video is a great example of how a screen reader user surfs the web where LĂ©onie Watson, a blind screen reader user, explores the web and talks through the barrier encountered.
Common screen readers
While not representative of all screen reader users, the WebAIM survey shows the top 3 most commonly used screen readers are:
Which screen readers to test with
Your operating system and budget will often determine which screen readers you can access. Ideally, multiple screen readers would be used for the most complete picture as some differences in support exist, however testing with one is certainly better than testing with none.
While the basic experience is similar, screen readers can announce content differently and use different keyboard shortcuts. Browsers make a difference as well. Some screen readers have better support in certain browsers. For example, VoiceOver on macOS works best with Safari.
According to the WebAIM survey, the most common browser and screen reader combinations are:
- JAWS + Chrome 24.7%
- NVDA + Chrome 21.3%
- JAWS + Edge 11.4%
- NVDA + Firefox 10%
- VoiceOver + Safari 7%
With majority of mobile screen reader users using iOS Safari + VO (70%), followed by 30% using Android and Talkback.
Understanding how your users browse your site should guide which screen readers you prioritise. For example, if most people visit your site using Chrome on Windows, testing with NVDA or JAWS may give more useful results than testing with iOS VoiceOver in Safari. Reviewing your analytics can help with this.
Handy screen reader resourses
- Deque - screen reader keyboard shortcuts and gestures
- JAWS hotkeys
- NVDA commands quick reference
- MacOS VoiceOver includes a tutorial (Settings > Accessibility > VoiceOver > Open VoiceOver tutorial)
How to test using a screen reader
Comparible experience
The aim of an accessible user interface is to provide a comparable experience for everyone, allowing people to complete their goals in a way that suits for them. Keep this in mind while testing with a screen reader. Make sure screen reader users can access the same content and the same functionality.
Before starting, remember that screen reader testing is just one part of accessibility testing. A great screen reader experience doesn't guarantee that your site is fully accessible to everyone. There's also crossover with keyboard testing. For example, if a button cannot be used by the keyboard, a screen reader user will have difficulties using it too.
Some areas of screen reader testing can be quite detailed and require a good knowledge of both the screen reader and how it should announce content in different situations. For example, when testing complex ARIA patterns. I'm going to focus on the basics, tests that can be performed on the majority of websites. It is worth noting that some checks are easier if you are sighted, such as checking whether content has been incorrectly hidden from screen reader users.
So, fire up your chosen screen reader and browser combination and work through the following checkpoints.
Keyboard shortcuts
Keyboard shortcuts vary between screen readers and keyboard layouts.
- NVDA uses slightly different commands on desktop and laptop keyboards. The shortcuts listed below are for desktop layouts.
- JAWS uses Insert as the main modifier key on desktop keyboards, and Caps Lock as the modifier on laptop keyboards.
- VoiceOver is available on both macOS and iOS. Commands listed below relate to macOS. iOS uses touch gestures to achieve similar actions. On macOS, VoiceOver commands use Ctrl + Option before most commands, referred to as VO below.
Where single-letter shortcuts are used to move to the next type of item (for example, H to jump to the next heading), holding Shift will move to the previous one.
Keyboard navigation is not enabled by default on macOS. You need to enable it in both of the following places:
- System Settings > Keyboard > Enable Keyboard Navigation
- Safari > Settings > Advanced > Accessibility > Press Tab to highlight each item on a webpage
1. Check the page title
When a page loads, the first thing a screen reader announces should be the page title. This is the same text shown on the browser tab. Make sure it is informative and not too long. It should briefly describe the topic and purpose of the page. Screen reader users rely on meaningful page titles to understand where they are on a site.
A good example of a short but informative page title would be: "Football equipment - Acme Sports Suppliers".
Poor examples include the page URL (which happens when no title is set) or using the same non-descriptive title for every page, such as only the organisation name.
2. Check a skip to content link exists
A skip link lets the user jump past repeated page content, such as header navigation. It is usually the first focusable element found when navigating with the Tab key, though sometimes it appears after cookie banners.
Check that:
- A skip to content link is present
- It moves focus to the main content when activated
3. Check the heading structure of the page
Just as sighted people scan the headings of a site to find relevant information, screen readers users can list and move between headings to find what they need.
List or navigate through the heading on the page by using:
- JAWS: H to go to next heading. Insert + F6 to list all headings.
- NVDA: H to go to next heading. Insert + F7 to display the element list, then select headings.
- VoiceOver: VO + Command + H to go to next heading. VO + U opens the Rotor, which allows you to list elements of certain types, use the left and right arrow keys to navigate to the headings list.
Check that:
- The page has one heading level 1, which should be the same or closely related to the page title
- Level 2 headings are used for section headings
- Level 3 are used for sub-section headings and so on to level 6
- Headings levels are not be skipped, for example a heading level 3 directly after a level 1
- There are no empty headings
4. Check link text is descriptive
List or navigate through the links on the page using:
- JAWS: U to go to next unvisited link. V to go to next visited link Insert + F7 to list all links.
- NVDA: K to go to next link. Insert + F7 to display the element list, then select links.
- VoiceOver: VO + Command + L. VO + U opens the Rotor, use the left and right arrow keys to navigate to the links list.
Check that links clearly describe their destination or action. Link text should make sense on its own whenever possible. While WCAG Level A and AA allow context from nearby text, this can still slow down users.
For example, imagine listing the links on a page and hearing several "Click here" links in a row. A screen reader user would then need extra steps to examine the surrounding content to work out where each link goes.
5. Check button text is descriptive
List or navigate through the buttons on the page using:
- JAWS: B to go to next button. Insert + Ctrl + B to list all buttons.
- NVDA: B to go to next button. Insert + F7 to display the element list, then select buttons.
- VoiceOver: VO + U opens the Rotor, use the left and right arrow keys to navigate to the button list.
Check buttons describe their purpose, for example: "Save", "Edit" or "Search". Pay extra attension to icon only buttons ensuring that a descriptive label is announced for each and not just "Button".
6. Check non-text content has an accessible alternative
List or navigate through the images on the page using the following, checking that accessible alternatives are provided and they convey the same information as shown in the image.
- JAWS: G to go to the next image. Insert + Ctrl + G to list all graphics.
- NVDA: G to go to the next image.
- VoiceOver: VO + Command + G. VO + U opens the Rotor, use the left and right arrow keys to navigate to the images list.
Images
Check that images which convey information or meaning have clear and descriptive alternative text. Decorative images do not need alternative text, though some screen reader user prefer it to be provided. The alternative text used largely depends on the situation and what the image is conveying. The W3C alt decision tree can help with this.
Images with an empty alt attribute are skipped by screen readers. Images with no alt attribute at all are often announced by their file name or file path, which is rather unhelpful.
Functional images, such as images used in links or buttons, should have alternative text that describes the action or purpose of the control, rather than the visual appearance of the image. For example, a linked passport image used to start a passport application should have alternative text such as "apply for a passport", not a visual description of the passport.
Complex images such as charts, graphs and maps
Complex images typically contain more information than can be included in a short sentance within an image's alt text. In these cases, a two part approach is needed. The image itself should have a short description within its alt text, including the location of a longer description or accessible alternative. Then, a more detailed breakdown of the information in the image should be place near the image.
This detailed alternative could be:
- A paragraph explaining the information
- A link to another page explaining the information
- A table listing the values shown in the graph
- A list of locations or directions shown in a map
7. Check tables
Navigate to tables and through cells using:
- JAWS: T to go to the next table. Insert + Ctrl + T to list all tables. Use Ctrl + Alt + arrow keys to move around the table cells.
- NVDA: T to go to the next table. Use Ctrl + Alt + arrow keys to move around the table cells.
- VoiceOver: VO + Command + T to go to next table. Use Ctrl + Option + arrow keys to move around tables cells. Tables can be listed in the Rotor though may not be by default.
Check that:
- If a caption is present, it's annouced and used as the table title when listing tables
- Header cells are read out when navigating, giving context for each cell
- It's clear which row and column you are currently in
- Tables are used only for tabular data (not for layout)
This video by UCSF shows an example of an accessible and inaccessible table where table headers have not been used correctly.
8. Landmarks (page regions)
Landmarks act as navigation signposts for screen reader users, helping them move quickly to common areas such as the header, main content, and navigation.
As you move through the page, check that key areas are communicated with appropriate landmark roles. What you'll typically hear read aloud:
- Banner: the page header using
<header>orrole="banner" - Complementary: a supporting section of content related to the main content using
<aside>orrole="complementary" - Content information: the page footer, containing information like copyrights and links to privacy and accessibility statements, using
<footer>orrole="contentinfo" - Main: the main content of the page, using
<main>orrole="main" - Navigation: a group of links used for site or page navigation, using
<nav>orrole="navigation" - Region: a section of content that has been deemed important enough to be listed in a summary of the page, using
<section>orrole="region"
In most screen readers you can list the landmarks on the page:
- JAWS: R to go to the landmark. Insert + Ctrl + R to list elements by type
- NVDA: D to go to the next landmark. Insert + F7 to display the element list, then select landmarks
- VoiceOver: VO + U opens the Rotor, use the arrow keys to navigate to the landmark list.
If multiple landmarks of the same type exist on the page (e.g., multiple navigations), they should have unique names. If a name is provided, you'll hear this when the landmark is navigated to or listed. For example "website navigation", where "website" is the name of the navigation landmark.
9. Check languages
Check that:
- The primary language of the page is announced with the correct accent and pronunciation (e.g,the result of
<html lang="en">) - If the page contains content in different languages, any language changes are announced and spoken with the appropriate accent and pronunciation
(e.g.,
<span lang="fr">le musée du Louvre</span>)
10. Forms
Navigating forms
When navigating inside a form, screen readers such as JAWS and NVDA may switch into a dedicated forms mode focused on text entry. In this mode, many browsing keyboard shortcuts are disabled. When testing forms, navigate through the using either Tab or screen reader specific form navigation keyboard commands.
- JAWS: F to go to the next form field. Insert + F5 to list form fields
- NVDA: F to go to the next form field. Insert + F7 to display the element list, then select form fields
- VoiceOver: VO + Command +
J to go to the next form element. VO + U opens the Rotor, then use the arrow keys to navigate to the forms list.
Navigate through the form, checking:
Inputs have descriptive labels
Each input must have a clear, programmatically associated label so users understand what information is required. When a form input is focused, a descriptive label must be announced.
For example:
- With a label: "First name, input, required"
- Without a label: screen readers announce only "input, required", leaving users guessing.
Input specific help text is announced
When input specific help text is provided (usually directly above or below an input), it should be read when the input receives focus. If the information is only presented visually and not programatically associated with the input, a screen reader in "forms mode" may not annouce it resulting in the user missing potentially important information.
Required inputs
Screen reader users should be able to tell which inputs are mandatory/required. If this is unclear, users may only discover missing information after submitting the form, creating unnecessary frustration and additional effort.
Errors
If an input is invalid or missing required information:
- The error message should be communicated as early as possible
- Users must be told which field has the error and what needs to be corrected
- Errors must be described in text. Colour changes or visual indicators alone are not accessible
Note: there are multiple ways of handling form errors depending on the technologies used. They could be injected "in-line" into the page when focus moves away a input using client-side validation or if validation is handled server-side, displayed on the form post-submission.
Radios/checkboxs have parent labels
Groups of radio buttons and checkboxes require contextual grouping for meaning.
For example: "Do you agree to our terms and conditions?" followed by a "yes" and "no" radio button. Without proper markup, screen readers may only announce "Yes, radio button" and "No, radio button" - missing the question entirely.
Grouping related inputs using <fieldset> and a descriptive <legend> ensures the correct context is announced.
11. Dynamic content
Modern websites often update content after the initial page load - for example when filtering results, submitting actions, or loading additional data in the background. If these changes are not announced to assistive technology users, they may be unaware that anything has happened. Unexpected screen changes was the 4th most problematic area in the WebAIM survey.
As you test, pay close attention to any functionality that:
- Loads new content without a full page refresh
- Updates only part of the page (e.g., a table, list, or message)
- Visually confirms an action without reloading the page or shifting focus
Check that:
- Changes are announced to screen readers
- Dynamic status messages shown visually, such as loading indicators, are also communicated to screen readers
- The user understands what changed and whether their action was successful
12. Custom components
Sometimes native HTML elements don't provide the functionality needed for a particular interaction, so developers create custom components. When this happens, additional work is required to ensure that the component communicates its:
- Accessible name (what it is)
- Role (what kind of control it is)
- State (if it's expanded, active, selected, etc.)
- Value (if it has one, for example entered text, or a selected option)
- and any changes that occur during interaction
Without this information, the component may appear fully functional visually but be unusable with a screen reader.
A common example is a custom dropdown that follows the ARIA Combobox pattern to support searching and option selection.
When testing custom components, check that:
- The label (accessible name) is announced when the component receives focus
- The correct role is announced (e.g., "combobox", "tab", "switch")
- Arrow keys, Enter, and Escape behave as expected for the component pattern
- Options are announced as they are navigated
- The currently selected value is announced
- Any dynamic updates (e.g., filtered lists) are communicated
Remember, the goal is a comparible experience. Taking the ComboBox as an example, sighted users can see the list of options, which is selected, they can see the search input and its value which is filtering the list. This information should also be communicated to screen reader users.
13. Check all content is identified correctly
In your screen reader, bring up the elements list:
- JAWS: Insert + F3
- NVDA: Insert + F7
- VoiceOver: VO + U opens the Rotor, then use the arrow keys to navigate through the different lists of element types.
Check: each element on the page has been identified correctly. For example, text that looks like a heading should be listed under headings.
Note: VoiceOver Rotor allows you to expand the elements types listed in the Rotor. This is configurable in the VoiceOver utility
14. Check interactive elements have a name, role, value and state
Tab through the interactive elements of the page, checking they are reachable and that each one properly communicates its:
- Accessible name: what the control represents
- Role: what type of control it is (button, link, checkbox, etc.)
- Value: the current value where applicable (e.g., selected option or text entered)
- State: whether the control is expanded, collapsed, checked, disabled, etc (where applicable - not all elements will have a state by default)
For example, a typical mobile "hamburger" menu button should announce something like: "Menu, collapsed, button", indicating its name, state and, role.
Native and custom interactive elements must also communicate their value when one is entered or selected. For example, a text input labelled "Name" with the value “James” might sound like: "James, contents selected, name, edit text".
15. Check common problem areas
Some components and patterns often cause difficulties for screen reader users. These usually need extra attention when testing:
- CAPTCHAs: : often lack accessible alternatives for puzzles or images, or may not provide labels for “I am human” checkboxes
- Cookie banners: often miss semantic markup, lack proper labels for controls, or fail to manage keyboard focus correctly
- Autoplaying content: audio can interrupt screen reader output, and auto-advancing carousels may repeatedly announce slide changes, resulting in the user having to hunt for the pause or stop button
- Chatbots: may have poor keyboard support, missing or unclear labels, or may not inform users when new messages appear
16. Optional - read through the full page content
This is a more indepth screen reader review of the entire page contents. Navigate line by line through the page content using:
- JAWS and NVDA: Down Arrow or Insert + Down Arrow to read continuously
- VoiceOver: VO + Right Arrow or VO + A to read continuously
Check that:
- All visible content is announced, to confirm nothing is hidden from screen readers using
aria-hidden="true" - Each item, including non-interactive content, is identified correctly (for example, lists are announced as lists)
- Instructions do not rely on sight or other senses, e.g., phrases like “click the blue square button on the left”
- Screen readers cannot access things that should be hidden, such as content inside a collapsed menu or accordion
Also check for content that only appears on hover. Screen reader users may not use a mouse, so any hover-only content will likely be missed unless there is another accessible way to access it.
Tips for smoother testing
How to silence a screen reader
Sometimes it can be handy to pause the speech while testing. In JAWS, NVDA and macOS VoiceOver this can be done with Ctrl.
How to adjust speech rates
As you get more familiar with screen reader testing you may wish to increase or descrease the speed of the speech output.
- JAWS: Ctrl + Alt + Page Up/Page Down
- NVDA: Insert + Ctrl + Page Up/Page Down
- VoiceOver: VO + Command + Shift+ Right arrow to access the rate settings
How to output speech to text
Some screen readers can output what they're reading in text form, which is useful for debugging.
- JAWS: Insert + Space follow by H to enable Speech History
- NVDA: Tools, Enable speech viewer.
- VoiceOver: Output by default to the activity window.
How to enable focus highlighting
As a sighted tester, it can be helpful to visually track the screen reader's focus while testing. When enabled, a coloured outline appears around the element currently being read aloud.
This makes it easier to understand what the screen reader is interacting with, helping you spot focus issues or unexpected reading order problems more easily.
- JAWS: Enabled by default. You can adjust this in Settings Center > Visual Tracking
- NVDA: Not enabled by default. Turn it on via Preferences > Settings > Vision > Enable Highlighting
- VoiceOver: Enabled by default. You can change this in VoiceOver Utility > Visuals > Show VoiceOver cursor
Summary
Screen readers are essential tools for many people. They offer multiple ways to explore and understand page content, but their effectiveness depends heavily on how a site is coded. When pages aren't built with accessibility and semantic HTML in mind, screen readers can struggle to identify content and functionality, making it harder for users to navigate or complete tasks.
Testing with a screen reader helps uncover issues that automated tools or visual checks may miss. While it can feel confusing at first, it's a skill worth developing - one that helps create a web that works better for everyone.