Content must be robust and compatible with current and future tools and technologies.
4.1.1 - Parsing
The code of the page must not cause browser or assistive technology conflicts. This ensures that content and functionality is presented in a way that works reliably across all supported browsers and assistive technologies.
Understanding Success Criterion 4.1.1: Parsing
HTML code must conform to the standard identified in the doctype statement.
ARIA code must conform to the rules for use with the host language (HTML).
Not all errors and warnings raised by an HTML validator have an impact on accessibility. We recommend using the bookmarklets in the Non-technical testing section rather than starting with an HTML validator.
How to test with a manual check
Use the two bookmarklets outlined in the article at https://www.tpgi.com/wcag-2-0-parsing-error-bookmarklet
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
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 at https://w3c.github.io/aria-practices
How to test
The guidance at https://w3c.github.io/aria-practices 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
Status messages or updates which occur visually should be communicated to screen reader users.
These messages should be non-intrustive and only used when there is a benefit to the user, for instance informing them how many search results have been returned, that errors have occured 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 https://www.w3.org/TR/wai-aria/#aria-live and https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions).
Avoid using the assertive setting for aria-live regions. The polite setting is sufficent in most use cases.
Testing 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 screereader users in a timely manner.
Note - these messages should not interupt the screenreaders current activity but should relay the information at a suitable break in the screenreader 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 firstname.lastname@example.org.