Screen Reader Support for ARIA Live Regions
Rich Internet Application (RIA) websites encourage people to generate content, collaborate online and make choices about the information they receive. Unsurprisingly, RIA websites can represent a considerable challenge for screen reader users. The WAI’s Accessible Rich Internet Applications (ARIA)is an emerging standard that aims to bridge the gap between RIA websites and screen reading technology.
ARIA Live Regions
Amongst other things, the ARIA roadmap defines live regions. Live regions are areas of a web page that allow updates to be announced, without the screen reader focusing on that part of the page.
The aim is to automatically provide screen reader users with appropriate information each time a live region of a page is updated. Live regions should help make many rich internet aplications more accessible to screen reader users.
There are three different types of live region:
- Polite.
- Assertive.
- *Rude.
*As noted in the comments, the rude live region type has been removed from the ARIA specification.
The following tests were carried out independently on different virtual machines, each running a variation of Windows XP. The test cases were sourced from Charles Chen’s AJAX Accessibility simple test cases.
Polite Live Regions
Live regions that are marked as polite should cause the screen reader to announce the update as soon as it’s finished its current activity
. For example, an update would be announced as soon as you finished reading the current line of text, or finished reading the page with a Say All command.
Polite Screen Reader Support
Test case: live=”polite”
| Screen Reader | IE8 | FF3.x | Notes |
|---|---|---|---|
| Hal 11 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
| Jaws 10.x | Yes | Yes | Updates are announced automatically at the end of the current activity, subsequent updates are announced until a further activity is invoked by the screen reader |
| NVDA 0.6P3.2 | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in FF3.x. The information cannot be determined by accessing the live region in IE8 |
| SA To Go | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in IE8 The information cannot be determined by accessing the live region in FF3.x |
| Window Eyes 7.01 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
Assertive Live Regions
Live regions marked as assertive should cause the screen reader to announce the update as soon as the current activity is finished, or perhaps sooner depending on the current activity.
For example an update would be announced at the end of a short activity such as reading a line of text, but would interupt a longer activity such as reading the page with a Say All command.
Assertive Screen Reader Support
Test case: live=”assertive”
| Screen Reader | IE8 | FF3.x | Notes |
|---|---|---|---|
| Hal 11 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
| Jaws 10.x | Yes | Yes | Updates are announced automatically at the end of the current activity, subsequent updates are announced until a further activity is invoked by the screen reader |
| NVDA 0.6P3.2 | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in FF3.x. The information cannot be determined by accessing the live region in IE8 |
| SA To Go | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in IE8 The information cannot be determined by accessing the live region in FF3.x |
| Window Eyes 7.01 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
Rude Live Regions
Live regions marked as rude should cause the screen reader to announce the update immediately. For example it would overide any activity including reading a line of text or reading a page with a Say All command.
Rude Screen Reader Support
Test case: live=”rude”
| Screen Reader | IE8 | FF3.x | Notes |
|---|---|---|---|
| Hal 11 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
| Jaws 10.x | Yes | Yes | Updates are announced automatically at the end of the current activity, subsequent updates are announced until a further activity is invoked by the screen reader |
| NVDA 0.6P3.2 | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in FF3.x. The live region itself cannot be accessed in IE8 |
| SA To Go | No | No | Updates are not announced automatically, although the information can be determined by accessing the live region itself in IE8 The information cannot be determined by accessing the live region in FF3.x |
| Window Eyes 7.01 | No | No | Updates are not announced automatically, and are not available when the live region is accessed |
Screen Reader Experience
Given proper support in the screen reader, the experience of using a web page with polite or assertive live regions is good. The balance between interacting with the page, and being kept up to date with the activity in the live region, works well.
The experience of using a page with rude live regions is quite different. It’s disruptive, irritating and frustrating, even when the interupt is set to long intervals. It’s
impossible to fluidly access any other content on the page,
because the updates are relentless in their interuption.
This entry was posted on June 1st, 2009 and filed under Accessibility, Screen Readers, Web Development.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
June 1st, 2009 at 10:39 pm
I am suspect of the testing as its undetermined who is the tester and if the comments are just being offered by Tech Support by each manufacturer. I am further suspicious that the author of this blog in attempts to reach the different AT Manufacturers possibly did not get responses to the their queries causing by default a negative response. So truly how valid is this testing?
June 1st, 2009 at 11:07 pm
Interesting question. I carried out the testing independently myself, without contacting the screen reader manufacturers.
Testing was done on three separate machines, using Charles Chen’s excellent test cases. Testing is rarely infallible, but the results appeared consistent over several iterations.
I’ll update the post to make this more apparent. If you’ve done any testing in this area yourself though, I’d be interested to hear of it.
June 1st, 2009 at 11:41 pm
NVDA does support additions for polite and rude live regions for “show” events. For example, if a container is marked as live and a div is appended to the container or a div inside the container becomes visible, it will be announced. Assertive live regions are currently treated like polite live regions. Obviously, this is a grievously incomplete implementation and we do have plans to fix it, but I thought it worth noting that we do have some support nevertheless.
Btw, to avoid confusion, it’d be great if you could be more specific about the version of NVDA used. NVDA 0.6 does not yet exist. The latest official release is NVDA 0.6p3.2 (which is a preview release well before 0.6).
June 2nd, 2009 at 3:26 pm
In the case of Window-Eyes, is this a beta of 7.1 or is it 7.01, the current version? I realize that the user wouldn’t know that an update had occured, but I assume that if she does Insert-backslash to refresh the screen (which refreshes the browse buffer) the information would get updated. I like the names for these types of regions, and hope that “rude” regions don’t get created very often.
June 2nd, 2009 at 3:40 pm
I think that live=”rude” isn´t already part of WAI-ARIA specification, see http://www.w3.org/WAI/PF/aria/#aria-live. Live has only three values – off, polite, assertive.
June 2nd, 2009 at 7:03 pm
Thanks James & Lloyd. I’ve updated the screen reader versions in the tables above.
June 2nd, 2009 at 7:11 pm
Radek, what makes this really interesting is that now we’ve got a situation where some screen readers support a property value that’s no longer part of the spec.
June 8th, 2009 at 12:04 pm
Only just come across this. Was there any particular reason why Hal and Thunder weren’t included in the test?
June 9th, 2009 at 7:19 pm
For the moment, my Hal demo has run out. I often wish that Dolphin opted for a 30/40 minute demo in the style of Jaws or Window Eyes, it would make testing during development much easier.
I’d discounted Thunder because of its reliance on WebbIE, which didn’t support JavaScript/AJAX last time I checked… Looking at the blurb, this still seems to be true, but I’ll download a copy and give it a whirl all the same.
If you’re able to contribute any results from Hal, I’d be glad to include them here though. Thanks.
June 28th, 2009 at 10:46 pm
Updated the post to include results from Hal v11.