mozilla

Revision 67170 of WAI ARIA Live Regions

  • Revision slug: AJAX/WAI_ARIA_Live_Regions
  • Revision title: WAI ARIA Live Regions
  • Revision id: 67170
  • Created:
  • Creator: Tuukka
  • Is current revision? No
  • Comment /* The Solution: Live Region Markup and Intuitive User Controls */ s/One/Once/ the markup is stable

Revision Content

Report on the WAI ARIA Markup for AJAX Live Regions

Major Contributors

Charles L. Chen

Aaron Leventhal

The Challenge: Making Live Regions Accessible

Asynchronous JavaScript and XML (AJAX) has recently received a great amount of attention, and the number of websites using or planning to use the technique is increasing. AJAX enables web developers to easily create sites that change areas of their content in response to user actions (such as in webmail applications) or real world changes (such as updates of stock prices).

Screen readers, which utilize text-to-speech and Braille displays, cannot present users with as much information at the same time as visual displays, and this creates challenges which need to be addressed before AJAX can be accessible.

Without having information to help know which changes to speak, the tendency is to either annoy users by speaking everything which changes, or to underinform users by speaking too little. Historically, assistive technologies could not do any better than that because they did not know much about the live changes. The could receive events about where and when the changes occurred, but had a dearth of information about the relative importance to these events. Ultimately, the user experience should provide enough information for users without annoying them with extra information that they do not need.

Breaking down the problem, some of the specific challenges are:

  • How should assistive technologies present live regions to users?
  • What should happen if a live region is updated while the user is reading another area of the page?
  • What should happen if two live regions are updated at the same time?
  • What information do developers need to provide about live regions, to enable a quality experience for assistive technology users

The Solution: Live Region Markup and Intuitive User Controls

The proposed WAI-ARIA markup for AJAX live regions is designed to address these issues. Live region markup allows web page authors to specify when and how live changes to specific areas of a web page should be spoken or shown on a Braille display by a screen reader. However, the markup is not device-specific. It uses concepts such as politeness levels to indicate strategies for interruption. The same markup may also be useful for screen magnifiers or devices with small displays, which can use the information to decide what to show on the limited available screen real estate.

It's important to remember that none of this takes away the final decision-making role of the user. If the user does not want to hear something, they can set background changes to "quiet" or "off". Likewise, if they are missing some updates, there can be a variety of "verbose" settings.

That said, many users do not change settings, and will not alter the verbosity of live regions. Therefore, the live region markup is crucial, as developers need to be given the capability to provide the most optimal default behavior possible.

For now, the priority is to get final decisions on the live region markup. Once the markup is stable, we're planning to experiment more in-depth to find not only the optimal use of that markup, but also define a base set of user interface features and settings that give the user power without requiring them to use them, or creating unnecessary complexity.

What this Report Provides

This report details Charles L. Chen's and Aaron Leventhal's findings on using the live region markup, along with links to test cases and information on the current state of Fire Vox support. The report also describes remaining issues and a set of recommendations for the live region standardization effort, to address those issues.

Potential readers of this report:

  • Developers interested in affecting the emerging standard or the user experience: live region markup is still in flux.
  • End-users interested in helping shape the user experience: there are many possibilities regarding how users will interact with, and ultimately control, live regions.
  • Assistive technology developers: this report is evolving to include more recommendations for assistive technology vendors.
  • (Not) web authors: this report has not yet evolved into documentation for web authors. Practically speaking, live region markup is not yet widely supported. It does not hurt anything to add live region markup to pages, but it also won't get you much mileage from it at this point. However, this report should eventually evolve into documentation for web developers, so please check back after the release of Firefox 3.

In general, any and all feedback is welcome (and encouraged) on the mailing list.

Live Region Attributes and Test Cases

Please see http://accessibleajax.clcworld.net for the test cases.

The test cases currently work only with Fire Vox. See the Status section for information on the current state of support in Fire Vox.

Please note that Fire Vox does not yet work with ARIA widgets -- the core of the ARIA specification.

In addition, desktop screen readers such as JAWS, Window-Eyes, LSR and Orca do not yet utilize live region markup. They will be able to do so in Firefox 3 test builds by using IAccessible2 and AT-SPI object attributes.

live=POLITENESS_SETTING

live=POLITENESS_SETTING is used to set the priority with which AT should treat updates to live regions. These are only the default priority settings for live regions; AT may provide ways for users to override/change these priority settings.

Setting Description Example
live="off" This is the default. Any updates made to it should not be announced to the user. live="off" would be a sensible setting for things that update very frequently such as timers that change every second.

Simple Test Case for live="off"

live="polite" The region is live, but updates made to it should only be announced if the user is not currently doing anything. live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines.

