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.

10 comments on “Screen Reader Support for ARIA Live Regions”

Skip to Post a comment
  1. Comment by Stephen Guerra

    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?

  2. Comment by Tink

    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.

  3. Comment by James Teh

    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).

  4. Comment by Lloyd Rasmussen

    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.

  5. Comment by Tink

    Thanks James & Lloyd. I’ve updated the screen reader versions in the tables above.

  6. Comment by Tink

    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.

  7. Comment by Steve Griffiths

    Only just come across this. Was there any particular reason why Hal and Thunder weren’t included in the test?

  8. Comment by Tink

    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.

  9. Comment by Tink

    Updated the post to include results from Hal v11.

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.