Accessibility and ARIA in Rich Internet Applications (proposed text)

sincerest apologies for missing this week's XG telecon and, hence, for 
being late with my proposed text for Section 4.  i tried to keep this 
as brief and as clear as possible -- the following can be reviewed 
(and commented upon) via the RWAB wiki:

http://www.w3.org/2005/Incubator/app-backplane/wiki/Accessibility_and_ARIA

--- begin suggested text ---

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 a 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 state, role, or 
properties 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 [ref 2], state [ref 3], or property [ref 
4] 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.


REFERENCES:
1) http://www.w3.org/TR/wai-aria
2) http://www.w3.org/TR/wai-aria/#def_Role
3) http://www.w3.org/TR/wai-aria/#def_State
4) http://www.w3.org/TR/wai-aria/#def_Property
5) http://www.w3.org/TR/wai-aria/#aria-live
6) http://www.w3.org/TR/wai-aria/#log


--- end suggested text ---

-----------------------------------------------------------------
Accessibility, Internationalization, and Interoperability are not
"features", "overlays" or "add-ons".  Rather, they are core 
components of any architecture -- programmatic or otherwise.
-----------------------------------------------------------------
     Gregory J. Rosmaita, gregory@linux-foundation.org
Vice-Chair, WebMaster & Listmaster, Open Accessibility Workgroup
http://a11y.org/                                http://a11y/specs
-----------------------------------------------------------------

Received on Wednesday, 30 September 2009 20:40:12 UTC