This technique demonstrates how to use the status role and describes the effect it has on browsers and assistive technology.
The status role is a type of live region and a container whose content is advisory information for the user that is not important enough to justify an alert, and is often presented as a status bar. When the role is added to an element, the browser will send out an accessible status event to assistive technology products which can then notify the user about it.
Status information content must be provided within a status object, and it should be ensured that this object does not receive focus. If another part of the page controls what appears in the status, the relationship should be made explicit via the aria-controls attribute.
Assistive technologies may reserve some cells of a Braille display to render the status.
When the status role is added to an element, or such an element becomes visible, the user agent should do the following:
- Expose the element as having a status role in the operating system's accessibility API.
- Fire an accessible status event using the operating system's accessibility API if it supports it.
Assistive technology products should listen for such an event and notify the user accordingly:
- Screen readers may provide a special key to announce the current status, and this should present the contents of any status live region. These should be announced when the user is idle, unless aria-live=”assertive” has been set and in which case the user may be interrupted.
- Screen magnifiers may enlarge the status.
Example 1: Adding the status role in HTML
The snippet below shows how the status role is added directly into the html source code.
<p role="status">Your changes were automatically saved.</p>
The Paciello Group published some data on compatibility via their 2014 blog post: Screen reader support for ARIA live regions
TBD: Add updated support information for common UA and AT product combinations
- Previous recommendations from WAI-ARIA 1.0 (2014) for the status role