Disability Considerations

This section provides a limited list of how something should be designed and why that design is important for a particular disability group. This is not an exhaustive list.

Design Considerations for Blindness

• All content must be presented in text or via a text equivalent (e.g., alt text for images or other non-text objects). Why: Screen readers cannot read non-text content (e.g., images) directly, but they can read alt text that you provide.
• 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 behaviours when the screen reader is on). Why: 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.). Why: 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, dialogues, 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). Why: 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. The silence after activating a feature is always bad! Why: 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 (dialogue, sounds, narration) does not explain everything that a person who is blind would need to know to understand the video. Why: Users who are blind can hear the dialogue, 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: (1) All features require a click action. (2) Custom swipe actions on web pages will not work with the screen reader turned on. Why: 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 Considerations for Low Vision

• The pinch-to-zoom feature must not be disabled (avoid ). Why: When zooming is disabled on a web page, which the parameter user-scalable=no does, low vision users who use screen magnifiers to read content may be unable to properly see information on a web page.
• All text must pass contrast guidelines against the background (verify using axe Accessibility Testing browser extension or a similar tool). Why: Some users who have low vision may see in low contrast. So, text, borders, and other elements may appear as the same or similar shades of brightness to them. Textual elements that are too close in brightness to background colours may be extremely difficult to read for these users.
• Links, buttons, and controls must have a visible :focus state and should have a visible :hover state. Why: Some low vision users may use a keyboard or a mouse, or both, as input methods. Having visible :focus and :hover states helps users to know where the keyboard/mouse focus is on a web page. The default browser :focus state is acceptable per the WCAG guidelines, but users with low vision benefit greatly from enhanced CSS :focus and :hover states.
• The user interface should provide a clear visual distinction between content (e.g., text) and controls (e.g., buttons, links, etc.). Why: Again, users who may see in low contrast may have difficulty distinguishing whether controls are actionable on a web page because these elements may blend together with surrounding text and background colours.

Design Considerations for Colorblindness

• All information must be understandable without needing to distinguish between colours Reds and greens are especially problematic when used as the only way to convey information. Why: When colours alone are the only methods being used to communicate important information on a web page, people who are colorblind may miss that information altogether. In addition to colour, consider using text and symbols as a means to convey information.

Design Considerations for Deafness

• All videos must have captions. Why: Without captions, people who are deaf may miss critical information communicated through dialogue and narration and may miss important sounds that give meaning to the video.
• All audio-only content must have transcripts. Why: Transcripts are necessary to convey all of the information being communicated by audio, including dialogue (and identifying speakers), narration, musical cues, and sound effects.
• Sign language interpretation of videos can be very helpful. Why: There are some people who are deaf whose primary means of communication is sign language. For this group, sign language interpretation may be preferred over captions and transcripts.

Design Considerations for Deafblindness

• All of the considerations for blindness apply. Why: Like people who are blind, people who are deafblind use a screen reader as an output device. But instead of relying on audio output, a refreshable braille output device is used so people who are deafblind can read content by touch.
• All of the considerations for deafness apply. Why: because an alternative means to access audio content should be provided, particularly in a text-based format.
• In addition, a transcript must be provided for audio and video content. Why: Transcripts are the only way a person who is deafblind will be able to access all of the information communicated in audio and video formats. Some modern Braille readers have the ability to display video captions, but it can be challenging to read the Braille characters as quickly as the captions are displayed, so transcripts are still the best option for deafblind users.

Design Considerations for Motor Disabilities/Dexterity

• All functionality must be available using only the keyboard. Why: For sighted keyboard users or those who use devices that emulate keyboards, everything that can be done on a web page with a mouse should be able to be done using only a keyboard. People with motor disabilities may not have the fine motor skills required to use a mouse.
• Links, buttons, and controls must have a visible :focus state and should have a visible :hover state. Why: The only way sighted keyboard users are aware of where the keyboard focus in a way is by a visible :focus state. If focus is turned off, interaction on web page for these users may be extremely difficult and nearly impossible. The default browser :focus state is acceptable per the WCAG guidelines, but like low vision users, sighted keyboard users can benefit greatly from enhanced CSS :focus and :hover states.
• With session time-outs, warn users before the time expires (e.g. an accessible dialogue or alert), and give them the option to extend the session. Ensure the warning itself allows for slow responses. A recommended minimum response time is 2 minutes. Why: People who have motor disabilities need more time to enter information into a web page. So, it is important that they are given sufficient time and options to extend time limits.
• Provide large click targets (links, buttons, controls) for users who have movements that are difficult to control. Why: People who may have tremors or spasms need to be able to activate targets on a web page. Increasing the target area for these users can help maximize their chances of accurately selecting the target on the web page.

Design Considerations for Speech Disabilities

• Don't depend on voice input (e.g., in mobile apps, custom widgets, games, etc.). Why: People with speech disabilities have difficulty with producing voice sounds and using muscles in their mouths, so it is critical that alternative means of communication are provided such as chats, forms, email, etc.

Design Considerations for Cognitive Disabilities

• For users with lower comprehension: (1) Simplify the interface as much as possible. (2) Simplify the content as much as possible. (3) Keep videos and audio as short as possible. (4) Limit the number of choices on the screen. (5) Provide help features. (6) Design for ease of use. (7) Testthe usability of the interface with actual users, preferably including users with cognitive disabilities. Why: Users who have lower comprehension will have a better web experience if the interface and content are easy to use and easy to understand. Too many options and complex information may be difficult for them to process.
• For users with memory loss: (1) Retain information across screens and within a path. (2) Provide help features. Why: A website that has predictability across all its pages (same navigation, same structure, etc.) will greatly benefit users with memory loss. Sites that are too complicated may fatigue users with memory loss. If users have difficulty interacting with the web page, help features can assist them with navigating the web page.
• For users with distractibility: (1) Reduce or eliminate distractions (be careful with ads, carousels, intrusive audio, intrusive video, etc.). Why: Too many distractions on a web page may cause people with cognitive disabilities to miss important information being conveyed on a web page. Distractions may cause them to lose focus or overwhelm them, and users may navigate from the web page.

Design Considerations for Reading Disabilities

• For users with difficulty reading (dyslexia, etc.): (1) Supplement text with illustrations, videos, audio, etc. (2) Avoid the highest level of contrast for text against the background (e.g., black on white) BUT be sure to stay within the contrast range that people with low vision need. Why: People who have difficulty reading the text will need the information conveyed in other formats like images, audio, and video. Using the highest contrast may also be difficult for people to read and hard on the eyes, so using colours that are a slight step down in contrast (e.g., dark grey against white or off-white) may make reading text a little easier.

Design Considerations for Seizure Disorders

• Don't include videos, animations, or transitions with flashing light sequences of 3-times or more per second. Why: Using flashing, blinking, and flickering content that lasts for more than 3 times per second may trigger photo-epileptic seizures in users.