Screen Reader
Foundations / Interaction / Screen Reader
Intro
Every application and UI component should be designed to allow blind and visually impaired users to utilize screen reader announcements for all relevant content.
This foundation concept provides an overview of what is needed to make a UI component accessible to screen readers.
Key Terms
- WCAG: Web Content Accessibility Guidelines
International standard that explains how to make web content more accessible to people with disabilities.
For more information, see WCAG for W3C. - ARIA: Accessible Rich Internet Applications Suite
Defines a way to make Web content and Web applications more accessible to people with disabilities.
For more information, see the WAI-ARIA Overview for W3C.
Basic Requirements
The following information must be provided for any focusable element:
- Role: The element type (such as “button” or “textbox”)
- Label: The name of the field
- Description: Additional “custom” information
- State: The current state of the element (such as “enabled” or “disabled”)
- Properties: Additional standardized information
Reading Order
On the currently focused element, screen readers usually provide available information in the following order:
- Label
- Role
- State
- Description
- Properties
Examples
Additional Features
Screen readers usually provide additional features for a better overview or fast navigation:
Reading Mode
In this mode, screen reader users can access non-focusable elements. Make sure that these elements also provide the necessary information (role, state, label, properties, description).
Navigation Dialogs
For specific roles (such as form, table, or link), some screen readers can display a list of all instances on the current page. Users can navigate to these items or trigger them directly.
Items are listed by their label.
Example
A page contains five links, each labeled "Details."
- To enhance accessibility and usability, provide meaningful and distinct names for each link, indicating the destination or context they relate to.
- Without unique labels, the dialog list will display the “Details” entry five times, giving the user only a 1 in 5 chance of selecting the correct link.
Roles
Roles are available for:
- Interactive controls (such as buttons and links)
- Non-interactive controls (such as images, icons, and separators)
- Non-interactive structural areas (such as landmarks)
- ...
A role implies which states and properties can be used.
For a list of available roles, see Roles in the screen reader design specification.
States
States are ARIA attributes that define the current condition of a particular UI element, which can change due to user interaction or automated processes.
For a list of available states, see States in the screen reader design specification.
Properties
ARIA properties are static attributes that define the inherent characteristics or behaviors of an HTML element, making these more accessible. For example, aria-keyshortcuts indicates keyboard shortcuts that an author has implemented to activate or give focus to an element.
For a list of available properties, see Properties in the screen reader design specification.
Labels
ARIA is used to label and describe purposes, as recommended by the Web Content Accessibility Guidelines. For more information, see ARIA-6 in the ARIA Techniques for WCAG 2.2.
A label is a specific identifier or name (= accessible name) given to a particular individual element within a certain role. It provides unique information about the individual element to distinguish it from other elements in the same role.
For more information, see Labels in the screen reader design specification.
Descriptions
Descriptions are used to provide additional information on an element (such as instructions, format requirements for an input field, tooltips, units of measurement, and custom attributes).
For information on adding descriptions, see Descriptions in the screen reader design specification.
Building Blocks and Example Patterns
Building Blocks
Building blocks provide the essential structure needed to define accessible, user-friendly, and efficient components.
- Disclosure Pattern
- Hiding Semantics
- Inputs with Drop-Down Area
- Ranges, Meters, Sliders, Multithumb-Sliders, Spin buttons, Window splitters
- Orientation
- Current Selected Context
- Selection
- Composites
- Value States
- Required User Input
Example Patterns
Example patterns are fundamental, well-defined components that serve as a basic setup, designed to be reusable and adaptable across various use case scenarios.
- Dialogs, Popovers
- Menus
- Message Strips
- Splitter
- Tabs
- Forms
- Read-Only Tables
- Listbox
- List
- Trees
- Grid and Table Properties
- Tree Tables