| | | |
---|
1.3.1 Info and Relationships | Elements MUST be used according to their meaning, not because of the way they appear visually. Use native HTML whenever possible and according to the W3C specifications. Labels MUST be programmatically associated with form input elements, using label (explicit or implicit), title , aria-labelledby or aria-label . A text alternative for informative CSS-generated content MUST be provided, AND the CSS-generated text SHOULD be set to aria-hidden="true" .
| | |
1.3.2 Meaningful Sequence | The reading and navigation order (determined by code order) MUST be logical and intuitive. While it is BEST PRACTICE to make reading order and visual order match (identical), It is NOT a true failure UNLESS meaning is really changed by the order. Dynamically generated content following user interaction MUST meet one of the following: assistive technology is automatically made aware of the new content OR the new content is the very next thing the assistive technology will encounter on the page. ℹ️Silence is bad. When screen reader users activate a feature (link, button, control, etc.), or when an important part of the content changes, they need to hear feedback. One of the basic challenges with dynamic content is to figure out the best way to tell screen reader users about the dynamic changes.
| order of elements in HTML match their visual order
content (like snack-bar) is dynamically generated at the end of the page and styled with CSS, but assistive technology is not made aware of it
| None
|
2.1.1 Keyboard | Page functionalities MUST be available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard. Page-specified shortcut keys and accesskeys MUST NOT conflict with existing browser and screen reader shortcuts.
| | |
2.1.2 No Keyboard Trap | | | None
|
2.4.3 Focus Order | The navigation order of links, form elements, etc. MUST be logical and intuitive. The order of content in the source code SHOULD be the same as the visual presentation of the content. The focus MUST be purposely moved or set (via JavaScript) onto the appropriate element when the user's action requires a change of context or location for effective keyboard or touch interaction. Modal dialogs: keyboard focus is moved to the newly-opened modal dialog ; keyboard focus returns to the invoking element (assuming the element is still on the page) when the modal dialog is closed; keyboard focus is limited (trapped) to the contents of the modal dialog and the browser's chrome (e.g., the browser-specific UI, such as the address bar, etc.); the page's content 'outside' of the modal dialog becomes inert, resulting in the content becoming hidden from assistive technologies, and inoperable to all users, so long as the modal dialog remains open; the use of the Escape key to close the modal dialog .
The focus MUST NOT become lost or reset to the top of the page, except when loading or re-loading a page.
| order of elements in HTML match their visual order
displaying a modal dialog automatically moves focus to the content of this dialog
the user is able to move focus outside the modal dialog
the tabindex is used to change the focus order
| Lint (bad) |
2.4.11 Focus Not Obscured (Minimum) | | | None
|
2.5.3 Label in Name | The visual labels for links, buttons, form elements, and other controls SHOULD match the programmatic labels (to allow easy and intuitive voice commands). For user interface components with labels that include text or images of text, the name MUST contain the text that is presented visually. The programmatic label MUST include the same text presented in the visual label, to facilitate voice activation.
| | Axe (bad) |
3.2.2 On Input | When a user inputs information or interacts with a control, it MUST NOT result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time.
| when the user selects an item in the dropdown, a modal dialog is displayed (without a warning of this behavior in advance)
a button is used to perform a “change of context” (such as opening a modal dialog)
| None
|
3.3.7 Redundant Entry | Information previously entered by or provided to the user that is required to be entered again in the same process MUST be either auto-populated or available for the user to select, with several allowable exceptions. The allowable exceptions when redundant entry may be required are when: re-entering the information is essential, the information is required to ensure the security of the content, or the previously entered information is no longer valid.
| | Axe (bad) |
4.1.2 Name, Role, Value | The name, role and value of page components MUST be programmatically determinable by assistive technologies. Every interactive UI element (e.g. links, buttons, controls for custom widgets, form inputs/elements) MUST have a name. Note: The name can come from the native text of the element (e.g. link text, button text), a value attribute (e.g. input type="submit" value="Name goes here" ), the aria-label text, the text referred to via the aria-labelledby ID value, or other attributes, such as title (depending on context).
The semantic meaning of elements MUST be communicated via appropriate native HTML element or ARIA role. Any dynamic properties — such as whether a checkbox is checked, a tab is selected, or a menu is expanded — MUST be programmatically set and updated. ARIA attributes (like aria-checked or aria-expanded ) can be used to reflect these states accurately. Links: Links MUST be semantically designated as such. Ideally this means using an a element with a valid href value. In rare problematic cases, setting role="link" (and adding all other aspects of link functionality) may be acceptable. A link MUST have programmatically discernible text, as determined by the accessible name calculation algorithm.
| | |
4.1.3 Status Messages | When the visual and/or functional state of an element changes (e.g. aria-valuenow , aria-pressed , aria-expanded , ariachecked ), the ARIA state MUST be changed accordingly. If a state change cannot be communicated via a change in an ARIA attribute, when the state change is the result of a user action or request, the state change MUST be communicated to the user visually AND MUST be communicated to assistive technologies using a technique such as: aria-live announcement
ARIA alert (inject text into a pre-existing container with role="alert" ) Move keyboard focus to the announcement (warning: moving the focus can be disorienting, so should be used with caution)
| a snack-bar notification is shown after completing an operation, aria-live is used for communicating it to assistive technologies
when a user searches and no results are found, "0 results returned" is shown below the search bar, but without a proper status role, screen readers won't announce it automatically
| None
|