An ARIA live region is a simple mechanism for notifying screen readers when content is updated on the page. Despite the obvious Accessible User Experience (AUX) benefits that live regions bring, screen reader support is disappointingly inconsistent.
To recap: A screen reader can only focus on one part of
the page at a time. If something changes elsewhere on the page, there’s a good chance a screen reader user will be oblivious to it. When the update takes place within an ARIA live region, a screen reader is automatically notified (wherever its focus is at the time), and it conveys the updated content to the user.
aria-live attribute
The aria-live attribute identifies an element as a live region. It takes three possible values:
- Off (no notification).
- Polite (screen reader notifies user once current task is complete).
- Assertive (screen reader interrupts current task to notify user).
aria-live test case
<head>
...
<script>
var result1 = 0;
function update1() {
result1 = result1 + 1;
document.getElementById("result1").innerHTML=result1;
}
</script>
</head>
<body>
...
<div id="result1" aria-live="polite"></div>
<div>
<button onclick="update1();">Update result 1</button>
</div>
...
</body>
Browser support for aria-live
Browser support for the aria-live attribute is good. All three of the browsers commonly used by screen reader users (Firefox, Internet Explorer and Safari) expose ARIA live regions through their accessibility APIs.
Screen reader support for aria-live
Screen reader support is mixed at best, even when using a simple test case like the one above.
For the common use case of triggering a live region update based on activation of a standard control, Jaws 15 fully supports the ARIA live region in both Firefox 27 and Internet Explorer 11. NVDA 2014.1 supports the aria-live attribute in Firefox, but not Internet Explorer.
Window Eyes 8.4 only supports the ARIA live region in Firefox when the aria-live attribute is set to assertive. It doesn’t support it in Internet Explorer.
VoiceOver in Safari 7.0.2 (OSX) fully supports the ARIA live region, but in Safari 7.0 (iOS) the test case only worked when the live region was assertive.
status role
The status role indicates that the element contains advisory information that the user should be made aware of, but which isn’t important enough to warrant an alert. The status role is a form of live region, so an element with the status role applied should not receive focus.
status role test case
<head>
...
<script>
var result1 = 0;
function update1() {
result1 = result1 + 1;
document.getElementById("result1").innerHTML=result1;
}
</script>
</head>
<body>
...
<div id="result1" role="status" aria-live="polite"></div>
<div>
<button onclick="update1();">Update result 1</button>
</div>
...
</body>Browser support for status role
Browser support for the status role is also good, with Firefox, Internet Explorer and Safari all exposing ARIA live regions through their accessibility APIs.
Screen reader support with status role
From the screen reader point of view, adding the status role forces Window Eyes to recognise the polite ARIA live region in Firefox. However it doesn’t make any difference to VoiceOver in Safari (iOS), or Window Eyes or NVDA in Internet Explorer.
With these simple test cases, the most widely supported combination is to use aria-live=”assertive” with role=”status” to create the ARIA live region. The only two browser/screen reader combinations that remain unsupportive are NVDA and Window Eyes in Internet Explorer.
A word or two of caution though:
- An assertive ARIA live region isn’t always desireable. Remember the notification will interrupt the screen reader from its current task, so use aria-live=”assertive” with care.
- The test cases used here are extraordinarily simple. When ARIA live regions are used in the wild (in more complex scenarios), screen reader behaviour is known to become more erratic.
Comments
You have found an instance of a bug where polite live regions don’t work as expected, but it is inaccurate and misleading to say that only assertive live regions are supported. For example, if you put a timeout on that live region update, it works. It you trigger this via some other script instead of a button press, it works. The bug you’ve found is much more specific that your blanket statement, and polite live regions work as expected in most cases. Please file a bug report next time.
Thanks James. I’ve updated the post to clarify the context – that the test cases represent the common scenario of triggering a live region update based on activation of a standard control.