Screen Readers

General information

A screen reader is an application that reads the user’s screen to the user. This allows people with visual disabilities, certain cognitive and neurological disabilities, and a number of other conditions to use their computers regardless of whether they can see the screen or read the text ¹.

A good metaphor for what it’s like to use a screen reader can be found in A Tale of Two Rooms by Ryan Jones.

A blind or low-vision person can’t scan a page and summarize what it’s about the way that a sighted person can. Screen readers provide people a lot of navigation options that standard browsers don’t, so that they can get an idea of what the site containers. These include:

• Jumping from link to link using the tab key or viewing a list of links on the page ¹
• Accessing a list of all the headings on the page ¹
• Accessing a list of all the landmarks and sections of the page ¹
• Jumping from paragraph to paragraph, or navigating by tables, lists, buttons, forms, links, images, and other formats ¹.

Training

• How Screen Readers Read Content in Designing for Screen Reader Compatibility by WebAIM provides more information on what screen readers read out and how they behave.
• Setting up a screen reader testing environment on your computer
• Understanding Screen Reader Interaction Modes by Léonie Watson

Training Videos

The following three videos are by far the best introduction to how screen readers work that I’ve found yet.

Design Considerations

Do

• Make sure your content follows a linear, logical layout ².
• Write descriptive links and headings, for example “Contact Us” ².
• Present all content in text or in a text equivalent, because screen readers can only read text content ³.
• Ensure all functionality and interactivity can be accessed by keyboard, because while most blind users can move a mouse or a trackpad, they can’t see where the pointer is ³.
• Use semantic HTML. Screen readers offer users the ability to navigate by headings, landmarks, and other semantic elements when they’re present ³.
• Use the correct name or label, role, and value for custom controls through either HTML or ARIA to ensure that screen reader users understand what is going on ³.
• Provide immediate feedback after the user or the system take an action. If the browser is silent, the user doesn’t know whether something failed or succeeded, or even finished ³.
• Label buttons and loading states in native mobile apps so that they are read by screen readers ⁴.
• Provide usage hints in iOS and Android to provide additional guidance ⁴.
• Provide a clear exit path from modal dialogs in native applications ⁴ (and web applications).

Don’t

• Don’t spread content all over a page ².
• Don’t convey information based solely on visual attributes such as the position of something, its color, thickness, background highlight, etc. because screen readers generally can’t access visual information ³.
• Don’t rely on text size and placement for structure ².
• Don’t write uninformative links and headings, for example, “Click here” ².
• Don’t use custom swipe actions on mobile devices or touchscreens. Screen reader users control their screen readers on phones and tablets using swipe actions. If you create custom swipe actions, either the screen reader will ignore your swipe action or your swipe action will break the screen reader. Ensure all functionality uses a click action ³.

Own Words Videos

The following videos provide examples of people using screen readers.