Accessibility Testing Procedure

Status Messages

Guideline

In content implemented using markup languages (such as HTML), 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.

Intent

The intent of this guideline is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work.

The intended beneficiaries are blind and low vision users of assistive technologies with screen reader capabilities. An additional benefit is that assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user.

The scope of this guideline is specific to changes in content that involve status messages. A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message:

1. the message 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;
2. the message is not delivered via a change in context.

Status Message Examples

1. After a user presses a Search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message "5 results returned" near the top of this new content. This text is given an appropriate role for a status message. A screen reader announces, "Five results returned".
2. After a user presses an Add to Shopping Cart button, a section of content near the Shopping Cart icon adds the text "5 items". A screen reader announces "Five items" or "Shopping cart, five items".
3. After a user enters incorrect text in an input called Postal Code, a message appears above the input reading "Invalid entry". The screen reader announces, "Invalid entry" or "Postal code, invalid entry".
4. After a user activates a process, an icon symbolizing 'busy' appears on the screen. The screen reader announces "application busy".
5. An application displays a progressbar to indicate the status of an upgrade. The element is assigned a suitable role. The screen reader provides intermittent announcements of the progress.
6. After a user submits a form, text is added to the existing form which reads, "Your form was successfully submitted." The screen reader announces the same message.
7. After a user unsuccessfully fills in a form because some of the data is in the incorrect format, text is added to the existing form which reads "5 errors on page". The screen reader announces the same message.
8. After a user puts a photo in an album in an online photo app, a snackbar displays the message "Saved in 'Wedding' album", which is also read by a screen reader.

Examples of Changes That Are Not Status Messages

1. An author displays an error message in a dialog.
   Since the dialog takes focus, it is defined as a change of context and does not meet the definition of a status message. As a result of taking focus, the new change of context is already announced by the screen reader, and thus does not need to be included in the scope of this Success Criterion.
2. Content is exposed or hidden when a user interacts with a user interface component, for example expanding components such as a menu, select, accordion or tree, or selecting a different tab item in a tablist.
   None of the resulting changes to content meet the definition of status messages. Further, all components that meet the definition of a user interface component already have requirements specified under 4.1.2 Name, Role, Value, including the need to make notifications of changes to values and states available to user agents, including assistive technologies. As a result, changes in state, such as "expanded" or "collapsed," would be announced by the screen reader, and thus the user would be alerted to the 'addition' or 'removal' of content. As such, such content does not need to be addressed by this Success Criterion.
3. After a user completes an input that indicates they are unhappy, a series of new inputs are added to the page about customer satisfaction.
   The new inputs do not meet the definition of status message. They do not "provide 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," and so are not required to meet this Success Criterion.

   NOTE: Creating a status message about these inputs being added, or notifying the user in advance that content changes may take place based on the user's response, are best practices but are not requirements in this scenario.

Finding and Inspecting Applicable Components

Open up the Web page or Web-based application in a suitable Web browser.

Find each occurrence of a status message (see Status Message Examples above) and determine whether the correct status is indicated to assistive technology.

Failure Conditions

• A status message does not convey the appropriate meaning/status to assistive technology.
  • Fails 4.1.3: Status Messages
• A status message receives focus.
  • Fails 4.1.3: Status Messages