accessibility design conventions
Table of Contents
Esri targets WCAG 2.1 AA compliance, so large text and graphical elements need to pass a luminance contrast ratio of 3:1 and regular text needs to pass 4.5:1.
Large text equates 18pt or 14pt bold and greater. Regular sized text is anything less than that.
Note: Windows also provides a high contrast mode that is designed to improve text legibility and readability. It is often used by people with low-vision. High contrast mode will force a preset color palette on the browsing experience, but it also disables background images.
When designing components, it is important to use a combination of color, shapes, and text to indicate states and statuses, such as keyboard focus, form validation, and alerts. Using these other elements provides a secondary indicator in the event a color cannot be seen.
Approximately 300 million people in the world have some type of color vision deficiency. Color vision deficiency diminishes an individual's ability to distinguish between certain colors and may prevent them from seeing certain colors all together.
Keeping text aligned to the left (or right in certain languages) and limiting the use of text formatting such as underlining, italics, or writing in all capitals improves design for individuals who have dyslexia.
Consider how text will reflow within components if the words become longer in translations or get bigger because an individual has changed their browser or operating system base font size. Within WCAG it's expected that text should be able to scale up to 200% without loss of content or functionality.
Smart typography choices can improve readability for individuals with dyslexia, cognitive disabilities, or those who have low vision and may be using zoom tools to navigate an app or web page.
The value of using semantic HTML elements in interface design is that many elements communicate specific states to assistive technologies automatically; although, ARIA can be used to supplement interactions. However, it is recommended to use ARIA sparingly. When adding multiple elements to a page, ensure the HTML matches the intent. (e.g., If it is something that operates like a checkbox, is that apparent?)
Headings allow assistive technologies to automatically identify section headings and allow for keyboard shortcuts for navigating the page. It is best practice to properly nest headings (h1, h2, h3, h4, h5, h6) as a missing heading may make an individual think, they have missed a section of content.
Link text should be meaningful and inform the individual where the link will take them. For example, “Learn more about WCAG 4.1.3” instead of “Learn More”. Links should be associated with a unique identifier, such as an item title using aria-labelledby.
Body links should be denoted with a style other than color and should either avoid opening in a new tab or display an indicator, such as an icon or supporting text, that communicates it as such.
Navigation should remain consistent when moving linearly on a page; nothing should move or disappear. Primary navigation should also remain consistent between related web pages, so that high-level links and components, like search or sign in, show up in the same places.
When navigating via keyboard, focus order should be logical and generally follow the visual order of the page.
A well thought out page structure helps all users, especially those who navigate with assistive technologies to better understand the content and what native shortcuts are available within their tools.
- 1.3.1 Info and Relationships
- 1.3.2 Meaningful Sequence
- 2.4.1 Bypass Blocks
- 2.4.3 Focus Order
- 2.4.6 Headings and Labels
- 3.1.5 Reading Level
- 3.2.3 Consistent Navigation
- 3.2.4 Consistent Identification
- 3.3.2 Labels or Instructions
Labels and supporting text should be kept near their relevant fields providing context for non-sighted and low vision individuals who may be using assistive technologies. If the system has constraints (e.g., dates being formatted in a specific way) supply help text.
Placeholder text should not be used as a replacement for labels as it vanishes upon typing, which can increase the cognitive load for individuals using the form as they must memorize what was there.
Elements that are grouped need to be associated with related form controls, such as <fieldset> and <legend>. Examples include radio button groups, grouped checkboxes, and related form fields.
- Always indicate required vs optional fields.
- If a field uses input masks (asterisks on sensitive fields) provide an option to reveal the text to reduce cognitive load. Avoid patterns that require a press-and-hold to display plaintext.
- Buttons are triggered by the spacebar and enter/return keys.
- Because buttons have slightly different keyboard interactions than links, it's good practice to distinguish the design patterns. This helps individuals who may be using assistive technologies like dictation software, verbally navigate a page.
- Buttons should trigger an event, not take you to a different URL, as that is the purpose of links.
It may not always be clear to an individual why a button is disabled. Due to its disabled state, an individual cannot interact with the button to use error messaging to inform their understanding. When disabling a button is necessary, it's recommended to add a tooltip or supporting text explaining why.
Displaying form validation errors next to the field, which has triggered the message helps individuals with limited working memory maintain context.
- Summarize errors at the top of the form with anchor links to jump to the affected fields. This benefits anyone using a keyboard who may be forced to move through the form linearly.
- Including a count of errors in the summary helps all users, in particular those with cognitive disabilities.
- After establishing an error pattern, it should be used consistently throughout the interface. Icons and styling need to mean the same thing, no matter where the pattern is surfaced.
Being able to use mobile and touchscreen devices is valuable for individuals with physical or motor disabilities. Interactive elements should not require precise touch points and a best practice within mobile to use 44x44 px touch zones.
A well-designed form can be helpful to all users. Whereas poorly designed forms can add hurdles for those with cognitive disabilities or those who need to navigate by keyboard.
- 1.3.1 Info and Relationships
- 1.3.2 Meaningful Sequence
- 2.1.1 Keyboard
- 2.1.2 No Keyboard Trap
- 2.1.4 Character Key Shortcuts
- 2.2.3 No Timing
- 2.2.6 Timeouts
- 2.4.6 Headings and Labels
- 2.5.5 Target Size
- 3.2.1 On Focus
- 3.2.2 On Input
- 3.2.3 Consistent Navigation
- 3.2.4 Consistent Identification
- 3.3 Input Assistance
- 4.1.2 Name, Role, Value
When adding images to content, use alt text to provide a succinct description that can be read by screen readers. Avoid alt text that would be redundant to surrounding content. If no new information is conveyed, consider marking the image as decorative.
Background images do not support the application of alt text in the same manner as images do because they are rendered with CSS. They can be marked up to communicate as an image, but it requires role="img" and an aria-label rather than an alt attribute.
Tip: Remember Windows High Contrast Mode will disable background images, so if using them to convey information, add an aria-label.
If an icon has a functional purpose, such as indicating a menu expands, it should have alt text. For vector-based icons such as iconfonts or SVGs, the alt text should be added via an aria-label.
To support the screen reader, NVDA, SVGs must also have role="img" to be read.
If the icon is decorative and describing it would be redundant to surrounding content, then it should be marked as decorative. To hide SVGs from screen readers, use aria-hidden="true". Do not use aria-hidden="false" as screen reader support is inconsistent.
While not always possible due to mobile or internationalization, it is best practice to include a visible label with icons in buttons as this reduces the guesswork of an icon's label when using voice dictation software.
Adding alternative text to graphics benefits anyone who may be using a screen reader or voice dictation software to navigate and interact with content.
- 1.1.1 Non-Text content
- 1.3.1 Info and Relationships
- 1.3.3 Sensory Characteristics
- 1.4.5 Images of Text
- 1.4.11 Non-Text Content
- Auto-playing content is often considered distracting, especially if audio is involved.
- Content should not flash or blink more than three times per second to avoid triggering photo-epileptic seizures.
For individuals who have motion sensitivities, whether that rooted in a vestibular disorder, migraines, or other factors, moving interfaces may cause dizziness, headaches, nausea, or even seizures.
- 1.3.3 Sensory Characteristics
- 1.4.2 Audio Control
- 2.2.2 Pause, Stop, hide
- 2.3.1 Three Flashes or Below Threshold
- 2.5.4 Motion Actuation
Instructions for understanding and interacting with an interface should not rely on any sensory characteristics such as shape, size, visual location, orientation, or sound. Contextual descriptors such as those are often lost by non-sighted or low-vision individuals who may be using a screen-reader and keyboard shortcuts to navigate.
Error text should be descriptive and should not remove any visible instruction. If a form field has help text and form validation, they should both be able to be viewed at the same time.
Providing clear and unambiguous content, instructions and/or labels benefits everyone in better understanding an interface, but it can be particularly useful to those with cognitive, language, or learning disabilities, or those navigating an interface in a non-linear way.