WAI-ARIA Live Regions

Tuesday, 30th January 2007

Summary

Many of the accessibility issues associated with AJAX will be solved by the live regions concept from the WAI-ARIA suite. Live regions allow assistive technologies, such as screen readers, to be informed of updates without losing their place in the content.

Author: Gez Lemon

Contents

WAI-Accessible Rich Internet Applications

Many of today's web applications exclude people with disabilities because current technologies are inadequate at relaying important information. Rich Internet Applications (RIA) are typically built using several technologies, such as HTML, CSS, and JavaScript, but often fail to provide sufficient semantics for the role and state of custom widgets to assistive technologies. Consequently, web applications can at best be difficult to use by people with disabilities, or completely inaccessible.

The W3C's Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) suite includes a roadmap outlining the requirements to make RIAs accessible. The roadmap includes a plan for developing the roles, and states and properties necessary to make RIAs accessible. Part of this roadmap defines AJAX live regions, to help ensure that updates are implemented so that they can be handled correctly by assistive technology. Live regions will greatly enhance the accessibility of AJAX-based web applications.

[Back to the contents]

Live Region Properties

AJAX live regions allows text to be spoken without giving it focus. This is good in that it means that users can be informed of multiple updates without losing their place within the content. The following attributes are defined in the States and Properties module that relate to AJAX live regions.

The atomic property

The atomic property is an optional property of live regions that can have the values true or false (default). When the region is updated, the atomic property is used to indicate if the assistive technology should present all or part of the changed region to the user. If this property is set to true, assistive technology should present the entire region as a whole; otherwise, the part of the region that changed might be announced on its own. 

<ul id="lr" aaa:atomic="true" aaa:live="polite">
  <li id="lir1">Item 1</li>
  <li id="lir2">Item 2</li>
  <li id="lir3">item 3</li>
</ul>

When a node changes, assistive technology should look for the first ancestor containing an explicitly set atomic property, and take one of the following actions depending on whether the property is set, and what value it contains if it is set:

Case 1
If none of the ancestors have explicitly set an atomic property, assistive technology only needs to present the changed node to the user.
Case 2
If the atomic property is explicitly set to false, assistive technology can stop searching up the ancestor chain, and should present only the changed node to the user.
Case 3
If the atomic property is explicitly set to true, then the assistive technology should present the entire subtree that the atomic property was set on.

The controls property

The controls property accepts IDREFS (a space-separated list of references to document-unique identifiers) that reference the elements that are controlled by the current element (the targets). 

<input id="bc" type="button" aaa:controls="lr" value="Update"/>
...
<p id="lr" aaa:live="polite">Initial Content</p>

If all of the targets effected by the controls property have their live property set to off, this could be used as a cue by assistive technology to announce that regions have been updated, without announcing the actual updates.

The describedby property

The describedby property accepts IDREFS that reference elements that describe the widget. The label element should describe the essence of what the widget does, and the describedby attribute provides extra information that might be required by some users. In the absence of describedby, the HTML label and table cell headers are considered to be the default describedby values. See XForms help or hint for more information about the rationale behind this concept. 

<p id="lbl">Label for live region</p>
...
<p id="lr" aaa:labelledby="lbl" aaa:describedby="desc" aaa:live="polite">
Initial Content
</p>
...
<p id="desc">
Long description for live region
</p>

The labelledby property

The labelledby property accepts IDREFS that point to elements that label the widget. Unlike the describedby attribute, which provides additional information, the label(s) should provide the essence of what the widget does. 

<p id="lbl">Label for live region</p>
...
<p id="lr" aaa:labelledby="lbl" aaa:live="polite">
Initial Content
</p>

The live property

The live attribute may have the values off (default), polite, assertive, or rude. The value of this attribute describes the verbosity assistive technology users can expect from an alert or live region.

off

This is the default value, and indicates that the region is not live. 

<p id="lr" aaa:live="off">Initial Content</p>
polite

This is normal operation and the default behavior for live regions. It is not necessary to respond until user completes their current activity. 

<p id="lr" aaa:live="polite">Initial Content</p>
assertive

This value is a higher priority than normal but does not necessarily interrupt the user immediately. 

<p id="lr" aaa:live="assertive">Initial Content</p>
rude

This value is the highest priority and will typically result in the user being interrupted. This may disorientate users, causing them not to continue in their current task, and so should only be used in scenarios where it is absolutely necessary, if ever. 

<p id="lr" aaa:live="rude">Initial Content</p>

The relevant property

The relevant property is optional, and used to indicate the relevant areas of change within a region. The relevant property accepts a space separated list of the following property values:

