Robust
Content must be robust and compatible with current and future tools and technologies.
Index
Compatible
Compatible
4.1.2 - Name, role, value
All interactive components must have an accessible name and role, and the state of the component must be communicated to assistive technologies.
Understanding Success Criterion 4.1.2: Name, Role, Value
Implementation guidance
All interactive elements and components must:
- have an accessible name and;
- an implicit or explicit role and;
- communicate information about their state
See guidance for complex components/widget in the ARIA Authoring Practices Guide (APG)
How to test
The guidance in the ARIA Authoring Practices Guide (APG) includes testing practices for complex components.
How to test with JAWS/NVDA
Use the arrow keys, Enter key and Spacebar to reach and interact with all the user interface components on the page and check that the screen readers announce all the information necessary to understand the role and current status of the components and how to operate them.
4.1.3 - Status messages
There are different situations where a page needs to dynamically display a status message. These messages need to be conveyed to assistive technology users, even when they don’t receive focus. Where possible, you should avoid disturbing the user’s place in a page.
Understanding Success Criterion 4.1.3: Status Messages
Implementation guidance
Status messages or updates which occur visually should be communicated to screen reader users.
These messages should be non-intrusive and only used when there is a benefit to the user, for example informing them how many search results have been returned, that errors have occurred in their submission or that a form has been successfully submitted.
Generally, a notification/status message should be implemented using an ARIA live region (see aria-live property and ARIA live regions).
Avoid using the assertive setting for ARIA live regions. The polite setting is sufficient in most use cases.
How to test with JAWS/NVDA
When completing actions that involve a visual status message or information that a user needs to be made aware of, check that the message is announced to screen reader users in a timely manner.
Note that these messages should not interrupt the screen reader's current activity but should relay the information at a suitable break in the screen reader audio.
Get in touch
If you’ve got a question or suggestion share it on the UK Home Office Slack channel #ask-accessibility or email accessibility@homeoffice.gov.uk.