The Web Content Accessibility Guidelines (WCAG) 2.1 are the most up-to-date version of the most widely used standards for website accessibility. First introduced in June 2018, WCAG 2.1 was intended to fill in many of the gaps in website and mobile accessibility since the publication of WCAG 2.0 a decade prior in 2008.
Among other additions, WCAG 2.1 introduced a new Level AA success criterion 4.1.3, also known as "Status Messages."Here's what you need to know about this new checkpoint, including what it is and how to successfully implement it on your website.
Related: History of WCAG
What is the WCAG 2.1 "status messages" success criterion?
WCAG success criterion 4.1.3 is intended for users of screen reader software and other assistive technology. Screen readers convert the text on a website or app into synthetic speech.
On many websites, the text of a page is not static; it may change in response to user actions. For example, if a user enters their address into an e-commerce website, the site may display a status message stating that the address is invalid. Other possible uses of status messages include:
- Presenting a message about the number of search results returned.
- Informing the user that an application is busy or available.
- Displaying information about the progress or completion of a process.
According to the WCAG glossary, the formal definition of a status message is “a change in content that is not a change of context, and that provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.”
In order to successfully use and navigate the website, people who use screen readers and other assistive technology must be made aware of these updates as well. However, making users aware of these new status messages must be done in a way that will not distract them or interrupt their work.
The full text of the WCAG 2.1 “status messages” criterion is as follows: “In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.”
Less formally, this means that status messages must be clearly labeled as such in the website’s code base, so that assistive technologies such as screen readers can identify them and decide how to relay them to the user.
Related: Assistive Technology 101
How to implement status messages
To implement WCAG guideline 4.1.3, web developers and designers should make use of the “status” role in ARIA.
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications), or ARIA for short, is a technical specification for improving website accessibility.
In ARIA, a role is an HTML attribute that defines the semantic role of an HTML element. For example, the ARIA role “textbox” is used to label elements in HTML that allow users to enter freeform text.
The “status” role in ARIA is used to label an HTML element that contains “advisory information for the user that is not important enough to justify an alert, and is often presented as a status bar."
Once the “status” role is attached to the status message, the assistive technology (which has been listening for such an event) should notify the user in the correct manner.
Depending on the type of status message, it may also be appropriate to use another ARIA role as well, such as the “progressbar” role for displaying the progress of a task.
Applying these and all accessibility best practices
Checkpoint 4.1.3 for status messages is just one of the new additions to the latest WCAG 2.1 standards. To learn more about how to comply with WCAG 2.1 and get your website and app into compliance, schedule a free chat with our web accessibility experts. Or, get started with a free website accessibility scan.
