Accessibility Blindness Cognitive Low Vision Types of Disabilities Uncategorized Vision WCAG WCAG Success Criterion

Status Messages (4.1.3 AA)

Who is it for?

This is for users who cannot percieve the entire page. This includes users that have a screen magnifier running, those that have resized the text, that

What is important to know?

A very important thing that most people get wrong about this criterion is that it doesn’t require that we add status messages. If there isn’t a status message already present on the page, then this does not apply. However, when a status message does appear, then a programmatic role or properties must be added to a component. I can’t stress this enough, this does not require that we add status messages. It only requires that when they appear, they can be presented to all users in a way that is meaningful.

It’s important to understand that this doesn’t cover things like expanding and collapsing content

Things that are not status messages.

I commonly run across this being applied to elements that it should not be applied to. The following is a short list of things that I’ve run across that were incorrectly identified as a failure of this success criterion.

  1. Content that displays in a dialog or alertdialog
  2. Content that is focussed
  3. Anything that is a change of context
    1. user agent;
    2. viewport;
    3. focus;
    4. content that changes the meaning of the Web page
  4. Content that shows or hides when the user interacts with it
    1. Tabs
    2. Select dropdowns
    3. Accordions
    4. Disclosures
    5. Show/Hide all buttons
    6. Menus
    7. Search suggestions as they type (this would be overly chatty and confusing anyway)
  5. State changes (These are covered in 4.1.2 Name, Role, Value)
    1. Expanding/collapsing content (aria-expanded)
    2. Pressed or checked states (aria-pressed, aria-checked)
    3. Valid state (aria-invalid)
    4. Orientation changes (aria-orientation)
    5. Selected state

What is covered?

Remember that this has to be a content change that is not a change of context. It, also, includes content changes that do not take the

Visual status messages

Text status messages

  1. The success or results of an action (e.g. submitting a search and getting results without refreshing the page)
  2. The waiting state of the application (e.g. loading spinners, server errors, etc.)
  3. The progress of a process (e.g. live progress indicators)
  4. Error reporting (e.g. an error that occurs on submit without a page refresh)

Non-text status messages

Images or images of text that appear must also be included in the status message. For instance, one thing that I see a lot is a warning triangle in front of a seemingly normal message. When read to a screen reader or other AT, it might just say “Server is busy”, but visually it looks much more serious. Likely they mean “Error: Server is busy”. This additional text would need to be included in the status message for the accessible name of the element.

There is also something non-visual that can occur such as the removal of a “loading” spinner. While removing content isn’t explicitly covered under this criterion, it would be pretty important to alert the user that the “loading has completed”.

Any modification to status text would need to be provided to the user as well. This would not include things like “stock tickers” especially where there may be multiple updating at the same time. This could create a page where the user cannot understand what is going on due to the amount of chatter that is occurring.

How do I code it?

The short answer would be to use a Live Region Role to indicate to the user when the content is updated or revealed.

How do I test it?

Check out the test for 4.1.3 Status message on the Failure 104 page.

Leave a Reply