ARIA Live Region Playground

A fun (perhaps?) and safe place for exploring ARIA live regions, their attributes, and their behaviors.

Live Region Display Area

Container below can be set to be an ARIA-live region. See Options in the aside to control properties and to start, stop, and reset messages that get added to the the container.

Force focus to live region container above

Secondary Live Region Display Area

Another live region which adds messages wrapped in div when the button below is pressed.

Message For Secondary Region

Secondary Region ARIA Live Value

Alert Role Implementations Live Region

ARIA live regions with role=alert should behave differently from other sorts of live regions. Alerts are supposed to be used for immediate reporting of time sensitive messages and, because of this, should be announced even if the container itself or the ARIA role attribute is added dynamically or the container exists already when the page loads. See MDN's page on Using the alert role for further discussion.

The controls for the main ARIA Live Region Display Area allow you to add content to an already existing element. But the controls immediately below allow you to add ARIA alerts to this page using three different means, documented as viable by MDN:

Load the page with an ARIA alert already in it, so that the alert text should be read on page load:

I am an already existing ARIA alert.
Dynamically add an element that contains an ARIA alert:
Add the alert role to an already existing element:

ARIA alerts get added below:

You pushed a button to add an ARIA alert to me.

Live Region Display Area Options

The controls below set options for the first live region and control its behavior.

Options

Live Region Display Area Live-Region Role

Live Region Display Area ARIA-Live Value

Live Region Display Area Live-Region Visibility

Visually Hidden
ARIA Hidden
Display None

Live Region Display Area Live-Region Attributes

ARIA Relevant
Note: It is recommended that authors should avoid aria-relevant, due to questionable utility and lack of AT support.
ARIA Atomic
ARIA Busy

Live Region Messages

Message One

Message Two

Message Three

Add Message As

Add Message To

Live Region Controls

Remove Live Region Message After

Here is a text input to type into while automatic live region announcements are being added. Use this to test to see if how user page text input affects announcement of live region changes. Ideally, live region announcements should pause (if set to polite) while the user is typing, and then resume when screen reader output is idle.

Text Input

Information About Live Region Usage and Behavior

For one-stop shopping on live regions, see MDN's ARIA Live Regions. For horse's mouth, see W3C WAI-ARIA on live regions, the aria-live property, live region roles, and live region attributes.

In order for a live region's value to be reported to a screen reading technology, the live region must be present in the DOM before content is added to it or removed from it (possible exception: role=alert). In other words, the content of a live region that is added to a page will not be reported/read until that content changes, that is, until text or element nodes are added to it or removed from it (depending on aria-relevant settings).

How should ARIA live regions be used? Live regions are for reporting page or element state changes and other notifications to a screen reading assistive technology, without changing the screen reader's current focus. In general, live regions should be separate from the currently focused container and are not meant to get screen reader/cursor focus or be browsed to. (One exception to this “not to be browsed to” rule is form validation error summary sections and other notifications that appear dynamically and stay visible until dismissed.)

Usage of live regions is a key technique for meeting WCAG 2.1, 4.1.3 Status Messages.

Some custom widgets may have a dedicated live region (often in the DOM immediately above the widget) for reporting supplemental state information for the widget. Best practice is to have no more than one or two general purpose, non-widget specific live regions on a page. Common practice is for these to be at the top or bottom of the page DOM. They are usually a div or other non-semantic container, which is non-visible but screen reader accessible. Content added to the live region is typically removed after a short period to prevent being accidentally discovered as the screen reader user browses the page.

Below is some general information about live region attributes and default behaviors.

role="alert" is supposed to assume aria-live="assertive" and aria-atomic="true".
role="status" is supposed to assume aria-live="polite" and aria-atomic="true".
role="log" is supposed to assume aria-live="polite".
role="timer" and role="marquee" are supposed to assume aria-live="off".
By default, all roles are supposed to assume aria-relevant="text additions".
Default for the aria-live attribute is supposed to be off.
Default for the aria-atomic attribute is supposed to be false.

Platform Support for Live Regions

Basic support for ARIA live regions is good across modern screen reader/platform/browser combinations. However, some attributes may not be implemented or may be interpreted differently. Testing with assistive technology should be performed to find optimal performance for a given use case.

Live region performance in AT may depend upon the user's screen reader configuation. Some screen readers may require you to turn on support for live regions. All screen readers, with the exception of Android Talkback, have settings that can control whether typing preempts reading of the live region message.

Here are the settings for disabling typing echo across supported screen readers:

NVDA: Preferences > Keyboard settings > uncheck “speech interrupt for typed characters” and “speech interrupt for Enter key”
JAWS: Settings > User > uncheck “Typing Interrupt”
VoiceOver iOS: General > Accessibility > VoiceOver > Typing feedback, set to “Nothing” (for Software and Hardware keyboards)
VoiceOver Mac: VoiceOver Utility > Verbosity, set “While typing speak” to “Nothing”

A note about Talkback: Some versions of Talkback treat live regions as aria-atomic, whether or not you set aria-atomic as an attribute and whether or not its value is “true” or “false.” What this means in practice is that in Talkback every new message that is appended to a live region will cause Talkback to announce every message currently in the region. Because of this, the ideal is to have messages persist in the live region for as short a time as is practical.

The W3C spec on the aria-live property suggests that AT should maintain a queue of “polite” messages, which should be announced at “the next graceful opportunity.” — when the current queued speech finishes, for example. However, messages designated “assertive,” such as those in an aria alert region, may remove all currently queued messages. Page authors should experiment to determine behaviors across screen reader/browser combinations.

Note on assistive technology reading speed: Minimum voice synthesis reading speed in screen readers appears to be 60 WPM. The section on speech and listening in the Wikipedia article on WPM notes that comprehension for presentations has a lower bound of 100 WPM for a “comfortable pace.” When timing is a concern for live region notifications, it is probably safe to assume screen readers are consuming live region content at around 100 WPM.