Blind | Lab

Paris

Design Consideration	Why?
All content must be presented in text or via a text equivalent (e.g., alt text for images or other non-text objects).	Screen readers cannot read non-text content (e.g., images) directly, but they can read alt text that you provide.
Information must not be conveyed by visual attributes alone (e.g., color, spatial location, thickness of text, background highlighting, etc.).	Not all visual information is available to screen readers. Even the visual attributes which are available to some screen readers, such as text color, are typically not announced by default.
All functionality must be available using only the keyboard (Note: be sure to test with the screen reader turned on, because there are subtle differences in keyboard behaviors when the screen reader is on).	Even though most blind users can physically use a mouse or trackpad, it doesn’t do them much good because they can’t see where the mouse pointer is. It is more effective for them to navigate by the keyboard.
The content must use markup with good structure and semantics (headings, landmarks, tables, lists, etc.).	Screen reader users often pull up lists of headings, landmarks, and other semantic elements to help them understand what is on the page. They can also navigate by these elements (e.g., jump directly to the main content landmark, or to a specific heading).
All custom controls (e.g., expand/collapse buttons, media player volume control, dialogs, etc.) must have the correct name/label, role (either with HTML or with ARIA), and value, and must change value when appropriate (e.g. `aria-expanded="false"` changes to `aria-expanded="true"` after activating the button).	Unlike native HTML elements, custom controls have no semantic parts natively, so screen readers can’t tell users what the widget is and can’t update users on the properties of the widget unless you supply that information via ARIA names, roles, states, and properties.
Users must receive immediate feedback after all actions, via their screen reader. Silence after activating a feature is always bad!	Examples of feedback: Expanded/collapse region, value changed on a control (e.g., on a slider, successful/unsuccessful form submission, notification that a new “page” has loaded in single-page applications, etc.).
Videos require audio descriptions (additional narration of visual content) if the video’s original audio track (dialog, sounds, narration) does not explain everything that a person who is blind would need to know to understand the video.	Users who are blind can hear the dialog, narration, and other sounds in videos, but they can’t see the visual parts of a video. So, if the visual parts convey important information, those parts will need to be described out loud for blind users to understand them.
On mobile devices: All features require a click action. Custom swipe actions on web pages will not work with the screen reader turned on.	When a blind screen reader user is on a mobile device, swipe actions are used by the screen reading software. All features (controls, widgets) on a mobile web page require a click action to work at all.

Design Consideration

Why?

All content must be presented in text or via a text equivalent (e.g., alt text for images or other non-text objects).

Screen readers cannot read non-text content (e.g., images) directly, but they can read alt text that you provide.

Information must not be conveyed by visual attributes alone (e.g., color, spatial location, thickness of text, background highlighting, etc.).

Not all visual information is available to screen readers. Even the visual attributes which are available to some screen readers, such as text color, are typically not announced by default.

All functionality must be available using only the keyboard (Note: be sure to test with the screen reader turned on, because there are subtle differences in keyboard behaviors when the screen reader is on).

Even though most blind users can physically use a mouse or trackpad, it doesn’t do them much good because they can’t see where the mouse pointer is. It is more effective for them to navigate by the keyboard.

The content must use markup with good structure and semantics (headings, landmarks, tables, lists, etc.).

Screen reader users often pull up lists of headings, landmarks, and other semantic elements to help them understand what is on the page. They can also navigate by these elements (e.g., jump directly to the main content landmark, or to a specific heading).

All custom controls (e.g., expand/collapse buttons, media player volume control, dialogs, etc.) must have the correct name/label, role (either with HTML or with ARIA), and value, and must change value when appropriate (e.g. aria-expanded="false" changes to aria-expanded="true" after activating the button).

Unlike native HTML elements, custom controls have no semantic parts natively, so screen readers can’t tell users what the widget is and can’t update users on the properties of the widget unless you supply that information via ARIA names, roles, states, and properties.

Users must receive immediate feedback after all actions, via their screen reader. Silence after activating a feature is always bad!

Examples of feedback: Expanded/collapse region, value changed on a control (e.g., on a slider, successful/unsuccessful form submission, notification that a new “page” has loaded in single-page applications, etc.).

Videos require audio descriptions (additional narration of visual content) if the video’s original audio track (dialog, sounds, narration) does not explain everything that a person who is blind would need to know to understand the video.

Users who are blind can hear the dialog, narration, and other sounds in videos, but they can’t see the visual parts of a video. So, if the visual parts convey important information, those parts will need to be described out loud for blind users to understand them.

On mobile devices:

All features require a click action.
Custom swipe actions on web pages will not work with the screen reader turned on.

When a blind screen reader user is on a mobile device, swipe actions are used by the screen reading software. All features (controls, widgets) on a mobile web page require a click action to work at all.

Congratulations!