additions
Nodes are added to the DOM within the region
removals
Nodes are removed from the DOM within the region
text
Text is added or removed from the DOM
all
All of the above (additions, removals, text) apply to this region

In the absence of an explicit relevant property, the default is to assume there are text changes and additions (aaa:relevant="text additions"). 

<li id="lr" aaa:relevant="text" aaa:live="polite">Initial Content</li>

[Back to the contents]

Conformance

The WAI-ARIA States and Properties module isn't a standalone module, but intended to be used with a host language; for example, using a namespace with XHTML 1.1: 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 Strict//EN" 
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:aaa="http://www.w3.org/2005/07/aaa"
      xml:lang="en">

This means that documents that include live region properties should be served as application/xml+xhtml. When the attributes are provided declaratively in the markup, they should be prefixed by the WAI-ARIA namespace, such as aaa:live. When the attributes are inserted with script, the setAttributeNS method should be used 

objElm.setAttributeNS('http://www.w3.org/2005/07/aaa', 'atomic', 'yes');
objElm.setAttributeNS('http://www.w3.org/2005/07/aaa', 'live', 'polite');

The Future

AJAX live regions will make web applications a lot more accessible than they are today when they are supported by user agents. At the moment, the specifications are in draft status, but fortunately, the latest version of Fire Vox by Charles L. Chen already supports live region properties. Charles has created some test cases that demonstrate how live regions work with Fire Vox, and give an idea of what can be expected in the future; thanks, Charles.

[Back to the contents]

Category: Accessibility.

Comments

  1. [wai-aria-live-regions.php#comment1]

    Excellent, but until Internet Explorer supports XHTML served as application/xml+xhhtml (which I believe, as of version 7, it still doesn't), this will have no practical impact.

    Fingers crossed though. This does sound pretty cool, if potentially a little complex.

    Posted by pauldwaite on Tuesday, 30th January 2007 at 23:38:07

  2. [wai-aria-live-regions.php#comment2]

    Hi Paul,

    Excellent, but until Internet Explorer supports XHTML served as application/xml+xhhtml (which I believe, as of version 7, it still doesn't), this will have no practical impact.

    Internet Explorer 7 doesn't support content served as application/xhtml+xml, but there is still a practical use for live regions. Authors wishing to use WAI-ARIA properties and support IE7 at the same time will be forced to use content negotiation.

    It is a significant issue, but it's not a show-stopper, as people can choose a user agent that does support content delivered as application/xhtml+xml. Hopefully, Internet Explorer will choose to support this MIME type at some point.

    Posted by Gez on Wednesday, 31st January 2007 at 00:43:47

  3. [wai-aria-live-regions.php#comment3]

    I second Paul's response. JAWS and other screen readers sit on top of IE. If IE does not understand live regions then this idea won't get off the ground.

    Posted by Danny on Wednesday, 31st January 2007 at 12:51:51

  4. [wai-aria-live-regions.php#comment4]

    JAWS and other screen readers sit on top of IE. If IE does not understand live regions then this idea won't get off the ground.

    Screen readers do work with other browsers. At this point in time, it's true that most screen readers tend to work better with IE, but that situation is changing.

    Given the rise in Rich Internet Applications over the past couple of years, the need for technologies like AJAX to work properly with screen readers and other assistive technologies is getting greater. At the moment, WAI-ARIA is only a draft, but by the time it is released, browsers like Firefox will fully support it. Screen readers will be able to provide a far better experience for their users if they work well with browsers that support WAI-ARIA.

    Posted by Gez on Wednesday, 31st January 2007 at 17:59:27

  5. [wai-aria-live-regions.php#comment5]

    The IE issue is a chicken and egg problem.

    The leaders in the accessibility field need to push this technology or provide an alternative solution. I suggest, either provide an alternative that works in IE, or start using the technology so that we can generate interest which will allow everyone to try it. The generated buzz can influence either Microsoft or the AT vendors to support the technology.

    We can also work to get this into open source Javascript toolkits, etc. For example, it can be put into an accessible chat widget for Dojo (a student named Peter Thiessen at University of Toronto plans to work on that). Once it's in these toolkits, ARIA can spread quite far.

    Posted by Aaron Leventhal on Thursday, 1st February 2007 at 15:50:49

  6. [wai-aria-live-regions.php#comment6]

    I was just scratching my head as to what RIA's were the other day, Thanks, and great content on this blog! cheers

    Posted by Anthony on Sunday, 4th February 2007 at 19:32:35

Comments are closed for this entry.