Summary of this set of standards

Content must be robust and compatible with current and future tools, browsers and technologies.

Compatible

Compatible

4.1.1 - Parsing

Level A Obsolete in version 2.2

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

Implementation guidance

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 testing and assurance page 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

Level A

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 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

Level A

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-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.

Contribute to this page on GitHub