Roles for Accessible Rich Internet Applications (WAI-ARIA Roles) 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 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.

1.2 Terms and Definitions

This section is informative.

While some terms are defined in place, the following definitions are used throughout this document. Familiarity with W3C XHTML 1.1 Recommendation [XHTML] and the W3C XML 1.0 Recommendation [XML] is highly recommended to understand these definitions.

Accessibility API

Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technology. Assistive technology uses these interfaces to get information about and interact with those controls. Examples of this are the Java Accessibility API [JAPI], Microsoft Active Accessibility [MSAA], Apple Accessibility for COCOA [AAC], the Gnome Accessibility Toolkit (ATK) [GAP], and IAccessible2 [IA2].

Assistive Technology

Hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide services to meet the requirements of users with disabilities that go beyond those offered by the mainstream user agents.

Services provided by assistive technology include alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.

Examples of assistive technologies that are important in the context of this document include the following:

• screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
• screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
• text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
• voice recognition software, which may be used by people who have some physical disabilities;
• alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use headpointers, single switches, sip/puff and other special input devices.);
• alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations

Attribute

In this specification, attribute is used as it is in markup languages. Attributes are structural features added to elements to provide information about the states and properties of the object represented by the element.

Characteristic

An assertion which can be a constraint.

Class

An abstract type of object.

Element

In this specfication, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for objects.

Event

A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object.

Namespace

A collection of related names. Qualifying a name in terms of the namespace to which it belongs allows these names to be distinguished from names in other namespaces that are spelled alike. Namespaces in this document are used in accordance with Namespaces in XML [XML-NAMES].

Object

A "thing" in the perceptual user experience, instantiated in markup languages by one or more elements, and converted into the object-oriented pattern by user agents. Objects are instances of abstract classes, which defines the general characteristics of object instances. A single DOM object may or may not correspond with a single object in accessibility API. An object in accessibility API encapsulates one ore more DOM objects.

Property

Attributes that are essential to the nature of a given object. As such, they are less likely to change than states; a change of a property may significantly impact the meaning or presentation of an object. Properties mainly provide limitations on objects from the most general case implied by roles without properties applied.

Relationship

A fact connecting two distinct, articulable things. Relationships may be of various types to indicate which object labels another, controls another, etc.

Role

An indicator of type. The object's role is the class of objects of which it is a member. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

State

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.

User Agent

Any software that retrieves and renders Web content for users, such as Web browsers, media players, plug-ins, and other programs including assistive technologies that help retrieve and render Web content.

Value

A literal that concretizes the information expressed by a state or property.

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

2.1 Introduction to using roles

This section is informative.

Complex user interfaces become inaccessible because assistive technologies that provide alternative access, are often left guessing at the semantics behind portions of a document (see the Roadmap for Accessible Rich Internet Applications [ARIA-ROADMAP]). Associating an element in the document to a role in this taxonomy associates all the information about that role that has been defined in this specification.

Roles defined in this specification descend from and complement the roles defined in the XHTML Role Attribute Module [XHTML-ROLES].

Roles in this specification are defined with RDF/OWL to build rich description of the expected behaviors of the role. For example:

• The roles taxonomy describes what states are supported for each role. For example, a checkbox supports being checked.
• 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 inheritence similar to any class hierarchy.
• The role taxonomy makes references to related concepts in other specifications.
• The role taxonomy provides descriptions for each role.

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

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

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
    xmlns:aaa="http://www.w3.org/2005/07/aaa" >
  <head></head>
  <body>
    
    <span class="checkbox" id="chbox1" role="wairole:checkbox"  aaa:checked="mixed"
        onkeydown="return checkBoxEvent(event);" onclick="return checkBoxEvent(event);" tabindex="0" >
      A checkbox label
    </span>
    
  </body>
</html>

2.2 Building Accessible Applications with Roles

This section provides a brief introduction to the process of making applications accessible using the ARIA Roles specification. The choice and usage of roles can be complex and context dependent. It is beyond the scope of this document to explain all possible use cases. ARIA Best Practices will provide expanded usage recommendations.

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.

Roles make the different elements in the application semantically rich. User agents use the role semantics to understand how to handle each element. Roles can be used to build accessible applications by providing any missing information that the assistive technology needs to anticipate the behavior of the elements inside the application.

2.3 Example: building a tree view in XHTML 1.0

This section is informative.

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:

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

<div role="wairole:treeitem" aaa:haschild="yellowtreegroup">Yellow<div>
…
<div id="yellowtreegroup" role="wairole:group">
<div role="wairole:treeitem">Bell peppers</div>
<div role="wairole:treeitem">Squash</div>
…
</div>

<div tabindex="-1" role="wairole:treeitem" aaa:expanded="true">Yellow</div>

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

2.4 Applying roles to documents

This section is informative.

Roles are provided in XML-based languages using an attribute designated for the purpose. Roles from this ontology are indicated as values of that role attribute. In order to indicate that the roles are used as specified in this document, the document must use the following namespace in the attribute value: http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#.

Generally this namespace is declared on the root element of the document as specified in XML Namespaces [XML-NAMES]. Examples in this document use the namespace prefix “wairole” to indicate this namespace.

For example, the start tag of a root element that includes the appropriate namespace declaration might look like:

<html xmlns="http://www.w3.org/1999/xhtml"
    xml:lang="en"
    xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
>

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml
"xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"><body>

<table id="table1" role="wairole:grid">

</table>

</body></html>

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:xhtml10="http://www.w3.org/1999/xhtml"
xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"><body>

<table id="table1" xhtml10:role="wairole:grid">

</table>
</body></html>

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
>

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.

Editorial note: The information below is presented with details arranged in a data table. Concerns about accessibility of this have been raised. An experimental alternate presentation is provided in Relationships between concepts in list form, using definition lists instead of tables to organize the details. We appreciate feedback about which form is more effective, or proposals for other forms.

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 ARIA States and Properties 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.

Editorial note: The information below is presented with details arranged in a data table. Concerns about accessibility of this have been raised. An experimental alternate presentation is provided in Role characteristics in list form, using definition lists instead of tables to organize the details. We appreciate feedback about which form is more effective, or proposals for other forms.

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

Editorial note: The roles below are presented with details arranged in a data table. Concerns about accessibility of this have been raised. An experimental alternate presentation is provided in Role details in list form, using definition lists instead of tables to organize the details. We appreciate feedback about which form is more effective, or proposals for other forms.

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

These roles ...

Roles in this section include:

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

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

Characteristics:

Is Abstract:
Parent Role:	list select
Child Roles:
Base Concept:
Related Concepts:	HTML select XForms select
Parent Element:
Required Child Elements:
Supported States and Properties:	multiselectable
Inherited States and Properties:	activedescendent 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] 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:	activedescendent 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