WCAG (Level AA) SC 4.1.3 Status Messages

WCAG (Level AA) SC 4.1.3 Status Messages (w3.org)

Issue description

WCAG 4.1.3, “Status Messages” is about making sure that status messages on a web page, such as error messages, success notifications, and alerts, are accessible to everyone, including people who use assistive technologies like screen readers.

Many websites display status messages in a way that is not programmatically accessible. This can happen when:

• Visually presented only: Status messages are only presented visually, without any underlying code that assistive technologies can access.
• Not programmatically associated: The status message is not programmatically associated with the element or action that triggered it.
• Not conveyed to assistive technologies: The status message is not conveyed to assistive technologies in a way that they can understand and announce to the user.

This can be problematic for:

• Screen reader users: Screen reader users might miss important status messages if they are not programmatically available.
• Users with cognitive disabilities: Users with cognitive disabilities may have difficulty understanding the context or meaning of status messages if they are not clearly associated with the relevant elements.

WCAG requirements

This guideline requires that status messages are programmatically determined so that they can be presented to the user by assistive technologies without receiving focus. This means:

• Using ARIA attributes: Use ARIA attributes, such as aria-live and role="alert", to indicate that an element contains a status message and how it should be announced by assistive technologies.
• Programmatic association: Ensure that the status message is programmatically associated with the element or action that triggered it.

Benefits

• Improved accessibility: Assistive technologies can announce status messages to users, providing them with important information about the status of their interactions.
• Enhanced user experience: It ensures that all users are informed about the status of their actions and can understand the feedback provided by the website.

Essentially, this guideline ensures that status messages are not just visually presented but also programmatically available, making them accessible to everyone, regardless of their abilities.

Related requirements

The following WCAG source criteria are often related to this as well. They can provide additional insights into specific challenges you may be encountering.

• WCAG (Level A) SC 2.5.3 Label in Name
• WCAG (Level A) SC 3.3.1 Error Identification
• WCAG (Level A) SC 3.3.2 Labels or Instructions
• WCAG (Level AA) SC 3.3.3 Error Suggestion
• WCAG (Level A) SC 4.1.2 Name, Role, Value

Who this issue impacts

Follow the links for additional information on user impairments:

• Vision impairment
• Cognitive impairment
• General user experience

Suggestions for remediation

Remediating WCAG 4.1.3, “Status Messages” involves making sure that status messages are programmatically determined and conveyed to assistive technologies, so users who rely on these technologies are informed of changes or actions on the page. Here’s how:

Use ARIA attributes

• aria-live: Use the aria-live attribute on the element that contains the status message. This tells assistive technologies that the content within this element will be updated dynamically and should be announced to the user.
  • aria-live="polite": Use for most status messages. The message will be announced when the user is idle.
  • aria-live="assertive": Use for urgent or critical messages that require immediate attention. The message will interrupt the current screen reader output.
• role="alert": Add role="alert" to the element to further indicate that it contains an alert or status message. This helps assistive technologies identify and announce the message correctly.

Associate status messages

• aria-describedby: If the status message relates to a specific form field or element, use aria-describedby to associate the message with that element. This helps assistive technologies provide context for the message.

Ensure visibility and focus management

• Visible to all: While the primary goal is to make status messages programmatically accessible, ensure they are also visually apparent to sighted users.
• Avoid automatic focus: Don’t automatically move focus to the status message, as this can be disorienting for keyboard users and those using screen readers.

Testing

• Screen reader testing: Thoroughly test the page with a screen reader to ensure that status messages are announced correctly and provide meaningful information to users.
• Keyboard navigation: Test the page using only the keyboard to ensure that status messages do not interfere with keyboard navigation or create unexpected behavior.

Example

If you have a form with a status message that appears after submission:

HTML
<form>
  </form>
<div id="status"></div> 

You can remediate it like this:

HTML
<form aria-describedby="status">
  </form>
<div id="status" aria-live="polite" role="alert"></div>

This code:

• Uses aria-describedby to associate the status message with the form.
• Uses aria-live="polite" to indicate that the status message should be announced to screen reader users.
• Adds role="alert" to further identify the element as a status message container.

By implementing these techniques, you can ensure that status messages are programmatically accessible to assistive technologies, providing all users with important feedback and information about the status of their interactions.

Links for more info

• Understanding WCAG SC 4.1.3 Status messages (digitala11y.com)
• Understanding Success Criterion 4.1.3: Status Messages (w3c.github.io)
• Status Messages (4.1.3 – Level AA) (wuhcag.com)