Simple Test Case for live="polite"

live="assertive" The region is live. Updates made to it are important enough to be announced to the user as soon as possible, but it is not necessary to immediately interrupt the user. live="assertive" should be used if there is information that a user should know about right away, for example, warning messages in a form that does validation on the fly.

Simple Test Case for live="assertive"

live="rude" The region is live. Updates to it are extremely important. In fact, the updates are so important that the user must be interrupted immediately. live="rude" should be used sparingly and only with great consideration as it can be very annoying to users.

Simple Test Case for live="rude"

controls=[IDLIST]

controls={{mediawiki.external('IDLIST')}} is used to associate a control with the regions that it controls.

Setting Description Example
controls="myRegion1_IDREF myRegion2_IDREF etcEtcEtc_IDREF" controls={{mediawiki.external('IDLIST')}} associates an element with one or more regions that it controls. If it controls more than one region, the regions are separated by a space. When a change to one of these regions occurs because of a user action on the control, then the change should be announced immediately to let users know that their action did have an effect.

Simple Test Case for controls=[IDLIST]

atomic=BOOLEAN

atomic=BOOLEAN is used to set whether or not the AT should present the live region as a whole. This is only the default setting for the live region; AT may provide ways for users to override whether or not the live region is treated as atomic.

Setting Description Example
atomic="false" This is the default. It means that when there is a change in the region, that change can be presented on its own; the AT should not present the entire region. atomic="false" is generally a good idea as it presents users with only changes and does not cause them to hear repetitive information that has not changed. However, web developers should take care that the changed information, when presented by itself, can still be understood and contextualized by the user.

Simple Test Case for atomic="false"

atomic="true" If atomic is set to "true", it means that the region must be presented as a whole; when there is a change, the AT should present the entire region, not just the change. atomic="true" can make it harder for users to understand changes as the changed areas are not presented independently. atomic="true" can also be annoying as it can force users to listen to repetitive information that has not changed. However, atomic="true" is necessary in cases where the change, when presented by itself, cannot be understood and contexualized by the user.

Simple Test Case for atomic="true"

labelledby=[IDLIST]

labelledby={{mediawiki.external('IDLIST')}} is used to associate a region with its labels.

Setting Description Example
labelledby="myLabel1_IDREF myLabel2_IDREF etcEtcEtc_IDREF" labelledby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as labels with the live region that they label. These elements do not have to be HTML <label> elements. If there is more than one label, the labels are separated by a space. The labels should be presented to the user when there is a change to the region that they are associated with.

Simple Test Case for labelledby=[IDLIST]

describedby=[IDLIST]

describedby={{mediawiki.external('IDLIST')}} is used to associate a region with its descriptions.

Setting Description Example
describedby="myDisc1_IDREF myDisc2_IDREF etcEtcEtc_IDREF" describedby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as descriptions with live region that they describe. If there is more than one description, the descriptions are separated by a space. The descriptions should be not be presented to the user when there is a change to the region that they are associated with as they are too lengthy and would annoy the user; however, there should be an easy way for users to find the description for a particular region when they want to find out more about the region.

Simple Test Case for describedby=[IDLIST]

relevant=[LIST_OF_CHANGES]

relevant={{mediawiki.external('LIST_OF_CHANGES')}} is used to set what types of changes are relevant to a live region. Multiple types of changes can be listed as relevant; the types are separated by a space. The default is relevant="additions text".

Setting Description Example
relevant="additions" relevant="additions" states that the insertion of nodes to the live region should be considered relevant.

Simple Test Case for relevant="additions"

relevant="removals" relevant="removals" states that the removal of nodes to the live region should be considered relevant.

Simple Test Case for relevant="removals"

relevant="text" relevant="text" states that changes to the text of nodes that already exist in the live region should be considered relevant.

Simple Test Case for relevant="text"

relevant="all" relevant="all" states that all changes to the live region should be considered relevant. This is the same as doing relevant="additions removals text".

Simple Test Case for relevant="all"

Current Status of Fire Vox Support

Property What works Improvements needed
live=POLITENESS_SETTING

Fire Vox supports the politeness setting.

  • Off events are not announced.
  • Polite events are queued.
  • Assertive events will cause earlier polite events to be discarded from the queue but not earlier assertive events.
  • Rude events cause earlier polite and assertive events to be discarded from the queue.

If there are too many events in the queue, Fire Vox tries to keep up as best it can with the hope that the event frequency will decrease later on - after the number of events passes a threshold, the oldest events are automatically dropped to make room for newer events. Fire Vox tries to maintain chronological consistency. Events are announced in the order in which they were fired.

