Status Messages (4.1.3 AA)

Who is it for?

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

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 that are not already present. It only requires that when status messages appear, they can be presented to all users in a way that reveals their presence.

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. As stated in the understanding document, “all components that meet the definition of a user interface component already have requirements specified in 4.1.2 Name, Role, Value”.

1. Content that displays in a dialog or alertdialog
   1. Basically, if it has interactive content in it, then it isn’t semantically a “status”.
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. User interface components. These are required to meet 4.1.2 Name, Role, Value which will
   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 and 1.3.1 Information and Relationships)
   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. So that would be things like a “Toast” message.

Visual status messages

Text status messages

The four types of status messages are:

1. The success or results of an action.
   1. This shouldn’t be confused with actions that are native to user interface components, such as expanding and collapsing, where the attributes of the control already conveying the status.
   2. A good example of this would be a custom search control that refreshes results on the page. If there were a status message that appears or updates to say, “15 results for ‘Jason Ament'”.
2. The waiting state of an application.
   1. Loading spinners or bars are a good examples of this.
3. The progress of a process.
   1. A good example of this is a multistep form where there may be a progress indicator at the top of the page that changes as you complete sections of the form.
4. The existence of errors.
   1. If an error is automatically detected (or is detected in response to a user submition) and is presented on the screen via text or other means, then that status must be made known to the user.
   2. Error messages that are contained within a dialog do not require a status role since this should already have a role=”alertdialog” or role=”dialog”.

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 the status role to indicate to the user when the content is updated or revealed. In some cases, when only part of an existing string are updates, it may be important to use aria-atomic to ensure that all of the string is announced instead of just the newly added text.

How do I test it?

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