PF/ARIA/BestPractices/Introduction

From W3C Wiki
< PF‎ | ARIA‎ | BestPractices


Introduction


The Accessible Rich Internet Applications (ARIA) Best Practices Guide (BPG) is intended to provide readers with an understanding of how to use ARIA to create an accessible Rich Internet Application. The ARIA BPG starts with a review of the ARIA Roadmap, which identifies accessibility deficiencies in today's markup related to enabling Rich Internet Applications (RIAs). It continues with a description of how the Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) plans to address these deficiencies through several W3C standards efforts, with a focus on the ARIA specifications.

The BPG is meant to accompany the Roles for ARIA Specification and the States and Properties for WAI-ARIA specifications to aid in the understanding.

Roadmap Review

More than 55% of all Web sites today contain JavaScript, dramatically affecting the ability for persons with disabilities to access Web content. New Rich Internet Applications (RIAs) render custom widgets, modeling rich desktop componentry to perform UI updates without having to reload the entire page - much like a graphical user interface (GUI). Legacy GUI accessibility frameworks address these issues through a comprehensive accessibility application programming interface (API) and infrastructure to foster interoperability with assistive technologies. These APIs constitute a contract between applications and assistive technologies, such as screen readers, to enable them to access rich dynamic content with the appropriate semantics needed to produce a usable alternative. No such contract exists between modern RIAs and assistive technologies, creating an accessibility gap for persons with disabilities.

Interoperability and Today's Web Content

Aspects of traditional HTML make accessible support of dynamic content difficult:

  1. Accessibility relies on abstracting semantics from both content and presentation information. Extracting semantic cues from current HTML content is typically unreliable. Today, semantics are limited to tag elements names.
  2. HTML allows content to be repurposed for presentation formatting without providing a way to convey semantic information. A common example of this is tables used to format content rather than style sheets.
  3. When combined with script and CSS, HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic GUI content.
  4. HTML lacks the ability to attach meaningful metadata about document structure.
  5. HTML elements commonly used for repurposing produce custom components that are not keyboard accessible.

Authors of JavaScript-generated content do not want to limit themselves to using standard tag elements that define the actual user interface element such as tables, ordered lists, etc. Rather, they make extensive use of tag elements such as DIVs in which they dynamically apply a UI through the use of style sheets and dynamic content changes. HTML DIV tags provide no semantic information. For example, authors may define a DIV as the start of a pop-up menu or even an ordered list. However, no HTML mechanism exists to:

  • Identify the role of the DIV as a pop-up menu
  • Alert assistive technology when these elements have focus
  • Convey accessibility property information, such as whether the pop-up menu is collapsed or expanded
  • Define what actions can be formed on the element other than through a device-dependent means through the event handler type (onmouseover, onclick, etc.)

In summary, JavaScript authors need an accessibility architecture to which they can write such that a solution can be mapped to the accessibility framework of the native platform by the user agent.

To-be-attached: Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript

Figure 1.0 illustrates a typical DOM node in a Model-View-Controller architecture. On the node, data, or the "Model", which should include semantic information, is separated from the user interface presentation, the "View." Here, the document element is managed by the user agent based on the default behavior of the element. The user agent's default behavior at the document element forms the controller. Placed between the DOM node and the assistive technology is a box containing the contract provided by the user agent to the assistive technology. This data includes typical accessibility information found in the accessibility API for many accessible platforms for GUIs (role, state, caret, selection, text, hypertext, name description, parent/child information, parent/child information, and relations). For HTML and other W3C markup, the accessibility information provided solely depends upon what the element's tag--and any accessibility attributes that map to that tag--provides. For example, the accessible role of a table is table. The author provides an accessible description by assigning a title attribute.

To-be-attached: Figure 2.0 accessibility Interoperability at a DOM node with JavaScript

Figure 2.0 shows a DOM node provided in Figure 1.0 with JavaScript acting as the new controller. JavaScript overrides the default user agent behavior at the DOM node. It manipulates the data, content, and style in response to events caused by user interaction to produce custom widgets. In this situation the default accessibility information is no longer valid, and, therefore, the contract is now invalid. Figure 2.0 shows the contract with asterisks in front of role, state, actions, value, event changes, and relations. These asterisks represent potential accessibility errors and gaps in the base markup. These gaps result from the author's inability to provide to the assistive technology the new semantic data needed to support the contract.

Filling the Gaps with ARIA

