Use a screen reader to evaluate a website

• Overview
• Choose a screen reader
• Evaluate a website
• Normal screen reader behavior
• Areas requiring extra attention
  • Form elements
  • Tables
  • Accordions
  • Carousels and slide shows
  • Images
  • Alerts, errors, and pop-ups
• Get help

---

Overview

Using a screen reader to check a web page or website can reveal many accessibility issues. To ensure that your website has not been created in a way that takes advantage of bugs or features of any one particular screen reader, you will need to check the site with more than one screen reader.

Choose a screen reader

Different screen readers behave in slightly different ways. Each has its own key combinations. The way content is announced may differ from screen reader to screen reader. For example, some screen readers may announce "link" before the name of the link, while others might announce "link" after the name of the link.

Common screen readers include:

• VoiceOver
  • Comes with all MacOS and iOS devices
  • Most often paired with Safari
• NVDA
  • Windows-only
  • Most often paired with Firefox
  • Free, open source
• JAWS
  • Windows-only
  • Most often paired with Chrome or Firefox
  • Price depends on license type
• Narrator
  • Comes with all Windows devices
  • Only compatible with Edge, at this date
• TalkBack
  • Available on some Android products

The screen reader and browser combinations above are widely accepted as the best and most consistent combinations, although many other combinations are possible. For example, Firefox can be used with VoiceOver on both desktop and mobile environments, but most people who use VoiceOver use it with Safari. While Chrome can also be used across multiple platforms and screen readers, its inconsistency makes its viability as a testing tool limited.

At the minimum, you should test with the following combinations:

• NVDA with Firefox
• VoiceOver with Safari
• VoiceOver on iOS

To get started with these screen readers, including keyboard commands or touch gestures, see:

• NVDA basics
• VoiceOver basics
• VoiceOver for iOS basics

Evaluate a website

When evaluating a website with a screen reader, listen for clarity and the logical order of page elements. Each web page should make sense without the visual context. First explore and listen to the page with the monitor turned off or the screen covered to measure the page's comprehensiveness and make note of problem areas. Then turn the screen back on and navigate the page with the screen reader key commands, verifying visually that all screen elements are accessible through the navigation.

1. Listen to the full page from start to finish to verify that the order of elements on the page follow a logical progression, such as left to right, top to bottom.
2. Use the Tab key to navigate through all the interactive items. Make sure they can all be accessed and function when using the screen reader.
3. Use the arrow keys to navigate through the page. The arrow keys will read line by line, reading everything on the page at your navigation pace.
4. Navigate through landmarks, links, and headings only. This can be done through a list, such as in the VoiceOver rotor or NVDA elements list, or by using special keys that navigate by item type.
   • Landmarks should be identifiable. For example, if there are two navigation landmarks, they should be labeled, such as "Main navigation" and "Section navigation".
   • Links should make sense out of context. The link destination should be clear from the link text. For a brief demonstration, see Quick accessibility test: Link text (YouTube video).
   • Headings should create an outline and indicate the type of content on the page.

Normal screen reader behavior

Screen readers may mispronounce words, including acronyms and abbreviations. This is normal and depends on the particular screen reader; see Don't Override Screen Reader Pronunciation. Screen reader users become familiar with the behavior of their particular screen reader, and if they choose to, can customize certain pronunciations.

Odd pronunciations should usually be ignored, including:

