Accessibility/Original live region report

From MozillaWiki
Jump to: navigation, search

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

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 <a class="external" href="http://www.mozilla.org/access/#community">mailing list</a>.

Live Region Attributes and Test Cases

Please see the following sets of test cases with live region properties set:

The test cases currently work with <a class="external" href="http://www.firevox.clcworld.net/downloads.html">Fire Vox</a> and <a class="external" href="http://live.gnome.org/Orca">Orca</a>.

In addition, Windows desktop screen readers such as JAWS and Window-Eyes do not yet (as of JAWS 9 and Window-Eyes 7 beta) utilize live region markup. Firefox 3 provides <a class="external" href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="http://developer.mozilla.org/editor/fckeditor/core/editor/en/AJAX/WAI_ARIA_Live_Regions//API_Support">API support for live regions</a>, and work is now being done by ATs to make use of that information.

<a class="external" href="http://www.w3.org/WAI/PF/aria/#live">aria-live=POLITENESS_SETTING</a>

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

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

<a class="external" href="http://accessibleajax.clcworld.net/simple/live_off.htm">Simple Test Case for aria-live="off"</a>
aria-live="polite" The region is live, but updates made to it should only be announced if the user is not currently doing anything. aria-live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines.

<a class="external" href="http://accessibleajax.clcworld.net/simple/live_polite.htm">Simple Test Case for aria-live="polite"</a>
aria-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. aria-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.

<a class="external" href="http://accessibleajax.clcworld.net/simple/live_assertive.htm">Simple Test Case for aria-live="assertive"</a>
aria-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. aria-live="rude" should be used sparingly and only with great consideration as it can be very annoying to users.

<a class="external" href="http://accessibleajax.clcworld.net/simple/live_rude.htm">Simple Test Case for aria-live="rude"</a>

<a class="external" href="http://www.w3.org/WAI/PF/aria/#controls">aria-controls=[IDLIST</a>]

aria-controls=Template:Mediawiki.external('IDLIST') is used to associate a control with the regions that it controls.

<tbody> </tbody>
Setting Description Example
aria-controls="myRegion1_IDREF myRegion2_IDREF etcEtcEtc_IDREF" aria-controls=Template: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. At this time, Firefox automatically calculates whether an event is from user input and exposes the information to ATs. Please see the docs on <a class="external" href="mks://localhost/en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support" title="en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support">API support for live regions in Firefox</a>.

<a class="external" href="http://accessibleajax.clcworld.net/simple/controls.htm">Simple Test Case for aria-controls=[IDLIST</a>]

<a class="external" href="http://www.w3.org/WAI/PF/aria/#atomic">aria-atomic=BOOLEAN</a>

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

<tbody> </tbody>
Setting Description Example
aria-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. aria-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.

<a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_false.htm">Simple Test Case for aria-atomic="false"</a>
aria-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. aria-atomic="true" can make it harder for users to understand changes as the changed areas are not presented independently. aria-atomic="true" can also be annoying as it can force users to listen to repetitive information that has not changed. However, aria-atomic="true" is necessary in cases where the change, when presented by itself, cannot be understood and contexualized by the user.

<a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_true.htm">Simple Test Case for aria-atomic="true"</a>

<a class="external" href="http://www.w3.org/WAI/PF/aria/#labelledby">aria-labelledby=[IDLIST</a>]

aria-labelledby=Template:Mediawiki.external('IDLIST') is used to associate a region with its labels.

<tbody> </tbody>
Setting Description Example
aria-labelledby="myLabel1_IDREF myLabel2_IDREF etcEtcEtc_IDREF" aria-labelledby=Template: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.

<a class="external" href="http://accessibleajax.clcworld.net/simple/labelledby.htm">Simple Test Case for aria-labelledby=[IDLIST</a>]

<a class="external" href="http://www.w3.org/WAI/PF/aria/#describedby">aria-describedby=[IDLIST</a>]

aria-describedby=Template:Mediawiki.external('IDLIST') is used to associate a region with its descriptions.