This is the reason that less polite events will cancel events that are more polite; chronological consistency is violated if a user hears a polite event after having first heard a rude event which was fired after the polite event.

In addition, since most webpages are not currently marked up with WAI-ARIA properties, there is an internal value of "unknown". Under the default mode for live region announcements, Fire Vox will treat "unknown" as a politeness setting between "off" and "polite"; "unknown" events will be announced, but they can be discarded by "polite" events. Under the tagged mode for live region announcements, Fire Vox will treat "unknown" as if it were "off".

Simple Test Case for live= is missing ("unknown")

None
controls={{mediawiki.external('IDLIST')}} This property is not ideal; a region can be changed both by a control or a world event.

There needs to be some way to determine causality in order for AT to know whether or not it should treat a change to a region as a result of a user action on a control.

atomic=BOOLEAN Fire Vox supports the atomic property. If a region is marked as atomic, the entire region will be read out when any of its subregions are modified. None
labelledby={{mediawiki.external('IDLIST')}} This should work, but support for it has not been implemented in Fire Vox yet. None yet; however, it should be stressed to web developers that the ARIA properties will override HTML elements. Thus if a label element is used with a "for=" that points to a live region which has "labelledby=" but does not include the label element in its IDLIST, then that label element will NOT be considered a label for that live region.
describedby={{mediawiki.external('IDLIST')}} This should work, but support for it has not been implemented in Fire Vox yet. None yet.
relevant={{mediawiki.external('LIST_OF_CHANGES')}} Fire Vox supports the relevant setting. Any event which is deemed to not be relevant automatically have their politeness level set to off and are not announced. None

Issues and Proposed Solutions

Issue Problem Description Proposed Solution
1. Causality The AT will need some way to know whether a control is really controlling a live region or if the onChange event for a particular control and an update to a live region that it controls is merely a coincidence (imagine a user tabbing out of the input blank after having typed something but without pressing enter and having some other user send a message at about the same time - both events happened, but the change in the input blank was not the cause for the new message that appeared in the blank). The browser can trace through the stack of JavaScript function calls that resulted in a change to the page to see if that change was caused by a JavaScript function that was triggered by a user action (such as clicking on a button). This cannot determine causality for every case as it is possible that the user action causes an HTTP request to be made to the server and the response handler for that request then causes the change; such a change would appear to be coming from a world event rather than a user action. However, knowing the source of a change could be helpful in disambiguating the two cases in other scenarios. In addition, for situations where a change can be caused by either user interaction or a world event, the recommendation is to not specify that live region as something that the control is controlling.
2. Interim updates If an update is polite, it is unclear whether or not it should cause the earlier updates for the same region in the queue to be discarded. In the case of updates made to a live region that displays the most recent play made in a game, polite events about the play just made should not cause earlier events to be discarded; to get a full picture of how the game is unfolding, one must know what the earlier plays were. So in this case, the user should be allowed to lag behind while many plays are being made and then catch up when there is a time out or some other pause in the action. However, in the case of updates to a stock price, the current price is what matters and its price three or two or one minute ago is of no interest; thus, polite updates to the stock price should cause earlier events to be discarded.

Since understanding the purpose behind the updates is crucial to determining whether or not earlier events should be discarded, web developers should have the ability to set the default for whether the AT should treat interim events for a particular live region as relevant or if only the final announcement-time content is relevant.

Adding "interim" as a keyword for relevant would solve this problem. If "interim" is added, then all relevant events to the live region which have happened since the last announcement will be announced. However, if "interim" is not specified, then only the events which are currently reflected in the page will be announced.

This means that without "interim", if the events queue have a node being added and then having its text changed, the announcement will only announce the current state of that node's text - the original text that it had when it was first added will not be announced since that is not there anymore. If "interim" had been used in this case, then there would have been an announcement that the node was added which gives its original text, followed by another announcement that the node was updated which gives its current text.

Note that interim's control over whether later events cause earlier events to be discarded is orthogonal to what is controlled by live=POLITENESS_SETTING. Assertive and rude events will still discard earlier events which are more polite than themselves, regardless of the interim setting. Whether a polite event will discard earlier polite events for the same region depends on the interim setting; a polite event will never discard earlier polite events from other regions.

Although adding the value of "interim" to the relevant property is still being discussed, Fire Vox already supports it.

Simple Test Case for relevant="interim additions text"

