Accessible Rich Internet Applications (WAI-ARIA) Version 1.0

1.1 About This Draft

This section is informative.

This draft currently handles two aspects of roles: GUI functionality and structural relationships of the element. For more information see the Roadmap for Accessible Rich Internet Applications [ARIA-ROADMAP] for the use of roles in making interactive content accessible.

This taxonomy is designed in-part to support the common roles found in platform accessibility APIs. Reference to roles found in this taxonomy by dynamic Web content may be used to support interoperability with assistive technologies.

The schema to support this standard has been designed to be extended so that custom roles can be created by extending base roles. This allows user agents to support at least the base role, and user agents that support the custom role can provide enhanced access. Note that much of this could be formalized in XML Schema [XSD]. However, being able to define similarities between roles, such as baseConcepts and more descriptive definitions would not be available in XSD. While this extensibility is possible, this version of the specification does not define how this extension is to be achieved.

WAI-ARIA is supported by a set of informative resources. In addition to the WAI-ARIA Roadmap, the WAI-ARIA Primer [ARIA-PRIMER] provides a basic introduction to the concepts behind and reason for ARIA, and the WAI-ARIA Best Practices [ARIA-PRACTICES] describe recommended usage patterns for Web content developers. These documents serve as important places of clarification where topics appear to be unclear.

1.2 Use Cases

This section is informative.

Alternate input devices are helped when all content is keyboard accessible. The tabindex changes achieve this. The new semantics when combined by our style guide work will allow alternate input solutions to facilitate command and control on via an alternate input solution.

