This Accessibility Guide shows dev accessibility at a glance:
- Automated testing with axe
- Keyboard-only accessibility
- Focus management
- Label UI elements
- Best practices
Deque axe is one of many accessibility testing tools. Axe can be used in your browser and integrates with the native dev tools.
Customers with tremors, arthritis, or limited fine motor skills may not be able to use a mouse, so they use a keyboard or alternate switch control to navigate our content.
Keyboard focus: ensure you can access all interactive elements like links, buttons, forms, navigation menus, and dropdowns with the TAB key. Identify functional elements that the keyboard cannot access, and resolve unintended keyboard traps.Keyboard focus outline: ensure that a visible indicator (focus outline) can be seen clearly for each functional element. Identify elements that don't have a focus indicator.Note: most browsers have a default focus outline (e.g. Chrome's blue border). Since the default focus indicator will not always provide sufficient contrast against our designs, collaborate with design leads to improve this experience.
- Interactive elements like menus, expand/collapse, or form
<select>need to follow the keyboard model. - Keyboard focus should never reset to the top of the page, or “get lost” on the page during interactions.
General rule: when triggering an action (expanding sections, opening modal menus, etc.), the focus moves from the triggering element to the action. Reversely, when the action is completed (collapsing UI, closing a dialog, etc.), the focus moves to the triggering element.
Links & buttons have text (<a></a> = no bueno), form fields have labels <label for="field_id"> or a title attribute (if <label> doesn't make sense in your UI), and images have alt text, etc.
No <div> soup for us please. Use HTML elements for their semantic meaning - headings, lists, paragraphs, etc.
Use ARIA landmarks to complement the main HTML sections: see image.