Deficiencies in HTML make the task of creating accessible RIAs difficult or impossible. Most of these problems can be addressed through the use of the W3C ARIA specifications. Problems ARIA addresses include:

  • Incomplete keyboard support in HTML and XHTML
  • Inability to provide the necessary semantics to enable full interoperability with Assistive Technologies
  • Unusable keyboard navigation due to a dependence on tabbing
  • Lack of structural semantics to assist content restructuring for diverse users

The ARIA specifications include:

Table 1 lists gaps in accessibility support in HTML, mapping them to the ARIA specification and feature that address each gap.

Table 1. Accessibility Gap in HTML Mapped to ARIA Specifications

|| GAP in (X)HTML || ARIA Specification filling the gap || Specification feature ||
|| Full Keyboard focus with author control over what is included in the tab order || States and Properties || tabindex modifications ||
|| value and value change notification || States and Properties || valuenow, valuemax, and valuemin. valuenow changes mapped to accessibility value change events ||
|| state and property change notification || States and Properties || States and Properties mapped to accessibility state or property change events ||
|| GUI-supporting states and properties || States and Properties ||All non-abstract States and Properties ||
|| Live region properties || States and Properties || Live region properties ||
|| Device Independent Navigation || XHTML Role Attribute Module, Roles for ARIA, States and Properties || XHTML role landmarks, Region, Directory roles in Roles for ARIA, Drag and Drop Properties of the States and Properties Module ||
|| Role Information (for re-purposed) markup || Roles for ARIA || All non-abstract roles in the taxonomy ||
|| Relationships and Labels || States and Properties || labelledby, controls, flowto, owns properties ||
|| Descriptions or help || States and Properties, Roles for ARIA || special describedby relationship property referenced to the description role in Roles for ARIA ||

ARIA may also be used to improve the accessibility of static (X)HTML documents. The XHTML role landmarks can vastly improve navigation of static (X)HTML by providing device-independent landmarks that any site can use. Once set, the user agent or assistive technology can assign a common set of keys or discrete device-specific inputs to move programmatic focus to the corresponding document parts. The ARIA states and properties provide missing form control properties, indicate invalid and required, and flag (X)HTML form controls with the appropriate properties. Finally, ARIA roles provide a presentation role that can be applied to tables used only for layout. This directs the user agent to tell an assistive technology that the table is only presentational and is used for layout purposes only. This eliminates the need to rewrite existing applications to use a style sheet to reproduce a table layout.

Applicability to XHTML and HTML

The ARIA States and Properties Module defines a collective extension to XHTML that includes:

  • The addition of the XHTML 1.X role attribute module, which provides for the role attribute and standard document sections that aid navigation
  • Changes to TABINDEX to allow the author to set keyboard focus to all XHTML elements while specifying if and where the elements may show up in the tab order.
  • States and properties needed to enable an author to provide accessibility semantics to assistive technologies for RIAs

The ARIA Roles for Accessible Rich Internet Applications specification provides role values needed to support rich internet applications. The common role values provided in the specification are defined in a taxonomy using an RDF and OWL. The RDF/OWL role taxonomy uses semantic web technology to define a class hierarchy and inheritance model to show state and property inheritance as well as related concepts for the roles in other industry applications. The role taxonomy establishes a basis for extensibility of constructions of new taxonomies in the future. For ARIA 1.0, developers should use the taxonomy to determine what states and properties a particular role can support. Role values are referenced using a qname.

This example uses roles and states in XHTML to convey that a

element has been re-purposed as a menu that has a pop-up menu and that accepts focus.

<?xml version="1.1" encoding="us-ascii"?>

  <!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
   http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"

   xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
   xmlns:aria="http://www.w3.org/2005/07/aaa"

>

   <body>
           File
   </body>

</html>

As this example shows, extensibility to XHTML, for ARIA, is achieved through namespaces (i.e.: aria:haspopup). HTML documents do not support namespaces, so the required accessibility role and state metadata cannot be included directly in these documents. In HTML 4, authors can define accessible role and accessible states as keywords in the class attribute, then use an ECMAScript library to parse the class keywords and copy them into the appropriate role and state namespaces after the document has been loaded. This enables provision of ARIA states and properties while circumventing the HTML validator by using the class attribute.

<html lang="en"> <head> <script type="text/javascript" src="slider.js"></script> <script type="text/javascript" src="enable.js"></script> </head> <body> </body> </html>