3. Batching events Sometimes, a web developer may make a series of related changes in quick succession. Announcing them as separate events would confuse the user, and the time it takes for the changes to happen is dependent on the user's machine and the network. The web developer should have a way to specify whether a live region is busy. Adding busy="BOOLEAN" would solve this problem. busy="true" means that the live region is in the middle of a set of changes and that no events should be announced yet. busy="false" means that the live region is done with its set of updates. The default is busy="false"; thus, if nothing is specified, then by default, events to live regions are ready to be announced when they happen.
4. Setting a threshold on event frequency With events that come from world events, the frequency of the events could vary dramatically in some cases. Too many events at once would make it very difficult for AT users to keep up and could lead to cognitive overload. In most real world situations where there can suddenly be a string of updates, it is the same set of information that is being updated. Good examples would be stocks and game stats. In both of these cases, interim should not be set as only the current values matter. As a result, users should not fall too far behind. To address the problem of cognitive overload (especially if the user is multitasking), AT should provide a patience setting that allows users to restrict updates to only once every X seconds.
5. Higher level abstractions for web developers Having to specify the live region properties for each widget on a page can be tedious; it also increases the chances for human error. Web developers should be able to use WAI-ARIA Roles as a higher level abstraction for specifying the live region properties. Roles such as "log", "alert", "progressbar", etc. should have a default set of live region properties associated with them in the WAI-ARIA standard. These default properties can be overridden by explicitly specifying them.
6. Browser support Browsers only give AT relatively low level information. For example, when the textContent of an HTML node is changed, the DOM mutation events that are fired are "DOMNodeRemoved" followed by "DOMNodeInserted". It is currently up to the AT to piece together these two bits of information and deduce that what has really happened is a text change event. AT vendors need more information and better abstractions from browsers. In the case of the textContent changing and two separate events being fired, the browser can clearly tell that it is a textContent change rather than an old element being removed from the page and then a new element being added. That information should be given to the AT directly since that will be more accurate and less computationally expensive than having the AT try to figure all of this out for itself.
7. Style changes are not fired as DOM events If we developers dynamically show/hide elements by changing the style on the elements, ATs that look at the DOM will not be able to detect when such a change has occurred since there is no DOM event fired. This is a problem for elements on the page which from a user's point of view, are essentially added or removed via changes to the display or visibility property. The DOM spec should provide for the firing of events when style has been changed.

To Be Done

  • Recommendations for authors
  • Description of logic for AT vendors
  • List end-user features (both implemented and planned)

Revision Source