<tbody> </tbody>
Setting Description Example
aria-describedby="myDisc1_IDREF myDisc2_IDREF etcEtcEtc_IDREF" aria-describedby=Template: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.

<a class="external" href="http://accessibleajax.clcworld.net/simple/describedby.htm">Simple Test Case for aria-describedby=[IDLIST</a>]

<a class="external" href="http://www.w3.org/WAI/PF/aria/#relevant">aria-relevant=[LIST_OF_CHANGES</a>]

aria-relevant=Template: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 aria-relevant="additions text".

<tbody> </tbody>
Setting Description Example
aria-relevant="additions" aria-relevant="additions" states that the insertion of nodes to the live region should be considered relevant.

<a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_additions.htm">Simple Test Case for aria-relevant="additions"</a>
aria-relevant="removals" aria-relevant="removals" states that the removal of nodes to the live region should be considered relevant.

<a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_removals.htm">Simple Test Case for aria-relevant="removals"</a>
aria-relevant="text" aria-relevant="text" states that changes to the text of nodes that already exist in the live region should be considered relevant.

<a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_text.htm">Simple Test Case for aria-relevant="text"</a>
aria-relevant="all" aria-relevant="all" states that all changes to the live region should be considered relevant. This is the same as doing aria-relevant="additions removals text".

<a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_all.htm">Simple Test Case for aria-relevant="all"</a>

<a class="external" href="http://www.w3.org/WAI/PF/aria/#Using_intro">role</a>

<tbody> </tbody>
Setting Description Example
role="timer", "log", "marquee" or "status" Each of those has a special meaning and a default politeness level. Please see the WAI-ARIA specification    

Live Changes on Pages Without WAI-ARIA Markup

It is possible to still do a good job with live changes on pages where the author did not use WAI-ARIA markup. A combination of the following things can help:

  1. User settings, scripts or toggles, either global or persisted by URL
  2. Timing and observation of when or how often changes occur
  3. The size of the change
  4. What the user is doing (how busy they are)
  5. Whether the event came from user input (see the <a class="external" href="mks://localhost/en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support" title="en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support">live region API support docs</a>)

Please test your software with <a class="external" href="http://live.gnome.org/Orca/Firefox/LiveRegions#head-6849dcb441b30982cf79ea5b155c0d4c7a686c45">web pages known to use AJAX but not live region markup</a>.

Current Status of Fire Vox Support

<tbody> </tbody>
Property What works Improvements needed
aria-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".

<a class="external" href="http://accessibleajax.clcworld.net/suggested/live_missing.htm">Simple Test Case for live= is missing ("unknown")</a>

 None
aria-controls=Template:Mediawiki.external('IDLIST') This property is not ideal; a region can be changed both by a control or a world event.

<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>
aria-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
aria-labelledby=Template:Mediawiki.external('IDLIST') Fire Vox supports the labelledby property. When the current element is queried for more information (default: Ctrl + Shift + Q), the text contents of any labelledby elements for that current element will be read out. The user has to actively query for this association; it is not actively provided, unlike the <label> property which is read as part of the identifying information of the element when it is read. The problem here is that with the HTML label element, it is possible to know when that element is first encountered that it is a label for something else. Thus the strategy is to not read a label until the item it is labelling is read. This prevents re-reading a label. However, with the labelledby property, the same algorithm is not possible; anything with an ID can potentially be a label and that cannot be determined until the item being labelled is encountered. Thus an element acting as a label because of the labelledby property cannot be skipped like an HTML label element. To svoid rereading the label and annoying the user, Fire Vox takes the approach of simply not reading the labelledby element until the user specifically tries to query for that relationship. Once the relationship can be determined available efficiently in both directions, then Fire Vox can treat labelledby elements as HTML label elements.
aria-describedby=Template:Mediawiki.external('IDLIST') Fire Vox supports the describedby property. When the current element is queried for more information (default: Ctrl + Shift + Q), the text contents of any describedby elements for that current element will be read out. None
aria-relevant=Template: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