• Abbreviations: Screen readers may try to fill in the full word, if the abbreviation is in the screen reader's dictionary. Other times, the abbreviation will be announced letter by letter. Occasionally, the screen reader will select the wrong word. For example, "W" may be announced as "w", "west" or "watts".
• Acronyms: Screen readers may announce an acronym letter by letter or try to pronounce it. Words that appear to be acronyms, such as words in all capital letters, may also be treated as acronyms.
• Email: Screen readers may pronounce this as it is seen on screen. For example, "someone@somewhere.com" may be read as "someone at somewhere dot com". Keep in mind that some screen readers could read it differently.
• Addresses: Screen readers may announce the number portion of the address such as "9998 West Rd" as "nine thousand nine hundred and ninety eight West Road."
• Phone numbers: Screen readers may state these as single numbers. For example, 812-999-9999 may be announced as "eight hundred and twelve dash nine hundred and ninety nine dash nine thousand nine hundred and ninety nine".
• Dates: Screen readers may try to pronounce dates such as 8/20/2018 as "eight slash twenty slash two thousand and eighteen".
• Times: Screen readers may try to pronounce a timespan such as 9:00 - 5:00 as "nine zero zero five zero zero".

Pronunciations of acronyms, abbreviations, and such are defined within each screen reader's default speech settings. These settings can then be altered to fit each user's specific preferences. These settings are accessed within the screen reader's preferences menu.

Areas requiring extra attention

Form elements

Pay careful attention to forms.

• All form elements should be announced by the screen reader.
• Verify that the type of form element, for example, checkbox or text input, is announced upon entering each form field.
• Verify that the form label is announced upon entering each form field. The form labels should be clear, describing the purpose of the field and any expected formatting.
• Verify that any states, properties, or values are announced. Examples include checked versus unchecked, expanded versus collapsed, or a pre-populated value.
• Verify that each form field can be completed with the screen reader.
• Verify that changes to states, properties, and values are announced.

Required form fields should be announced. If an asterisk (*) is the only method used to indicate required form fields, the symbol must be included in the label and defined at the start of the form.

Many screen readers switch to forms mode when encountering forms. Non-form elements are ignored by screen readers in forms mode and will not be announced. Pay attention for any text on the form that is not announced.

Enter erroneous data in some form fields, including leaving required fields blank. Submit the form and pay careful attention to the error messages. The screen reader should immediately announce the presence of errors. Error messages should be clear, indicate the number of errors, and indicate how to correct the errors.

It should be easy to navigate to the fields in error, and field-specific error messages should be announced when entering the field.

Tables

Data tables must have names. The table name identifies the table.

Header cells must be present. When used correctly, the corresponding header(s) will be announced with each data cell.

Tables should be simple. Headers may be announced incorrectly for nested tables and complex tables with headers spanning multiple cells.

There should be no empty rows, columns, or data cells.

Accordions

Check any accordions. Make sure each accordion panel can be opened and that panel content can be accessed by the screen reader. Some accordions may not work with a keyboard and may not be announced correctly by screen readers.

Accordion resources:

• Create an expandable details widget in Canvas
• Accordion (Sections With Show/Hide Functionality)
• Accessible accordion example

Carousels and slide shows

Carousels and slide shows that automatically advance may cause problems for screen readers.

Note any interruptions, such as:

• The screen reader announcing a slide change even when focus is on another part of the page
• The slide advancing before the screen reader finishes announcing the current slide

Check the carousel controls; they should work with the screen reader. Best practices for carousel functionality include:

• Previous and Next buttons
• Navigation buttons
• Focus on selected item
• Play and Stop button
• Pause on mouse hover and keyboard focus

Carousel resources:

• Should I use a Carousel?
• Web Accessibility Tutorials: Carousel Concepts

Images

Image alt text should be announced, unless the image is decorative. The alt text should describe the image's content and function on the page.

For more, see Alternative text for images.

Alerts, errors, pop-ups

Any new content that appears on screen must be announced by the screen reader. This includes pop-ups, error messages, alerts, and any other new content.

Check any new interactive elements to be sure they work with the screen reader. Check that any pop-ups can be closed with the keyboard.

In many cases, such as a pop-up, focus should move to the new content. In other cases, such as status messages, the message should be announced, but focus should remain on the current element.

Next step: Check color contrast on a website
Previous step: Use automated tools to review accessibility
Return to index: Perform an accessibility review on your website

Get help