Technique F103:Failure of Success Criterion 4.1.3 due to providing status messages that cannot be programmatically determined through role or properties

Applicability

Technologies that support Accessible Rich Internet Applications (WAI-ARIA).

This technique relates to 4.1.3: Status Messages (Failure).

Description

The objective of this technique is to describe a failure where status messages are used in content but are not communicated to the user due to a lack of appropriate roles or properties.

The initial step in confirming a failure of Status Messages is to check that new dynamic content meets the definition of a status message. There are two criteria that determine if changed content on a page represents a status message:

  1. the new content does not take focus (does not change context);
  2. the new content provides information to the user on the outcome of an action, the state of an application, the progress of a process, or the existence of errors.
Where updated content does not conform to the definition of status message, a failure of 4.1.3 has not taken place.

The second step in this failure technique involves examining code. Where dynamic content meets the definition of a status message, its container can be examined for an appropriate WAI-ARIA role or property which allows it to be programmatically determinable as a status message. Currently there are only a small number of techniques available to indicate status messages to assistive technologies. They are:

  • role="status"
  • role="alert"
  • the use of an aria-live attribute on an element, set to either "polite" or "assertive"
  • role="log"
  • role="progressbar"
The absence of all of these techniques predicts a failure for the status message be announced to the user. Additionally, if the role or property is not set before the dynamic content is added, this also predicts a failure.

Since additional techniques may exist to alert an assistive technology, the final step of this failure technique is confirming whether an assistive technology (such as a screen reader) detects the dynamic content and exposes the information to users. Where a status message exists but is not surfaced by assistive technology, it is confirmation that a failure has taken place.

Examples

Example 1: Including a search results message without a status role

When a user carries out a search by pressing a Search button, the page content is updated with the results of the search, displayed in a section below the Search button. Since the search has no results, the change to content conveys the status message "0 results returned". This text is not given an appropriate role for a status message, and so a screen reader will not announce "Zero results returned" unless the user repositions to that text. Since the status message is not automatically presented to the user (i.e., instead, it must be manually discovered by the individual), it fails 4.1.3.

Working example: search results message without appropriate role

Tests

Procedure

For content that is dynamically added to the page:

  1. Check that the element containing the updated content does not take focus
  2. Check that the new content provides information to the user on one of the following:
    • the success or result of an action
    • the waiting state of an application
    • the progress of a process
    • the existence of errors
  3. Check that the element containing the new content does not have a pre-existing aria role of status, alert, log, or progressbar, or an aria-live attribute
  4. Check that the status message is not surfaced (i.e., announced) by assistive technology

Expected Results

  • If #1 through #4 are all true, then content fails the Success Criterion.