Current Status of Orca Support

<tbody> </tbody>
Property What works Improvements needed
aria-live=POLITENESS_SETTING

Orca 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, Orca 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. Orca 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.

Orca also supports no ARIA markup cases and identifies document changes as live region events. In addition, Orca provides the user a set of controls to change the politeness of a live region and the ability to save these changes for later visits.

 None
aria-controls=Template:Mediawiki.external('IDLIST') Orca does not support aria-controls. Currently not implemented.
aria-atomic=BOOLEAN Orca supports the atomic property. None
aria-labelledby=Template:Mediawiki.external('IDLIST') Orca supports the labelledby property. Currently this information is provided with the live region content. However, there are some issues when labeling with spans and currently there is no support for multiple labels. See Firefox bugs. None
aria-describedby=Template:Mediawiki.external('IDLIST') Orca supports the describedby property as part of the "where am I" function. None
aria-relevant=Template:Mediawiki.external('LIST OF CHANGES') Orca does not currently recognize aria-relevant Currently not implemented.

Issues and Proposed Solutions

<tbody> </tbody>
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). In Mozilla, this is now provided via the "event-from-user-input" object attribute via the nsIAccessible interface. See <a href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="en/AJAX/WAI_ARIA_Live_Regions//API_Support">AJAX:WAI_ARIA_Live_Regions/API_Support</a> for more information.
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 aria-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.

<a class="external" href="http://accessibleajax.clcworld.net/suggested/relevant_interim.htm">Simple Test Case for aria-relevant="interim additions text"</a>
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. Additionally, a connection may time out or have some other error; thus, it is possible to have a series of updates that is only partially completed and unable to finish. The web developer should have a way to specify whether a live region is busy. Adding aria-busy={true/false/error} would solve this problem. aria-busy="true" means that the live region is in the middle of a set of changes and that no events should be announced yet. aria-busy="false" means that the live region is done with its set of updates. aria-busy="error" means that an error has occurred and that the full set of updates will not be completed. The default is aria-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.
8. Notifications Some notifications should be spoken before regular messages without causing the regular messages to be dropped. An example of such a notification is a chat message that is directed at the user. In such a case, that message should be spoken before the other chat messages, but the other chat messages should still be spoken and not just dropped. Some AT users have both speech synthesis and Braille - they may prefer assertive notifications to be delivered to the Braille display while regular messages are spoken by the synthesizer.

If multiple hardware channels are available, the AT should allow users to map the live events to different channels.

Status of ATK/AT-SPI and IAccessible2 Support in Firefox

There is quite a lot of API support in Firefox 3 for live regions. Please read <a href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="en/AJAX/WAI_ARIA_Live_Regions//API_Support">AJAX:WAI_ARIA_Live_Regions/API_Support</a> for more information.

Recommendations for authors

Please see the <a class="external" href="http://www.w3.org/WAI/PF/aria-practices/#LiveRegions">live region section in the Best Practices Guide</a>.

Recommendations for screen reader developers

Please see the <a class="external" href="mks://localhost/en/ARIA/ARIA_Screen_Reader_Implementors_Guide#Live_Regions" title="http://developer.mozilla.org/editor/fckeditor/core/editor/En/ARIA_Screen_Reader_Implementors_Guide#Live_Regions">live region section in the ARIA Screen Reader Implementors Guide</a>.

Recommendations for browser implementors

Please see <a class="external" href="mks://localhost/en/ARIA_User_Agent_Implementors_Guide#11.3.12_Changes_to_document_content_or_node_visibility" title="http://developer.mozilla.org/editor/fckeditor/core/editor/en/ARIA_User_Agent_Implementors_Guide#11.3.12_Changes_to_document_content_or_node_visibility">changes to document content or node visibility</a>in the ARIA user agent implementors guide.

Retrieved from "https://wiki.mozilla.org/index.php?title=Accessibility/Original_live_region_report&oldid=363336"