Low vision solutions benefit from ARIA markup in that the improved keyboard navigation helps people with extremely low vision. Low vision solutions offer a degree of screen reading functionality (like AI Squared's Zoom text). Furthermore, ARIA introduces navigation landmarks both through our taxonomy and the XHTML role landmarks which dramatically improves keyboard navigation productivity. This is a huge benefit for alternate input solutions as well.

ARIA will also be used to assist people with cognitive impairments. The additional semantics will allow us to restructure and substitute alternative content in adaptive Web 2.0 solutions. We are doing this on the FLUID project. In FLUID we will be incorporating ARIA technology into uPortal and Sakai. Support for cognitive impairment is absolutely critical.

1.3 Design Aims

This section is informative.

The design aims of creating this specification include:

• Define what state information may be controlled by the author.
• Support device independence - new devices coming on line, such as telephones, PDA's, tablets, televisions, etc. mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.
• Improve the accessibility of dynamic content such as that generated by script.
• Provide for interoperability with Assistive Technologies.

2.1 WAI-ARIA Roles

An ARIA role is set on an element using the a role attribute similar to the one defined in the XHTML Role Attribute Module [XHTML-ROLES].

<div role = "checkbox">

The roles defined in this specification include a collection of document landmarks and the ARIA role taxonomy.

The Roles in this taxonomy were modeled using RDF/OWL to build rich descriptions of the expected behaviors of each role. For example:

• The roles taxonomy describes the context of a role. For example a listitem should be inside a list.
• The role taxonomy defines a hierarchy of roles with related properties. For example a directory is a type of list.
• The role taxonomy makes use of OWL to provide a type hierarchy allowing for semantic inheritance similar to a class hierarchy.
• The role taxonomy makes references to related concepts in other specifications.
• The role taxonomy provides descriptions for each role.
• The roles taxonomy describes what states are supported for each role. For example, a checkbox supports being checked.

Attaching a role from the role taxonomy to an element in the document gives assistive technology the information it needs to handle an element correctly.

2.2 WAI-ARIA States and Properties

ARIA provides a collection of accessibility states and properties which are used to support platform accessibility APIs on the various operating system platforms. Your assistive technology may access this information through an exposed user agent DOM or through a mapping to the platform accessibility API. When combined with roles your user agent can supply the assistive technology with information to render the information to the user at any instance in time. Changes in states or properties will result in a notification to an assistive technology to let them know that a change in behavior has occurred.

In the following example, a span has been used to create a checkbox which in this case has three possible states. A role is used to make the behavior of this simple widget known to the user agent. Properties that may change with user actions (such as checked) are defined in the States and Properties.

  <span role="checkbox"  aria-checked="mixed"
        onkeydown="return checkBoxEvent(event);" onclick="return checkBoxEvent(event);" >
      A checkbox label
  </span>

It should be noted that some accessibility state information is managed and controlled by the user agent. These are called managed states. Often these states have corresponding CSS pseudo classes to reflect necessary style changes. The states in this specification are typically controlled by the author and are called unmanaged states. Both managed and unmanaged states are mapped to the platform accessibility APIs by the user agent. An example of a managed state is focus.

Finally, an added value for ARIA is that user agents that support CSS attribute selectors ([CSS], Section 5.8) can allow the author to create UI changes based on the ARIA state information, dramatically reducing the amount of script used to create the equivalent functionality, as shown in this example:

*[aria-checked=true]:before {content:   url('checked.gif')}
*[aria-checked=false]:before {content:  url('unchecked.gif')}

*[aria-checked=false]:before {content:  url('unchecked.gif')}

2.3 Building Accessible Applications with WAI-ARIA

This section provides a brief introduction to the process of making applications accessible using ARIA. The choice and usage of roles can be complex and context dependent. It is beyond the scope of this document to explain implementations for all the possible ARIA use cases. ARIA Best Practices [ARIA-PRACTICES] will provide detailed guidance on ARIA implementation methodology as well as references to sample code.

An application becomes accessible when:

1. Each element or widget has full and correct semantics that fully describes its behavior (using element names or roles).
2. The relationships between elements and groups are known
3. States, properties, and container relationships are valid for each element's behavior and are accessible via the Document Object Model [DOM] and the platform accessibility API.
4. There is an element having the correct input focus.

ARIA provides authors with the means to makes the different elements in a Web application semantically rich. User agents use the role semantics to understand how to handle each element. Roles conveys missing information that the assistive technology needs to anticipate the behavior of the elements inside the application such as how to present the corresponding ARIA states and properties to the user. The user agent will use the accessibility semantics from the host language and ARIA accessibility semantics which may override those of the host language and present them to an assistive technology through the Document Object Model or the platform accessibility API. When supporting the platform accessibility API the user agent will create accessible objects containing the accessibility semantics for each visual element on your page. It will use the chosen API to notify the assistive of changes to the semantics as well.

The following list of

1. Use native mark up when possible

   Use the semantic elements that are defined in the host markup language. For example, with XHTML it is better to use the native checkbox than to use a div element with role checkbox as these should already be accessible through your browser. There may also be cases where ARIA can augment an existing element in the host language. For example, a grid and gridcells can reuse the functionality of a table when overlaying it. ARIA roles, states, and properties are best used when the markup language does not support all the semantics required. When a role attribute is added to an element, the semantics and behavior of the element are overridden by the role behavior.

2. Apply the appropriate roles from ARIA

   Set roles to make sure elements behave predictably and correctly describe the behavior of each element within the application (unless elements behaviors are fully described by the native markup language). Roles for interactive elements should support all the states that the element could use. Once a role attribute is set it should not be changed as this will confuse an assistive technology. This does not preclude a document element being removed which has the role attribute set. Only states and properties may be changed for a given document element.

3. Preserve semantic structure

   Structural information is critical to providing context to people with disabilities. This is achieved through preserving DOM hierarchy within structural elements and widgets; forming logical groups within within user interface widgets such as treeitems in a group. Look for groups within a page, and mark them using the most appropriate role that best describes their usage. For example: a region of the page that contains a group of elements that are likely to change through an Ajax application could be tagged as a region. The preservation of semantic web structure involves your entire web page such as through the use of document landmarks to facilitate keyboard navigation for screen reader and mobility impaired users as well as page restructuring and simplification for users with cognitive and learning impairments.

4. Build relationships

   Look for relationships between elements, and mark them using the most appropriate property or attribute. For example: If container A contains search results, and container B contains the search controls, then mark each container as a region and set the controls property in region B to reference region A. See relationships in WAI-ARIA.

   Some relationships are determined automatically from the host language, such as by using the label tag in HTML.

5. Set states and properties in response to events

   Once the role for an element has been set, select the appropriate states and properties for that role during the element's life cycle. This is often done in response to user input events. States are special properties for widgets that may change frequently during a widget's life cycle due to user interaction, while properties are more stable attributes of objects. User agents should notify assistive technology of state changes. Conversely, assistive technology notification of property changes depends on the method by which an assistive technology communicates with the user agent. For example, the multiline property is not something that changes frequently, whereas the checked state changes frequently in response to user input.

   When setting states and properties, set them until the behavior of the element is fully defined. Only use those supported for the chosen role or document element as defined in this specification.

6. Support full, usable keyboard navigation

   Usable keyboard navigation in a rich internet application is different from the tabbing paradigm in a static document. Rich internet applications behave more like desktop applications where the user tabs to significant widgets and uses the arrow keys to navigate within the widget, such as a spreadsheet or menu. The changes that ARIA introduces in keyboard navigation makes this enhanced accessibility possible. For a more in-depth understanding of keyboard navigation in ARIA, see the ARIA Best Practices [ARIA-PRACTICES]

7. Synchronize the visual UI with accessibility states and properties for supporting user agents

   This will allow the state of your UI to be perceivable to the user as well as the assistive technology. There are many ways to do this using script or by using CSS attribute selectors (in conforming user agents) For example, the author should have an associated selector that responds to a form element being required or a gridcell being selected. Refer to the ARIA Best Practices [ARIA-PRACTICES] for techniques for proper UI synchronization with the accessible state of the document.

2.4 Example: building a tree widget

A basic tree view allows the user to select different list items and expand and collapse embedded lists. Arrow keys are used to navigate through a tree, including left/right to collapse/expand sub trees. Double clicking with the mouse also toggles expansion.

Building this user interface element with script could leave assistive technology guessing about the role of each element. To make this feature accessible we need to:

• Inform assistive technology about the role of each element, so they know how to handle it;
• Inform assistive technology about the relationships between tree items;
• Give a clear keyboard focus that will not confuse users with disabilities;
• Expose the changing states (e.g., open and closed) of the the tree items.

We can do that by following the steps below:

1. Look at the native mark up language

   There is no tree element in HTML that supports our behavior including expansion. If such an element existed, we should use that to take advantage of existing support. Since it does not, we will need to use roles.

2. Finding the right roles

   As we did not find a tree element in the native mark up we need to add roles that do this by referencing roles from this taxonomy that support states that we need.

   Our tree will need roles that support embedded list behavior and expandable/collapsible embedded lists. The roles that support tree behavior for a tree are:

   • tree: A tree is the main container element for our tree. It is a form of a select where subtrees can be collapsed and expanded.
   • treeitem: A treeitem is an option item of a tree. This is an element within a tree which may be expanded or collapsed.
3. Look for groups and build relationships

   Tree relationships can be made simply via the DOM and logical structure of the page. A tree element will be the main container encompassing all other elements in the tree. Each selectable item in the tree will be a treeitem.

   When a treeitem contains an embedded list of treeitems they will be all embedded in a group. A group should be contained inside the tree item that is the parent item.

   Tree relationships are like list relationships in HTML. Group and tree elements act like list containers (OL and UL). A tree item acts like a list item (li) in HTML.

   Because treeitems and groups commonly both use div elements it is recommended to add a comment next to closing treeitems that contain embedded tree groups.

   <div role="tree" >
     <div role="treeitem" >Veggies
       <div role="group">
         <div role="treeitem">Green
           <div role="group">
             <div role="treeitem">Asparagus</div>
             <div role="treeitem">Kale</div>
             <div role="treeitem" >Leafy
               <div role="group">
                 <div role="treeitem">Lettuce</div>
                 <div role="treeitem">Kale</div>
                 <div role="treeitem">Spinach</div>
                 <div role="treeitem">Chard</div>
               </div>
             </div> ---close leafy
             <div role="treeitem">Green beans</div>
           </div>
         </div> ---close green
         <div role="treeitem">Legumes</div>
         <div role="treeitem" >Yellow
           <div role="group">
             <div role="treeitem">Bell peppers</div>
             <div role="treeitem">Squash</div>
           </div>
         </div> ---close yellow
       </div>
     </div> ---close veggies
   </div> ---close tree

   Sometimes a tree structure is not explicit via the DOM and logical structure of a page. In such cases the relationships must still be made explicit using the States and Properties Module.

   Example:

   <div role="treeitem" aria-haschild="yellowtreegroup">Yellow<div>
   …
   <div id="yellowtreegroup" role="group">
   <div role="treeitem">Bell peppers</div>
   <div role="treeitem">Squash</div>
   …
   </div>

4. Use States, Properties in response to events

   Control the behavior of the element in response to user in put events such as from the keyboard and the mouse as shown here:

   <div tabindex="-1" role="treeitem" aria-expanded="true"
         onclick="return toggleExpansion(event)"
         onkeydown="return processArrowKeystoToggleExpansion(event);"
         onkeypress="return processArrowKeystoToggleExpansion(event);"
   >Yellow</div>

   And use device independent events with supporting JavaScript to handle user interaction.

   <div role="tree" tabindex="-1"
     onfocus="return treeItemFocus(event);"
     onclick="return treeItemEvent(event);"
     ondblclick="return treeItemEvent(event);"
     onkeydown="return treeItemEvent(event);"
     onkeypress="return treeItemEvent(event);">

   Then create JavaScript support to control the event driven behavior of the application.

3.1 Relationships between concepts

This section is normative.

The role taxonomy uses the following relationships to relate ARIA roles to each other and to concepts from other specifications, such as HTML and XForms.

3.2 Role Characteristics

This section is normative.

Roles are defined and described by their characteristics. Characteristics define the structural function of a role, such as what a role is, concepts behind it, what instances of the role can or must contain. In the case of widgets this also includes how it interacts with the user agent based on mapping to HTML forms and XForms. States and properties from WAI-ARIA that are supported by the role are also indicated.

The Roles Taxonomy defines the following characteristics. These characteristics are implemented in RDF as properties of the OWL classes that describe the roles.

3.3 Global States and Properties

This section is normative.

Some states and properties are applicable to all roles, and most are applicable to all elements regardless of role. In addition to explicitly expressed supported states and properties, the following global states and properties are supported by all roles as well. These include:

• datatype
• describedby
• dropeffect
• flowto
• grab
• haspopup
• hidden
• labelledby
• owns
• tabindex

Global states and properties are applied to the role roletype, which is the base role, and therefore inherit into all roles. To facilitate reading, they are not explicitly identified as either supported or inherited states and properties in the specification. Instead, the inheritance is indicated by a link to this section.

3.4 Roles

This section is normative.

To support the current user scenario, this specification defines roles that A, help define Widgets (For example, a tristate Checkbox) and B, help define page structure (for example, a section header).

Class diagram of the relationships described in the role data model

View larger version of class diagram

Roles are categorized as follows:

1. Taxonomy Roles
2. User Input Controls
3. User Interface Elements
4. Document Structure
5. Specialized Regions

Below is an alphabetical list of ARIA roles to be used by rich internet application authors (excluding abstract roles which are not used directly). A detailed definition of the taxonomy supporting these ARIA roles follows.

3.4.2 User Input Controls

Roles in this section include:

• input
• select
• listbox
• combobox
• option
• checkbox
• radio
• radiogroup
• textbox
• range
• spinbutton

Role: input

Generic type for widgets that can have a value.

Characteristics:

Is Abstract:	True
Parent Role:	widget
Child Roles:	select option textbox range
Base Concept:
Related Concepts:	XForms input
Supported States and Properties:	invalid required
Inherited States and Properties:	controls disabled Global States
Name From:	author
Accessible Name Required:
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: select

A form control that allows the user to make selections from a set of choices. A select must contain an option.

Characteristics:

Is Abstract:	True
Parent Role:	composite group input
Child Roles:	listbox combobox radiogroup menu tree
Base Concept:
Related Concepts:
Supported States and Properties:
Inherited States and Properties:	activedescendant atomic busy channel controls disabled expanded invalid live relevant required templateid Global States
Name From:	author
Accessible Name Required:
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: listbox

A list box is a widget that allows the user to select one or more items from a list. Items within the list are static and may contain images. List boxes contain children whose role is option.

Characteristics:

Is Abstract:
Parent Role:	list select
Child Roles:
Base Concept:
Related Concepts:	HTML select XForms select
Parent Element:
Required Child Elements:	option
Supported States and Properties:	multiselectable
Inherited States and Properties:	activedescendant atomic busy channel controls disabled expanded invalid level live relevant required templateid Global States
Name From:	author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: combobox

Combobox is a presentation of a select, where users can type to locate a selected item.

Combobox is the combined presentation of a single line textbox with a drop down select widget. The combobox may be open or closed. An "open" combobox allows users to type freeform text into the textbox whereas a "closed" combobox only shows text in the textbox which can be retrieved from the select. Typically a "closed" text field will use the text entered to quickly search and fill the textfield with text from the select.

NOTE: In XForms [XFORMS] the same select can have one of 3 appearances: combo-box, drop-down box or group of radio-buttons. Besides, many browsers (if not all of them) allow users to type in a drop-down select as well.

Characteristics:

Is Abstract:
Parent Role:	select
Child Roles:
Base Concept:
Related Concepts:	HTML select XForms select
Parent Element:
Required Child Elements:	option
Supported States and Properties:	autocomplete
Inherited States and Properties:	activedescendant atomic busy channel controls disabled expanded invalid live relevant required templateid Global States
Name From:	author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: option

A selectable item in a list represented by a select.

An option must appear inside an element with select role.

Characteristics:

Is Abstract:
Parent Role:	input
Child Roles:	checkbox menuitem treeitem
Base Concept:	HTML option
Related Concepts:	listitem XForms item
Parent Element:	select
Required Child Elements:
Supported States and Properties:	checked selected
Inherited States and Properties:	controls disabled invalid required Global States
Name From:	subtree author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: checkbox

A control that has three possible values, (true, false, mixed).

Many checkboxes do not use the mixed value, and thus are effectively boolean checkboxes. However, the checked state supports the "mixed" value to support cases such as installers where an option has been partially installed.

Characteristics:

Is Abstract:
Parent Role:	option
Child Roles:	radio menuitemcheckbox
Base Concept:
Related Concepts:	HTML input (type : checkbox)
Parent Element:
Required Child Elements:
Supported States and Properties:
Inherited States and Properties:	checked controls disabled invalid required selected Global States
Name From:	subtree author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: radio

A radio is an option in single-select list. Only one radio control in a radiogroup can be selected at the same time.

Characteristics:

Is Abstract:
Parent Role:	checkbox
Child Roles:	menuitemradio
Base Concept:
Related Concepts:	HTML input (type : radio)
Parent Element:
Required Child Elements:
Supported States and Properties:
Inherited States and Properties:	checked controls disabled invalid required selected Global States
Name From:	subtree author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: radiogroup

A group of radio controls.

Characteristics:

Is Abstract:
Parent Role:	select
Child Roles:
Base Concept:
Related Concepts:	list
Parent Element:
Required Child Elements:	radio
Supported States and Properties:
Inherited States and Properties:	activedescendant atomic busy channel controls disabled expanded invalid live relevant required templateid Global States
Name From:	author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: textbox

Inputs that allow free-form text as their value.

If the multiline property is true, the control accepts line breaks within the input, as in a HTML textarea. Otherwise this is a simple text box.

Intended use is in languages that do not have a text input object (such as SVG), or cases in which an element with different semantics is repurposed as an input box. The user would use this role when additional states or properties are applied to a standard text input control. This is to indicate to the user agent that it must process additional states and properties such as invalid and required.

Characteristics:

Is Abstract:
Parent Role:	input
Child Roles:
Base Concept:
Related Concepts:	XForms input HTML textarea
Supported States and Properties:	autocomplete multiline readonly secret
Inherited States and Properties:	controls disabled invalid required Global States
Name From:	author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: range

Represents a range of values that can be set by the user.

Characteristics:

Is Abstract:	True
Parent Role:	input
Child Roles:	spinbutton slider
Base Concept:
Related Concepts:
Supported States and Properties:	valuemax required valuemin required valuenow required
Inherited States and Properties:	controls disabled invalid required Global States
Name From:	author
Accessible Name Required:
Inherits Name Required:
Children Presentational:
Inherits Presentational:

---

Role: spinbutton

A form of Range that expects a user selecting from discrete choices.

A spinbutton allows the user to select from the given range through the use of an up and down button. Visibly, the current value is incremented or decremented until a maximum or minimum value is reached. This functionality should be accomplished programmatically through the use of up and down arrows on the keyboard.

Characteristics:

Is Abstract:
Parent Role:	composite range
Child Roles:
Base Concept:
Related Concepts:
Parent Element:
Required Child Elements:
Supported States and Properties:
Inherited States and Properties:	activedescendant controls disabled invalid required valuemax valuemin valuenow Global States
Name From:	author
Accessible Name Required:	True
Inherits Name Required:
Children Presentational:
Inherits Presentational: