Warning:
This wiki has been archived and is now read-only.
Accessibility and ARIA
4.1: Accessibility and Rich Internet Applications
Persons with disabilities most often interact with their computers using third-party assistive software such as speech synthesis, braille output, screen magnification, voice input or an on-screen keyboard. Even in environments where multi-modal output is natively supported by the user's underlying operating system, assistive technology is only capable of providing an equivalent user experience with a Rich Internet Application if there exist explicit bindings between scripted objects or routines and regions of the RIA which are dynamically updated. When a script manipulates the contents of a page, assistive technology cannot be relied upon to update the user of the new data or content output by a scripted process, because the script, and not the underlying declarative framework utilized for the RIA, directly generates the output.
The W3C has developed a technology to address these issues: Accessible Rich Internet Applications (ARIA {ref 1}). ARIA enables multi-modal navigation and interaction with scripted objects and their output, through the use of explicit role and state properties which can be bound to the declarative framework upon which a javascripted object or element is presented to the user. ARIA also provides focus management mechanisms, which are critical to an assistive technology users' understanding of, and ability to interact with, the RIA. In the absence of ARIA bindings, scripted objects and the changes to a web document caused by scripting, constitute perceptual and functional black holes. Thus, the additional semantics provided by ARIA allows authors to restructure and substitute alternative content in an RIA and ensures that assistive technologies can communicate changes of role (ref 2), state (ref 3), or property {ref 4) caused by scripting, as well as ensuring that dynamically updated content is accessible to the user of an assistive technology.
While there are a handful of markup languages that explicitly separate presentation from content – in particular XForms and MathML – and provide explicit binding mechanisms, the overwhelming majority of RIAs currently implemented on the web use a generic markup language, such as HTML or XHTML. Even when using a declarative markup language which has been designed so as to be natively accessible to persons with disabilities, there is still a need for ARIA bindings in order to facillitate multi-modal exposition of the content and interactivity provided by the RIA through the use of scripting, as javascript overrides the default user agent behavior at the DOM node when manipulating and/or managing data, the content, and/or the style of an RIA in response to events either caused by user interaction or by background scripts which produce custom widgets and update specific areas of the RIA.
ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that is equivalent to the ARIA feature, the host language feature should be used. ARIA should be used in cases where the host language lacks the needed role, state and/or property indicator. Authors are advised to first use a host language feature that is as similar as possible to an ARIA feature, then refine the meaning of the feature by adding ARIA. This allows for the best possible fallback for user agents that do not support ARIA and preserves the integrity of the host language semantics. ARIA also enables a user to control the behavior of an element in response to user input events such as from the keyboard and the mouse. Authors are advised to use device-independent events with supporting javascript to handle user interaction.
4.1.1. ARIA LIVE REGIONS AND POLITENESS LEVELS
In RIAs, alerts and dialogs are often used to convey important messages and feedback to the user. ARIA provides mechanisms which ensure that a user, no matter what her means of interacting with the web, is notified of dynamic changes to a RIA's content by processing the alert or dialog as a live region. An example of a live region is a section of an RIA that reflects dynamic data management, such as auto-updating stock quotes or updating a designated region on an interactive financial form. ARIA contains attributes specific to live regions, using the aria-live attribute (ref 5), which may be applied to any element. Use of the aria-live attribute indicates that content changes may occur without the element to which the content change is bound receiving focus, thereby providing an assistive technology with sufficient information on how to process those content updates by first Indicating that an element will be updated, and describes the types of updates which the user agent, the assistive technology and individual users can expect from the live region.
ARIA expresses live regions in terms of "politeness levels". Regions specified as polite will notify users of updates, but do not generally interrupt the current task. ARIA's assertive value is used when the update needs to be communicated to the user more urgently; for example, a warning or error messages in a form that performs immediate validation for each form field. Politeness levels are essentially an ordering mechanism for updates and serve as a strong suggestion to the user agent or assistive technology. The value may be overridden by the user agent, assistive technology, or user. Since different users have different needs, it is up to the user to tweak his or her assistive technology's response to a live region with a certain politeness level from the commonly defined baseline. Using the aria-live attribute is the primary determination for the order of presentation of changes to live regions. Implementations must also consider the default level of politeness in a role when the aria-live attribute is not set in the ancestor chain (for example, log (ref 6) changes are polite by default). Items which are assertive should be presented immediately, followed by polite items. An assistive technology is thus able to implement increasing and decreasing levels of granularity so that the user can exercise control over queues, interruptions and dynamic updates, which -- without ARIA bindings -- would be imperceptible to the user of assistive technology.
Note: The discussion page for this wiki document contains an alternate version of the final paragraph of proposed text.
REFERENCES: