Status messages deliver important information to your website’s users, providing them with an idea of what to expect when your content changes. For example, if your website has a form, a message reading “thank you for your submission" lets them know that they’ve completed the form successfully — there’s no need to re-enter information.
Because status messages occur when content changes, they’re a particularly important point of concern for web accessibility. The relevant standard here can be found in the Web Content Accessibility Guidelines (WCAG) 2.1 Success Criterion (SC) 4.1.3, “Status Messages,” which reads:
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.
If you’re new to WCAG, some of the terms in this success criterion might seem confusing. Below, we’ll explain how following this standard improves accessibility — and how to check your status messages to ensure that they’re useful for people with disabilities.
How does WCAG define a “status message?”
The World Wide Web Consortium (W3C) defines status messages as 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.”
Status messages can provide the following information to users:
- The success, failure, or other result of an action.
- The waiting state of an application.
- The existence of errors.
Common examples of status messages include shopping cart updates (such as “4 items in cart"), loading indicators, search result updates (“10 results found"), and success toasts. However, if the message changes the context of the page, it’s not a status message as defined by WCAG 2.1 SC 4.1.3.
In WCAG terminology, a “change of context" refers to situations in which changes occur as a result of user behavior. For example, if your website informs users of a form error by displaying a dialog box that immediately receives focus, that’s a change of context. You’ll still need to make sure that the dialog box is accessible to keyboard-only users, and you’ll need to make sure that the user can determine which element has focus, but the dialog box isn’t technically a status message.
Why are accessible status messages important?
If you’re confused by the definition above, it may be helpful to consider the purpose of WCAG’s “Status Message" standard. This criterion is primarily intended for people with vision disabilities who use screen readers to browse the web.
Consider the experience of a visual user who unsuccessfully fills out a form on a website. The website displays a status message that reads: “6 errors found in your form.” The user sees the message, then makes the necessary changes.
However, screen readers might not announce the new information (“6 errors found in your form") without proper markup. If the status message doesn’t contain an accurate WAI-ARIA role or property, the screen reader software won’t recognize the purpose of the message — and neither will the user.
That can create a frustrating experience. The screen reader user might need to search through the page to find the status message, or they might navigate away from the page while thinking that the form was successfully submitted.
Checking Your Website’s Status Messages for Accessibility
To determine whether status messages are accessible for people who use assistive technology, consider whether they’re programmatically determinable. In other words, could software identify the purpose of the status message?
Writing appropriate markup for status messages usually requires WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications Suite, commonly referred to as ARIA). As we’ve noted in other articles, ARIA is a powerful tool, but it can cause new accessibility issues when misused.
We’ll explain some basic concepts below, but if you’re confused about ARIA roles and properties, contact the Bureau of Internet Accessibility before making changes.
Related: 4 Questions to Ask Before Using ARIA
Use appropriate ARIA roles for status messages that don’t cause a change of context.
ARIA allows developers to define semantics for certain elements that don’t have equivalent semantics in native HTML. Several ARIA roles are particularly useful for defining status messages:
- role=”alert" should be used for important information that needs to be presented to the user immediately. For example, the alert role can inform the user of a successful form submission.
- role=”status" should be used for information that is helpful, but not essential. Most screen readers will announce the alert role right away, but status elements have a lower priority.
- role=”progressbar" can identify the status of an update. For instance, if a page is loading, the progressbar role informs the user of the ongoing update, allowing the user to monitor the status when they want the information.
When using ARIA, make sure to test your markup frequently. Make sure to use roles and properties accurately — and when in doubt, seek guidance from accessibility experts.
Write status messages that deliver clear, succinct information.
The goal of accessibility is to provide a better experience for all users, not to achieve a certain level of conformance with WCAG. With that in mind, make sure your status messages provide appropriate information for users.
“Item added to cart" may be sufficient for a shopping cart update message, but “Item added to cart, 6 items in cart" would be more useful. A good rule of thumb is that your status messages should provide non-visual users with the same information available to visual users.
However, don’t write lengthy status messages — remember, screen readers will announce the full text of every message, and too much info can result in a poor user experience.
Related: How Do Screen Readers Help People with Visual Impairments?
If a message causes a change of context, make sure it provides a pleasant user experience.
As discussed above, messages that change the context of the page aren’t technically “status messages.” However, they’re still important elements.
Pay close attention to messages that open a new window or cause a change of focus. For more guidance, read: What You Need to Know About Visual Focus and Accessibility.