After declaring any classes used for styling, the accessible DHTML control defines a class of "axs". This signals to the ECMAScript compatibility library that this element defines additional role and state information. The next class in the space-separated list of classes is the DHTML role. The remaining classes in the class attribute list represent state information.

A state is a key-value pair, separated by a hyphen. For example, to represent that a checkbox control is currently checked, one could use class="axs checkbox checked-true". Because checkboxes are so common, a true Boolean state may be represented simply by the state name. So instead of class="axs checkbox checked-true", one can simply say class="axs checkbox checked".

For more details see the : Embedding Accessibility Role and State Metadata in HTML Documents.

Simple Tree Widget Example

Consider this simple tree widget example in XHTML: Simple Tree Widget example.

Brief Introduction to the Use of Semantic Web Technology

For years, assistive technologies and application developers have lacked a mechanism to describe the user interface objects in Web applications. When creating new custom interface component, RIA developers have difficulty informing assistive technologies of what UI properties to expect from the UI component and of what other UI components known to the AT that the component resembles.

Semantic Web Technology is a World Wide Web technology, represented in natural language, that is machine-processable. The Roles for ARIA specification uses the semantic web technologies Resource Description Framework (RDF), a way to describe a resource; RDF Schema (RDF-S), a knowledge representation language; and the Web Ontology Language (OWL) to represent the roles in a class hierarchy. OWL describes classes and their properties, along with their related properties and instances.

In the case where gridcell is used in XHTML:

the qname wairole:gridcell expands to http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#gridcell resolves to the gridcell OWL class with ID of "gridcell" represented here from the ARIA Role taxonomy:

<owl:Class rdf:ID="gridcell">

     <rdfs:subClassOf rdf:resource="#section"/>
     <rdfs:subClassOf rdf:resource="#widget"/>
     <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TD"/>
     <role:scope rdf:resource="#row"/>
     <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#expanded">
        <role:default>undefined</role:default>
     </role:supportedState>
     <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#readonly">
        <role:default>false</role:default>
     </role:supportedState>
     <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#selected">
        <role:default>undefined</role:default>
     </role:supportedState>

</owl:Class>

Here we see gridcell represented as an OWL class. We also see that RDF-S is used to indicate that gridcell is a subclass of the OWL classes section and widget. So, a gridcell is a section (structural) and a widget. We also see that it has a base concept of in HTML. We also see that gridcells have a scope within an OWL class of row. Finally, we see that gridcell explicitly supports the expanded, readonly, and selected states from the ARIA States and Properties module, so the readonly property specified by the developer is valid.

Due to inheritance from widget and section, gridcell inherits some ARIA states and properties (atomic, busy, channel, controls, disabled, live, relevant, templateid, and a set of global states). By referring to the ARIA states and properties module you can see that, based on the properties used, a gridcell can take on live region properties, a disabled state, and a templateid to help assistive technologies map customizations to. It also inherits a number of global states defined by the ARIA role taxonomy.

These capabilities will facilitate test tool validation of ARIA-enabled applications and it can help assistive technologies process ARIA semantics provided in a RIA. OWL facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics.

Through the use of semantic web technology, the ARIA standards team was able to build a rich taxonomy of common roles used by RIAs. The role taxonomy will help RIA developers and AT vendors to determine when to use an ARIA role and how to process it respectively. RIAs re-purpose existing XHTML markup. The ARIA Roles specification helps the accessibility testing tools to validate whether the ARIA properties provided are supported for the associated role (XHTML DTD cannot do this validation because the DTD validates attributes supported by the associated XHTML element). The supported ARIA properties for an XHTML element change depending on the ARIA role assigned.

Preview of the Rest of this Document

With an understanding of the issues, the BPG provide direction on how to make RIAs keyboard accessible; then follows guidance on how to provide layout and structural semantics within the web page. These semantics are critical to enable assistive technologies to provide a usable experience when processing RIAs with rich documents on the same page.

The BPG will then introduce the different types of relationships provided by ARIA followed by: guidance on dynamic document management; use of ARIA Form properties, ARIA Drag and Drop, and then the creation of ARIA-enabled alerts and dialogs.

At this point, you will have a good understanding of how ARIA provides for interoperability with assistive technologies and support for a more usable, accessible experience. The BPG will then discuss the construction of accessible simple and complex ARIA examples and some reusable component libraries available to help produce ARIA enabled applications quickly. The BPG appendix provides substantial information including code samples for developers of user agents, assistive technologies, and web pages.