<h2 name="Report_on_the_WAI_ARIA_Markup_for_AJAX_Live_Regions">Report on the WAI ARIA Markup for AJAX Live Regions</h2>
<h3 name="Major_Contributors">Major Contributors</h3>
<p>Charles L. Chen
</p><p>Aaron Leventhal
</p>
<h3 name="The_Challenge:_Making_Live_Regions_Accessible">The Challenge: Making Live Regions Accessible</h3>
<p>Asynchronous JavaScript and XML (AJAX) has recently received a great amount of attention, and the number of websites using or planning to use the technique is increasing. AJAX enables web developers to easily create sites that change areas of their content in response to user actions (such as in webmail applications) or real world changes (such as updates of stock prices).
</p><p>Screen readers, which utilize text-to-speech and Braille displays, cannot present users with as much information at the same time as visual displays, and this creates challenges which need to be addressed before AJAX can be accessible.
</p><p>Without having information to help know which changes to speak, the tendency is to either annoy users by speaking everything which changes, or to underinform users  by speaking too little. Historically, assistive technologies could not do any better than that because they did not know much about the live changes. The could receive events about where and when the changes occurred, but had a dearth of information about the relative importance to these events. Ultimately, the user experience should provide enough information for users without annoying them with extra information that they do not need.
</p><p>Breaking down the problem, some of the specific challenges are:
</p>
<ul><li> How should assistive technologies present live regions to users?
</li><li> What should happen if a live region is updated while the user is reading another area of the page?
</li><li> What should happen if two live regions are updated at the same time?
</li><li> What information do developers need to provide about live regions, to enable a quality experience for assistive technology users
</li></ul>
<h3 name="The_Solution:_Live_Region_Markup_and_Intuitive_User_Controls">The Solution: Live Region Markup and Intuitive User Controls</h3>
<p>The <a class="external" href="http://www.w3.org/TR/aria-state/">proposed WAI-ARIA markup for AJAX live regions</a> is designed to address these issues. Live region markup allows web page authors to specify when and how live changes to specific areas of a web page should be spoken or shown on a Braille display by a screen reader. However, the markup is not device-specific. It uses concepts such as politeness levels to indicate strategies for interruption. The same markup may also be useful for screen magnifiers or devices with small displays, which can use the information to decide what to show on the limited available screen real estate.
</p><p>It's important to remember that none of this takes away the final decision-making role of the user. If the user does not want to hear something, they can set background changes to "quiet" or "off". Likewise, if they are missing some updates, there can be a variety of "verbose" settings.
</p><p>That said, many users do not change settings, and will not alter the verbosity of live regions. Therefore, the live region markup is crucial, as developers need to be given the capability to provide the most optimal default behavior possible.
</p><p>For now, the priority is to get final decisions on the live region markup. Once the markup is stable, we're planning to experiment more in-depth to find not only the optimal use of that markup, but also define a base set of user interface features and settings that give the user power without requiring them to use them, or creating unnecessary complexity.
</p>
<h3 name="What_this_Report_Provides">What this Report Provides</h3>
<p>This report details Charles L. Chen's and Aaron Leventhal's findings on using the live region markup, along with links to test cases and information on the current state of Fire Vox support. The report also describes remaining issues and a set of recommendations for the live region standardization effort, to address those issues.
</p><p>Potential readers of this report:
</p>
<ul><li> Developers interested in affecting the emerging standard or the user experience: live region markup is still in flux.
</li><li> End-users interested in helping shape the user experience: there are many possibilities regarding how users will interact with, and ultimately control, live regions.
</li><li> Assistive technology developers: this report is evolving to include more recommendations for assistive technology vendors.
</li><li> (Not) web authors: this report has not yet evolved into documentation for web authors. Practically speaking, live region markup is not yet widely supported. It does not hurt anything to add live region markup to pages, but it also won't get you much mileage from it at this point. However, this report should eventually evolve into documentation for web developers, so please check back after the release of Firefox 3.
</li></ul>
<p>In general, any and all feedback is welcome (and encouraged) on the <a class="external" href="http://www.mozilla.org/access/#community">mailing list</a>.
</p>
<h3 name="Live_Region_Attributes_and_Test_Cases">Live Region Attributes and Test Cases</h3>
<p><a class="external" href="http://accessibleajax.clcworld.net">Please see http://accessibleajax.clcworld.net for the test cases.</a>
</p><p>The test cases currently work only with <a class="external" href="http://www.firevox.clcworld.net/downloads.html">Fire Vox</a>. See the Status section for information on the current state of support in Fire Vox.
</p><p>Please note that Fire Vox does not yet work with <a class="external" href="http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications">ARIA widgets</a> -- the core of the ARIA specification.
</p><p>In addition, desktop screen readers such as JAWS, Window-Eyes, LSR and Orca do not yet utilize live region markup. They will be able to do so in <a class="external" href="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/">Firefox 3 test builds</a> by using IAccessible2 and AT-SPI object attributes.
</p>
<h4 name="live.3DPOLITENESS_SETTING"><a class="external" href="http://www.w3.org/TR/aria-state/#live">live=POLITENESS_SETTING</a></h4>
<p>live=POLITENESS_SETTING is used to set the priority with which AT should treat updates to live regions. These are only the default priority settings for live regions; AT may provide ways for users to override/change these priority settings.
</p>
<table border="1" summary="live=POLITENESS_SETTING">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> live="off"
</td><td> This is the default. Any updates made to it should not be announced to the user. live="off" would be a sensible setting for things that update very frequently such as timers that change every second.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_off.htm">Simple Test Case for live="off"</a>
</p>
</td></tr>
<tr>
<td> live="polite"
</td><td> The region is live, but updates made to it should only be announced if the user is not currently doing anything. live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_polite.htm">Simple Test Case for live="polite"</a>
</p>
</td></tr>
<tr>
<td> live="assertive"
</td><td> The region is live. Updates made to it are important enough to be announced to the user as soon as possible, but it is not necessary to immediately interrupt the user. live="assertive" should be used if there is information that a user should know about right away, for example, warning messages in a form that does validation on the fly.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_assertive.htm">Simple Test Case for live="assertive"</a>
</p>
</td></tr>
<tr>
<td> live="rude"
</td><td> The region is live. Updates to it are extremely important. In fact, the updates are so important that the user must be interrupted immediately. live="rude" should be used sparingly and only with great consideration as it can be very annoying to users.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_rude.htm">Simple Test Case for live="rude"</a>
</p>
</td></tr></tbody></table>
<h4 name="controls.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/TR/aria-state/#controls">controls=[IDLIST</a>]</h4>
<p>controls={{mediawiki.external('IDLIST')}} is used to associate a control with the regions that it controls.
</p>
<table border="1" summary="controls=[IDLIST]">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> controls="myRegion1_IDREF myRegion2_IDREF etcEtcEtc_IDREF"
</td><td> controls={{mediawiki.external('IDLIST')}} associates an element with one or more regions that it controls. If it controls more than one region, the regions are separated by a space. When a change to one of these regions occurs because of a user action on the control, then the change should be announced immediately to let users know that their action did have an effect.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/controls.htm">Simple Test Case for controls=[IDLIST</a>]
</p>
</td></tr></tbody></table>
<h4 name="atomic.3DBOOLEAN"><a class="external" href="http://www.w3.org/TR/aria-state/#atomic">atomic=BOOLEAN</a></h4>
<p>atomic=BOOLEAN is used to set whether or not the AT should present the live region as a whole. This is only the default setting for the live region; AT may provide ways for users to override whether or not the live region is treated as atomic.
</p>
<table border="1" summary="atomic=BOOLEAN">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> atomic="false"
</td><td> This is the default. It means that when there is a change in the region, that change can be presented on its own; the AT should not present the entire region. atomic="false" is generally a good idea as it presents users with only changes and does not cause them to hear repetitive information that has not changed. However, web developers should take care that the changed information, when presented by itself, can still be understood and contextualized by the user.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_false.htm">Simple Test Case for atomic="false"</a>
</p>
</td></tr>
<tr>
<td> atomic="true"
</td><td> If atomic is set to "true", it means that the region must be presented as a whole; when there is a change, the AT should present the entire region, not just the change. atomic="true" can make it harder for users to understand changes as the changed areas are not presented independently. atomic="true" can also be annoying as it can force users to listen to repetitive information that has not changed. However, atomic="true" is necessary in cases where the change, when presented by itself, cannot be understood and contexualized by the user.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_true.htm">Simple Test Case for atomic="true"</a>
</p>
</td></tr></tbody></table>
<h4 name="labelledby.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/TR/aria-state/#labelledby">labelledby=[IDLIST</a>]</h4>
<p>labelledby={{mediawiki.external('IDLIST')}} is used to associate a region with its labels.
</p>
<table border="1" summary="labelledby=[IDLIST]">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> labelledby="myLabel1_IDREF myLabel2_IDREF etcEtcEtc_IDREF"
</td><td> labelledby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as labels with the live region that they label. These elements do not have to be HTML &lt;label&gt; elements. If there is more than one label, the labels are separated by a space. The labels should be presented to the user when there is a change to the region that they are associated with.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/labelledby.htm">Simple Test Case for labelledby=[IDLIST</a>]
</p>
</td></tr></tbody></table>
<h4 name="describedby.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/TR/aria-state/#describedby">describedby=[IDLIST</a>]</h4>
<p>describedby={{mediawiki.external('IDLIST')}} is used to associate a region with its descriptions.
</p>
<table border="1" summary="describedby=[IDLIST]">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> describedby="myDisc1_IDREF myDisc2_IDREF etcEtcEtc_IDREF"
</td><td> describedby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as descriptions with live region that they describe. If there is more than one description, the descriptions are separated by a space. The descriptions should be not be presented to the user when there is a change to the region that they are associated with as they are too lengthy and would annoy the user; however, there should be an easy way for users to find the description for a particular region when they want to find out more about the region.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/describedby.htm">Simple Test Case for describedby=[IDLIST</a>]
</p>
</td></tr></tbody></table>
<h4 name="relevant.3D.5BLIST_OF_CHANGES.5D"><a class="external" href="http://www.w3.org/TR/aria-state/#relevant">relevant=[LIST_OF_CHANGES</a>]</h4>
<p>relevant={{mediawiki.external('LIST_OF_CHANGES')}} is used to set what types of changes are relevant to a live region. Multiple types of changes can be listed as relevant; the types are separated by a space. The default is relevant="additions text".
</p>
<table border="1" summary="relevant=[LIST_OF_CHANGES]">
<tbody><tr>
<th> Setting
</th><th> Description
</th><th> Example
</th></tr>
<tr>
<td> relevant="additions"
</td><td> relevant="additions" states that the insertion of nodes to the live region should be considered relevant.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_additions.htm">Simple Test Case for relevant="additions"</a>
</p>
</td></tr>
<tr>
<td> relevant="removals"
</td><td> relevant="removals" states that the removal of nodes to the live region should be considered relevant.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_removals.htm">Simple Test Case for relevant="removals"</a>
</p>
</td></tr>
<tr>
<td> relevant="text"
</td><td> relevant="text" states that changes to the text of nodes that already exist in the live region should be considered relevant.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_text.htm">Simple Test Case for relevant="text"</a>
</p>
</td></tr>
<tr>
<td> relevant="all"
</td><td> relevant="all" states that all changes to the live region should be considered relevant. This is the same as doing relevant="additions removals text".
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_all.htm">Simple Test Case for relevant="all"</a>
</p>
</td></tr></tbody></table>
<h3 name="Current_Status_of_Fire_Vox_Support">Current Status of Fire Vox Support</h3>
<table border="1" summary="Current Status: What works and what needs improvement">
<tbody><tr>
<th> Property
</th><th> What works
</th><th> Improvements needed
</th></tr>
<tr>
<td> live=POLITENESS_SETTING
</td><td>
<p>Fire Vox supports the politeness setting.
</p>
<ul><li> Off events are not announced.
</li><li> Polite events are queued.
</li><li> Assertive events will cause earlier polite events to be discarded from the queue but not earlier assertive events.
</li><li> Rude events cause earlier polite and assertive events to be discarded from the queue.  
</li></ul>
<p>If there are too many events in the queue, Fire Vox tries to keep up as best it can with the hope that the event frequency will decrease later on - after the number of events passes a threshold, the oldest events are automatically dropped to make room for newer events.  Fire Vox tries to maintain chronological consistency. Events are announced in the order in which they were fired. 
</p><p>This is the reason that less polite events will cancel events that are more polite; chronological consistency is violated if a user hears a polite event after having first heard a rude event which was fired after the polite event.
</p><p>In addition, since most webpages are not currently marked up with WAI-ARIA properties, there is an internal value of "unknown". Under the default mode for live region announcements, Fire Vox will treat "unknown" as a politeness setting between "off" and "polite"; "unknown" events will be announced, but they can be discarded by "polite" events. Under the tagged mode for live region announcements, Fire Vox will treat "unknown" as if it were "off".
</p><p><a class="external" href="http://accessibleajax.clcworld.net/suggested/live_missing.htm">Simple Test Case for live= is missing ("unknown")</a>
</p>
</td><td> None
</td></tr>
<tr>
<td> controls={{mediawiki.external('IDLIST')}}
</td><td> This property is not ideal; a region can be changed both by a control or a world event.
</td><td>
<p><a class="external" href="http://accessibleajax.clcworld.net/report.html#issues_causality">There needs to be some way to determine causality in order for AT to know whether or not it should treat a change to a region as a result of a user action on a control. </a>
</p>
</td></tr>
<tr>
<td> atomic=BOOLEAN
</td><td> Fire Vox supports the atomic property. If a region is marked as atomic, the entire region will be read out when any of its subregions are modified.
</td><td> None
</td></tr>
<tr>
<td> labelledby={{mediawiki.external('IDLIST')}}
</td><td> This should work, but support for it has not been implemented in Fire Vox yet.
</td><td> None yet; however, it should be stressed to web developers that the ARIA properties will override HTML elements. Thus if a label element is used with a "for=" that points to a live region which has "labelledby=" but does not include the label element in its IDLIST, then that label element will NOT be considered a label for that live region.
</td></tr>
<tr>
<td> describedby={{mediawiki.external('IDLIST')}}
</td><td> This should work, but support for it has not been implemented in Fire Vox yet.
</td><td> None yet.
</td></tr>
<tr>
<td> relevant={{mediawiki.external('LIST_OF_CHANGES')}}
</td><td> Fire Vox supports the relevant setting. Any event which is deemed to not be relevant automatically have their politeness level set to off and are not announced.
</td><td> None
</td></tr></tbody></table>
<h3 name="Issues_and_Proposed_Solutions">Issues and Proposed Solutions</h3>
<table border="1" summary="Issues: Problems and suggested solutions">
<tbody><tr>
<th> Issue
</th><th> Problem Description
</th><th> Proposed Solution
</th></tr>
<tr>
<td id="issues_causality"> 1. Causality
</td><td> The AT will need some way to know whether a control is really controlling a live region or if the onChange event for a particular control and an update to a live region that it controls is merely a coincidence (imagine a user tabbing out of the input blank after having typed something but without pressing enter and having some other user send a message at about the same time - both events happened, but the change in the input blank was not the cause for the new message that appeared in the blank).
</td><td> The browser can trace through the stack of JavaScript function calls that resulted in a change to the page to see if that change was caused by a JavaScript function that was triggered by a user action (such as clicking on a button). This cannot determine causality for every case as it is possible that the user action causes an HTTP request to be made to the server and the response handler for that request then causes the change; such a change would appear to be coming from a world event rather than a user action. However, knowing the source of a change could be helpful in disambiguating the two cases in other scenarios. In addition, for situations where a change can be caused by either user interaction or a world event, the recommendation is to not specify that live region as something that the control is controlling.
</td></tr>
<tr>
<td> 2. Interim updates
</td><td> If an update is polite, it is unclear whether or not it should cause the earlier updates for the same region in the queue to be discarded. In the case of updates made to a live region that displays the most recent play made in a game, polite events about the play just made should not cause earlier events to be discarded; to get a full picture of how the game is unfolding, one must know what the earlier plays were. So in this case, the user should be allowed to lag behind while many plays are being made and then catch up when there is a time out or some other pause in the action. However, in the case of updates to a stock price, the current price is what matters and its price three or two or one minute ago is of no interest; thus, polite updates to the stock price should cause earlier events to be discarded.
</td><td>
<p>Since understanding the purpose behind the updates is crucial to determining whether or not earlier events should be discarded, web developers should have the ability to set the default for whether the AT should treat interim events for a particular live region as relevant or if only the final announcement-time content is relevant.
</p><p>Adding "interim" as a keyword for relevant would solve this problem. If "interim" is added, then all relevant events to the live region which have happened since the last announcement will be announced. However, if "interim" is not specified, then only the events which are currently reflected in the page will be announced.
</p><p>This means that without "interim", if the events queue have a node being added and then having its text changed, the announcement will only announce the current state of that node's text - the original text that it had when it was first added will not be announced since that is not there anymore. If "interim" had been used in this case, then there would have been an announcement that the node was added which gives its original text, followed by another announcement that the node was updated which gives its current text.
</p><p>Note that interim's control over whether later events cause earlier events to be discarded is orthogonal to what is controlled by live=POLITENESS_SETTING. Assertive and rude events will still discard earlier events which are more polite than themselves, regardless of the interim setting. Whether a polite event will discard earlier polite events for the same region depends on the interim setting; a polite event will never discard earlier polite events from other regions.
</p><p>Although adding the value of "interim" to the relevant property is still being discussed, Fire Vox already supports it. 
</p><p><a class="external" href="http://accessibleajax.clcworld.net/suggested/relevant_interim.htm">Simple Test Case for relevant="interim additions text"</a>
</p>
</td></tr>
<tr>
<td> 3. Batching events
</td><td> Sometimes, a web developer may make a series of related changes in quick succession. Announcing them as separate events would confuse the user, and the time it takes for the changes to happen is dependent on the user's machine and the network.
</td><td> The web developer should have a way to specify whether a live region is busy. Adding busy="BOOLEAN" would solve this problem. busy="true" means that the live region is in the middle of a set of changes and that no events should be announced yet. busy="false" means that the live region is done with its set of updates. The default is busy="false"; thus, if nothing is specified, then by default, events to live regions are ready to be announced when they happen.
</td></tr>
<tr>
<td> 4. Setting a threshold on event frequency
</td><td> With events that come from world events, the frequency of the events could vary dramatically in some cases. Too many events at once would make it very difficult for AT users to keep up and could lead to cognitive overload.
</td><td> In most real world situations where there can suddenly be a string of updates, it is the same set of information that is being updated. Good examples would be stocks and game stats. In both of these cases, interim should not be set as only the current values matter. As a result, users should not fall too far behind. To address the problem of cognitive overload (especially if the user is multitasking), AT should provide a patience setting that allows users to restrict updates to only once every X seconds.
</td></tr>
<tr>
<td> 5. Higher level abstractions for web developers
</td><td> Having to specify the live region properties for each widget on a page can be tedious; it also increases the chances for human error.
</td><td> Web developers should be able to use WAI-ARIA Roles as a higher level abstraction for specifying the live region properties. Roles such as "log", "alert", "progressbar", etc. should have a default set of live region properties associated with them in the WAI-ARIA standard. These default properties can be overridden by explicitly specifying them.
</td></tr>
<tr>
<td> 6. Browser support
</td><td> Browsers only give AT relatively low level information. For example, when the textContent of an HTML node is changed, the DOM mutation events that are fired are "DOMNodeRemoved" followed by "DOMNodeInserted". It is currently up to the AT to piece together these two bits of information and deduce that what has really happened is a text change event.
</td><td> AT vendors need more information and better abstractions from browsers. In the case of the textContent changing and two separate events being fired, the browser can clearly tell that it is a textContent change rather than an old element being removed from the page and then a new element being added. That information should be given to the AT directly since that will be more accurate and less computationally expensive than having the AT try to figure all of this out for itself.
</td></tr>
<tr>
<td> 7. Style changes are not fired as DOM events
</td><td> If we developers dynamically show/hide elements by changing the style on the elements, ATs that look at the DOM will not be able to detect when such a change has occurred since there is no DOM event fired. This is a problem for elements on the page which from a user's point of view, are essentially added or removed via changes to the display or visibility property.
</td><td> The DOM spec should provide for the firing of events when style has been changed.
</td></tr></tbody></table>
<h3 name="To_Be_Done">To Be Done</h3>
<ul><li> Recommendations for authors
</li><li> Description of logic for AT vendors
</li><li> List end-user features (both implemented and planned)
</li></ul>
Revert to this revision