4.1.3 Status Messages: In content implemented using markup languages, 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. (Level AA)

Requirements

Why is it important?

• A sighted person can quickly see status messages on a page, and them go back to what they were doing or reading. Moving focus to a message can be disruptive for screen reader users, users of speech recognition software and keyboard only users.
  • Screen reader users navigate page with what is called a ‘screen reader cursor’. They can move that screen reader cursor using their keyboard, braille display or gestures on a touch screen.
  • Status messages (like system error messages or form validation error messages) need to be communicated to users without moving their ‘scren reader cursor’ on the page. Otherwise users would need to figure out where they are on the page afterwards, and move back to where they wanted to be.
• If focus is always moved to the message users with cognitive impairments may also be confused by unpredictable focus changes.

Summary

Make sure status messages are identified in code, so that assistive technologies can convey them to users.

Common Mistakes

• Status messages are not to be shown in a way that the AT understands or receive focus.
• Using role="alert" or aria-live="assertive" on content which is not important.
• On a page with ARIA live regions – if regions are hidden or not needed – always make sure to switch their active and inactive states accordingly.

Design Guide

Status Message Example for Android

You can use a live region in order to send a new AccessibilityEvent to the current enabled Accessibility Service on view updates. This means that any service like TalkBack will pay attention to any changes in that View and will automatically announce them.

To do so, you can easily mark any View as a live region in your XML file by adding the accessibilityLiveRegion attribute:

<View
  ...
  android:accessibilityLiveRegion="polite"
  .../>

Options for this attribute are the following:

• none: Accessibility services should not announce changes to this view.
• polite: Accessibility services should announce changes to this view.
• assertive: Accessibility services should interrupt ongoing speech to immediately announce changes to this view.

Carefully consider when to use live regions, as announcements for frequently changing views can be disruptive and annoying. Live regions can easily be overused, especially when you’re just starting out with accessibility. Live regions are the exception, not the rule.

Status Message Example for Flutter

Widgets with built in error messages such as TextField() in a Form() widget have their errors read out automatically when the validator: (value) {} returns a error string.

The same can be said for the AlertDialog widget.

• If you want the screen reader to read something out programmatically, for example on a state change or a widget coming into view you can use:

SemanticsService.announce( String, TextDirection.ltr); // the text direction should be based on some sort of localization setting.

Status Message Example for Web

The following are different situations you will need to cover:

When a status message tells the user something is successful

If a status message conveys a suggestion, or a warning or error

If a status message conveys information on the progress of a process

The ARIA role="progressbar" can be used but may not be enough on its own (depending on support by browsers and assistive technologies). For some examples of progressbar role see:

• Mozilla – Using the progressbar role
• ARIA Progress bar example – LevelAccess Labs

You can use the following techniques:

• Using role=log to identify sequential information updates
• Using role=status to present status messages in combination with providing help by an assistant in the Web page

References

1. ARIA live regions article on MDN
2. w3.org- Providing help by an assistant in the Web page
3. Accessibility Guidelines- Github.io