AccessibilityRobust

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 Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.