W3C

Accessible Rich Internet Applications (WAI-ARIA) Version 1.0

W3C Working Draft 4 February 2008

This version:
http://www.w3.org/TR/2008/WD-wai-aria-20080204/
Latest version:
http://www.w3.org/TR/wai-aria/
Editors:
Lisa Seeman, UB Access
Michael Cooper, W3C
Rich Schwerdtfeger, IBM
Lisa Pappas, SAS

Abstract

Accessibility of Web content to people with disabilities requires semantic information about widgets, structures, and behaviors, in order to allow Assistive Technologies to make appropriate transformations. This specification provides an ontology of roles, states, and properties that set out an abstract model for accessible interfaces and can be used to improve the accessibility and interoperability of Web Content and Applications. This information can be mapped to accessibility frameworks that use this information to provide alternative access solutions. Similarly, this information can be used to change the rendering of content dynamically using different style sheet properties. The result is an interoperable method for associating behaviors with document-level markup. This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a First Public Working Draft by the Protocols & Formats Working Group of the Web Accessibility Initiative. This is a single specification that combines the two previously-published ARIA draft specifications, Roles for Accessible Rich Internet Applications (WAI-ARIA Roles) and the States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties). The interdependencies between those two documents required familiarity with both to understand either, and combining them eliminates the redundancies that were necessary to support them as standalone specifications.

The Working Group believes that development of this specification is mostly complete. This draft is being published to allow for public review prior to entering finalization stages and to support ongoing discussion with other Working Groups about the impact of this specification on other W3C technologies. Refer to the history of changes to WAI-ARIA Roles and to the history of changes to WAI-ARIA States and Properties for more details.

The content of the WAI-ARIA specification depends on specialized knowledge of assistive technology and accessibility APIs. To facilitate understanding and implementation, there are two companion documents: WAI-ARIA Primer [ARIA-PRIMER], and WAI-ARIA Best Practices [ARIA-PRACTICES]. The WAI-ARIA Primer provides a basic introduction to the concepts behind and reason for ARIA, and the WAI-ARIA Best Practices describe recommended usage patterns for Web content developers. Please consider these documents as one of the potential places of clarification where topics appear to be unclear. Note, however, that only this specification is intended to become a W3C Recommendation and therefore is the only one that is normative for implementations.

Feedback on the model set out here is important to the success of the Web community in creating accessible Rich Internet Applications. The PFWG would like to know, in particular:

When addressing these questions, please consider them in the context of the companion documents. Comments on this document may be sent to public-pfwg-comments@w3.org (Archive). Comments should be made by 3 March 2008. If possible, the Working Group requests that comments be made by 20 February 2008 to facilitate handling of comments at a scheduled meeting. However, comments arriving after that date will still be considered.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The disclosure obligations of the Participants of this group are described in the charter.

Table of Contents

  1. 1 Introduction
    1. 1.1 About This Draft
    2. 1.2 Use Cases
    3. 1.3 Design Aims
  2. 2 Using WAI-ARIA
    1. 2.1 WAI-ARIA Roles
    2. 2.2 WAI-ARIA States and Properties
    3. 2.3 Building Accessible Applications with WAI-ARIA
    4. 2.4 Example: building a tree widget
  3. 3 The RDF Roles Model
    1. 3.1 Relationships between concepts
    2. 3.2 Role Characteristics
    3. 3.3 Global States and Properties
    4. 3.4 Roles
      1. 3.4.1 Base Types
      2. 3.4.2 User Input Controls
      3. 3.4.3 User Interface Elements
      4. 3.4.4 Document Structure
      5. 3.4.5 Specialized Regions
      6. 3.4.6 Landmark Roles Inherited from the XHTML Role Attribute Module
  4. 4 Supported States and Properties
    1. 4.1 Characteristics of States and Properties
    2. 4.2 Definitions for States and Properties
      1. 4.2.1 Widget states and properties
      2. 4.2.2 Live Regions
      3. 4.2.3 Drag and Drop
      4. 4.2.4 Focus
      5. 4.2.5 Relationships
      6. 4.2.6 User interface properties
  5. 5 Implementation in Host Languages
    1. 5.1 Implementation in HTML and other markup languages without requiring namespace support
    2. 5.2 Implementation using namespaces
      1. 5.2.1 The States and Properties Module
      2. 5.2.2 Using ARIA in other Namespace-aware XML Languages
  6. 6 Conformance Requirements
    1. 6.1 Document Conformance
    2. 6.2 User Agent Conformance
  7. 7 Appendices
    1. 7.1 Implementations
      1. 7.1.1 Roles Implementation
      2. 7.1.2 Qualified Names Module
      3. 7.1.3 ELEMENTS XHTML 1.1 For Accessible Adaptable Applications DTD
      4. 7.1.4 XHTML 1.1 For Accessible Adaptable Applications DTD
    2. 7.2 Glossary
    3. 7.3 References
    4. 7.4 Acknowledgments
      1. 7.4.1 Participants active in the PFWG at the time of publication
      2. 7.4.2 Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification
      3. 7.4.3 Enabling funders

1 Introduction

This section is informative.

The domain of Web accessibility defines how to make Web content usable by people with disabilities. People with some types of disabilities use Assistive Technology (AT) to interact with content. AT can transform the presentation of content into a format more suitable to the user, and can allow the user to interact in different ways than the author designed. In order to accomplish this, AT must understand the semantics of the content. Semantics are knowledge of roles, states, and properties, as a person would understand them, that apply to elements within the content. For instance, if a paragraph is semantically identified as such, AT can interact with it as a unit separable from the rest of the content, knowing the exact boundaries of that paragraph. A slider or tree control is a more complex example, in which various parts of a widget each have semantics that must be properly identified for the computer to support effective interaction.

Established content technologies define semantics for elements commonly used in those technologies. However, new technologies can overlook some of the semantics required for accessibility. Furthermore, new authoring practices evolve which override the intended semantics—elements that have one defined semantic meaning in the technology are used with a different semantic meaning intended to be understood by the user.

For example, Rich Internet Applications developers can create a tree control in HTML using CSS and JavaScript even though HTML lacks a semantic element for that. A different element must be used, possibly a list element with display instructions to make it look and behave like a tree control. Assistive technology, however, must re-present the element in a different modality and the display instructions may not be applicable. The AT will present it as a list, which has very different display and interaction from a tree control, and the user may be unsuccessful at understanding and operating the control.

The incorporation of Roles for Accessible Rich Internet Applications is a way for an author to provide proper type semantics on custom widgets (elements with repurposed semantics) to make these widgets accessible, usable and interoperable with assistive technologies. This specification identifies the types of widgets and structures that are recognized by accessibility products, by providing an ontology of corresponding roles that can be attached to content. This allows elements with a given role to be understood as a particular widget or structural type regardless of any semantic inherited from the implementing technology. Roles are a common property of platform Accessibility APIs which applications use to support assistive technologies. Assistive technology can then use the role information to provide effective presentation and interaction with these elements.

This role taxonomy currently includes interaction widget (user interface controls) and structural document (content organization) objects. The role taxonomy describes inheritance (widgets that are types of other widgets) and details what states and properties each role supports. When possible, information is provided about mapping of roles to accessibility APIs.

Roles are element types and should not change with time or user actions. Changing the role on an element from its initial value will confuse an assistive technology. Platform accessibility APIs, to which the roles are mapped by the browser, do not provide a vehicle to notify the assistive technology of a role type changing. If the old element type is be replaced by a new one, the corresponding element and its subtree should be removed from the document and a new one inserted containing the new role type.

Changeable states and properties of elements are also defined in this specification. States and Properties are used to declare important properties of an element that affect and describe interaction. These properties enable the user agent or operating system to properly handle the element even when these properties are altered dynamically by scripts. For example, alternative input and output technology such as screen readers, speech dictation software and on-screen keyboards must recognize the state of an element (such as: if an object is disabled, checked, focused, collapsed, hidden, etc.).

While it is possible for assistive technologies to access these properties through the Document Object Model [DOM], the preferred mechanism is for the user agent to map the States and Properties to the accessibility API of the operating system.

Figure 1.0 illustrates a typical Document Object Model (DOM) [DOM] node. Placed within 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 of our accessible platforms for GUIs (role, state, caret, selection, event notification, parent/child information, relationship, and descriptions).

The contract model with accessibility APIs

Figure 1: The contract model with accessibility APIs

For more information see the Roadmap for Accessible Rich Internet Applications for the use of roles in making interactive content accessible.

In addition to the prose documentation, the role taxonomy is provided in Web Ontology Language (OWL) [OWL], which is an implementation of Resource Description Framework (RDF) [RDF]. Tools can use these to validate the implementation of roles in a given content document.

Note: the use of RDF/OWL as a formal representation of roles is intended to support future extensibility. Standard RDF/OWL mechanisms can be used to define new roles that inherit from the roles defined in this specification. The mechanism to define and use role extensions in an interoperable manner, however, is not defined by this specification. A future version of ARIA Roles is expected to define how to extend roles.

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:

2 Using WAI-ARIA

This section is informative.

Complex web applications become inaccessible when assistive technologies cannot determine the semantics behind portions of a document or when the user is unable to effectively navigate to all parts of it in a usable way (see the Roadmap for Accessible Rich Internet Applications [ARIA-ROADMAP]). ARIA divides the semantics into roles (the type defining a user interface element) and states and properties supported by the roles.

Authors must associate elements in the document to an ARIA role and the appropriate attributes (states and properties) during its lifecycle.

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:

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

picture of a tree view

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:

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 The RDF Roles Model

This section is normative.This specification defines a Taxonomy called Roles. The remainder of this section describes the properties of roles in this taxonomy, and describes the characteristics of all roles. A formal RDF representation of all the information presented here is available in Appendix 6.1: Implementation.

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.

Relationships Supported by Role Taxonomy
Relationship RDF Property Description
Parent Role rdfs:subClassOf

The role that this role extends in the taxonomy. This extension causes all the properties and constraints of the parent role to propagate to the child role. Other than well known stable specifications, inheritance may be restricted to items defined inside this specification so that items can not be changed and affect inherited classes.

For example: buttonundo is a subclass or type of a button. If we change the properties and expected behavior of a button then the properties and behavior of buttonundo will also change.

Inheritance is expressed in RDF using the RDF Schema subClassOf ([RDFS], section 3.4) property.

Child Roles   Informative list of roles for which this role is the parent. This is provided to facilitate reading of the specification but adds no new information as the list of child roles is the list of roles for which the current role is the parent.
Related Concepts role:relatedConcept

A relatedConcept is a similar or related idea from other specifications. Concepts that are related are not necessarily identical. relatedConcepts do not inherit properties from each other. Hence if the definition of a type changes, the properties, behavior and definition of a relatedConcept is not affected.

For example: A grid is like a table. Therefore, a grid has a relatedConcept of a table as defined at http://www.w3.org/TR/html4/struct/tables.html#edef-TABLE. However if the definition of table is modified our definition of a grid will not be affected.

Base Concept role:baseConcept

A baseConcept is like a "borrowed" concept. BaseConcept is similar to type, but without inheritance of limitations and properties. baseConcepts are designed as a substitute for inheritance for external concepts. A baseConcept is like a relatedConcept except that baseConcepts are almost identical to each other.

For example: the checkbox defined in this document has the same functionality and anticipated behavior as a checkbox defined in http://www.w3.org/MarkUp/HTML#checkbox.

Therefore, a checkbox has a baseConcept of a checkbox as defined at http://www.w3.org/MarkUp/HTML#checkbox. However, if http://www.w3.org/MarkUp/HTML#checkbox is modified, the definition of a checkbox in this document will not be not affected.

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.

Characteristics Supported by Role Taxonomy
Characteristic RDF Property Description Values
Is Abstract N/A This role is abstract and cannot be used by authors directly. It is used to create a relationship amongst descendant roles. Boolean
Supported States and Properties

role:supportedState

A supportedState must be supported by this role. Typically refers to states from the aaa namespace.

Supported states and properties are inherited from ancestor roles and are shown informatively as Inherited States in this specification. States and properties are inherited from ancestor roles in the role taxonomy, not from ancestor elements in the DOM tree.

Any valid RDF object reference, such as a URI or RDF ID reference.

Inherited States and Properties   Informative list of properties that are inherited onto a role from ancestor roles. These properties are not explicitly defined on the role as the inheritance of properties is automatic. This information is provided to facilitate reading of the specification. The set of supported states and properties combined with inherited states and properties forms the full set of states and properties supported by the role.  
Required Child Elements

role:mustContain

A child element that must be contained by this role. For example a list must contain a listitem.

When multiple required children are indicated, either of them are permitted.

Any valid RDF object reference, such as a URI or RDF ID reference.

Parent Element

role:scope

Context, where this role is allowed. For example a list item is allowed inside a list.

Any valid RDF object reference, such as a URI or RDF ID reference.
Name From

role:nameFrom

Computational mechanism to determine the accessible name of the object to which the role applies. This may be computed from the children of the object or the title attribute.

Computing the accessible name:

Collect the name from the content subtrees pointed to by labelledby which contains the IDs for the label content. Use the labelledby IDs in order. For each ID use a depth-first computation of the name, appending to the currently computed name.

If labelledby is unspecified:

  1. For container elements which allow name from descendants, use a depth-first computation of the name.
    1. If a text node, append the text contents;
    2. If a control, append the current value for the control;
    3. If an image or object with a text equivalent, append the text equivalent;
    4. If there is a forced line break (e.g. if the current object is styled with display:block), append a space character.
  2. If not such a container, or the descendant computation generated an empty name, use the contents of the title attribute, if specified.

One of the following values:

  • "author": name comes from values provided by the author in explicit markup features such as the labelledby property or the HTML "title" attribute.
  • "subtree": name comes from the text value of the element node. Although this may be allowed in addition to "author" in some roles, this is used in content only if "author" features are not provided.
Children Presentational role:childrenArePresentational The children are presentational. Assistive technologies may choose to hide the children from the user, in order to avoid confusing third party APIs using accessibility APIs. If assistive technologies do not hide the children, user agents may read some information twice.

Boolean (true | false)

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:

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

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.

RoleDefinition
alertA message with an alert or error information.
alertdialogA separate window with an alert or error information.
applicationA software unit executing a set of tasks for its users.
bannerA banner is usually defined as the advertisement at the top of a web page. The banner content typically contains the site or company logo and other key advertisements for the site.
buttonAllows for user-triggered actions.
checkboxA control that has three possible values, (true, false, mixed).
columnheaderA table cell containing header information for a column.
comboboxCombobox is a presentation of a select, where users can type to locate a selected item.
contentinfoThis is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.
definitionThe contents of the associated element represent a definition (e.g., of a term or concept). If there is a dfn element within the contents, then that represents the term being defined. Todo: not sure this is clear
descriptionDescriptive content for a page element which references this element via describedby.
dialogA dialog is a small application window that sits above the application and is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response.
directoryA list of references to members of a single group.
documentContent that contains related information, such as a book.
gridA grid contains cells of tabular data arranged in rows and columns (e.g., a table).
gridcellA gridcell is a table cell in a grid. Gridcells may be active, editable, and selectable. Cells may have relationships such as controls to address the application of functional relationships.
groupA group is a section of user interface objects which would not be included in a page summary or table of contents by an assistive technology. See region for sections of user interface objects that should be included in a page summary or table of contents.
headingA heading for a section of the page.
imgAn img is a container for a collection elements that form an image.
linkInteractive reference to a resource (note, that in XHTML 2.0 any element can have an href attribute and thus be a link)
listGroup of non-interactive list items. Lists contain children whose role is listitem.
listboxA 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.
listitemA single item in a list.
logA region where new information is added and old information may disappear such as chat logs, messaging, game log or an error log. In contrast to other regions, in this role there is a relationship between the arrival of new items in the log and the reading order. The log contains a meaningful sequence and new information is added only to the end of the log, not at arbitrary points.
mainThis defines the main content of a document.
marqueeA marquee is used to scroll text across the page.
menuOffers a list of choices to the user.
menubarA menubar is a container of menu items. Each menu item may activate a new sub-menu. Navigation behavior should be similar to the typical menu bar graphical user interface.
menuitemA link in a menu. This is an option in a group of choices contained in a menu.
menuitemcheckboxDefines a menuitem which is checkable (tri-state).
menuitemradioIndicates a menu item which is part of a group of menuitemradio roles.
navigationThis is a collection of links suitable for use when navigating the document or related documents.
noteThe content is parenthetic or ancillary to the main content of the resource.
optionA selectable item in a list represented by a select.
presentationAn element whose role is presentational does not need to be mapped to the accessibility API.
progressbarUsed by applications for tasks that take a long time to execute, to show the execution progress.
radioA radio is an option in single-select list. Only one radio control in a radiogroup can be selected at the same time.
radiogroupA group of radio controls.
region Region is a large perceivable section on the web page.
rowA row of table cells.
rowheaderA table cell containing header information for a row.
searchThis is the search section of a web document. This is typically a form used to submit search requests about the site or a more general Internet wide search service.
secondaryThis is any unique section of the document. In the case of a portal, this may include but not be limited to: show times; current weather; or stocks to watch.
seealsoIndicates that the element contains content that is related to the main content of the page.
separatorA line or bar that separates and distinguishes sections of content.
sliderA user input where the user selects an input in a given range. This form of range expects an analog keyboard interface.
spinbuttonA form of Range that expects a user selecting from discrete choices.
statusThis is a container for process advisory information to give feedback to the user.
tabA header for a tabpanel.
tablistA list of tabs, which are references to tabpanels.
tabpanelTabpanel is a container for the resources associated with a tab.
textboxInputs that allow free-form text as their value.
timerA numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.
toolbarA toolbar is a collection of commonly used functions represented in compact visual form.
tooltipA popup that displays a description for an element when a user passes over or rests on that element. Supplement to the normal tooltip processing of the user agent.
treeA form of a list having groups inside groups, where sub trees can be collapsed and expanded.
treegridA grid whose rows can be expanded and collapsed in the same manner as for a tree.
treeitemAn option item of a tree. This is an element within a tree that may be expanded or collapsed

3.4.1 Base Types

The following roles are used as base types for applied roles. Base classes are used to build a picture of the role taxonomy class hierarchy within the taxonomy. Note that while all roles in this section are abstract, not all abstract roles are in this section. This section includes only the most high-level abstractions in the taxonomy.

Roles in this section include:

Role: roletype

Base role from which all other roles in this taxonomy inherit.

Properties of this role describe the structural and functional purpose of objects that are assigned this role (known in RDF terms as "instances"). A Role is a concept that can be used to understand and operate instances.

Characteristics:
Is Abstract: True
Parent Role:  
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:
Inherited States and Properties:  
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: widget

A component of a GUI (graphical user interface).

Widget Roles all map to accessibility APIs. Widgets are ... , see @@

Characteristics:
Is Abstract: True
Parent Role: roletype
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:
Inherited States and Properties:
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: structure

A document structural element.

Roles for document structure are also required to support the accessibility of dynamic Web content to assist assistive technology in determining active content vs. static document content. Structural Roles, by themselves do not all map to accessibility APIs, but are used to create widget roles or assist content adaptation.

This schema is likely to evolve as new use cases are added to the scope of this specification.

Characteristics:
Is Abstract: True
Parent Role: roletype
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:
Inherited States and Properties:
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: composite

A widget that may contain navigable descendants.

Descendants of this role may not have the "nameFrom" value of "subtree" set.

Characteristics:
Is Abstract: True
Parent Role: widget
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties: activedescendant
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: window

Browser or application window

Characteristics:
Is Abstract: True
Parent Role: roletype
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

3.4.2 User Input Controls

Roles in this section include:

Role: input

Generic type for widgets that can have a value.

Characteristics:
Is Abstract: True
Parent Role: widget
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:
Inherited States and Properties:
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:
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: listbox
Image of 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:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements: option
Supported States and Properties: multiselectable
Inherited States and Properties:
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:
Parent Element:  
Required Child Elements: option
Supported States and Properties: autocomplete
Inherited States and Properties:
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:
Base Concept: HTML option
Related Concepts:
Parent Element: select
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
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:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
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:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
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:
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:
Supported States and Properties:
Inherited States and Properties:
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:
Base Concept:  
Related Concepts:
Supported States and Properties:
Inherited States and Properties:
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:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

3.4.3 User Interface Elements

Roles in this section include:

Role: button

Allows for user-triggered actions.

Buttons are mostly used for discrete, atomic actions. Its value is cognitive; the idea that this is a user action opportunity is made very clear by making it look like a front-panel button on a device. The animation of the button in response to indirect (by mouse) manipulation fosters the illusion of direct manipulation and keeps user cognition in sync with the user interface perception of user action events. Standardizing the appearance of buttons enhances recognition as buttons and arraying them compactly in toolbars, for example.

Buttons support the optional state pressed. Buttons with this state present are toggle buttons. When pressed is "true" the button is depressed, when pressed is "false" it is not depressed.

Characteristics:
Is Abstract:  
Parent Role: widget
Child Roles:  
Base Concept: HTML button
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties: pressed
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational: True
Inherits Presentational:  

Role: link

Interactive reference to a resource (note, that in XHTML 2.0 any element can have an href attribute and thus be a link)

Characteristics:
Is Abstract:  
Parent Role: widget
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: menu

Offers a list of choices to the user.

A menu is often a list of links to important sections of a document or a site. The menu role is appropriate when the list of links is presented in a manner similar to a menu on a desktop application.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements: menuitem
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: menubar

A menubar is a container of menu items. Each menu item may activate a new sub-menu. Navigation behavior should be similar to the typical menu bar graphical user interface.

Menubar is used to create a menubar similar to those found in Windows, the Mac, and Gnome desktops. A menubar is used to create a consistent climate of frequently used commands.

Characteristics:
Is Abstract:  
Parent Role: group
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: toolbar

A toolbar is a collection of commonly used functions represented in compact visual form.

The toolbar is often a subset of functions found in a menubar designed to reduced user effort in using these functions.

If this is not keyboard accessible the actions defined in the toolbar must be reproduced in an accessible, device independent fashion.

Characteristics:
Is Abstract:  
Parent Role: group
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties: multiselectable
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: menuitem

A link in a menu. This is an option in a group of choices contained in a menu.

It may be disabled or active. It may also have a popup.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:
Base Concept:  
Related Concepts:
Parent Element: menu
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: menuitemcheckbox

Defines a menuitem which is checkable (tri-state).

The checked state indicates whether the menu item is checked, unchecked, or mixed.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element: menu
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: menuitemradio

Indicates a menu item which is part of a group of menuitemradio roles.

Checking of one menuitemradio in a group will unchecked the other group members.

Menuitems should also be separated into a group by a separator.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element: menu
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: slider

A user input where the user selects an input in a given range. This form of range expects an analog keyboard interface.

A slider has the added functionality of being able to select a value through the use of a visible slider. The slider would be keyboard accessible and provide a visible thumb position that represents the current position within the slider.

Characteristics:
Is Abstract:  
Parent Role: range
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational: True
Inherits Presentational:  

Role: tooltip

A popup that displays a description for an element when a user passes over or rests on that element. Supplement to the normal tooltip processing of the user agent.

Objects with this role must be referenced through the use of a describedby. If the tooltip has active elements it must be keyboard navigable.

Characteristics:
Is Abstract:  
Parent Role: description
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:  
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: tabpanel

Tabpanel is a container for the resources associated with a tab.

Note: There must be a means to associate a tabpanel element with its associated tab in a tablist. Using the labelledby property on the tabpanel to reference the tab is the recommended way to achieve this.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: tablist

A list of tabs, which are references to tabpanels.

Characteristics:
Is Abstract:  
Parent Role: directory
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: tab

A header for a tabpanel.

Tab is used as a grouping label, providing a link for selecting the tab content to be rendered to the user. The currently active tab is determined if the tab or an object in the associated tabpanel has focus.

Tabs appear in the container tablist. Only one tab may be selected at a time. At any time, one tab must be selected.

One of the tabs in tablist must be the current tab. The tabpanel associated with the current tab, must be rendered to the user. Other tabpanels are typically hidden from the user until the user selects the tab associated with that tabpanel.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element: tablist
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: tree

A form of a list having groups inside groups, where sub trees can be collapsed and expanded.

Characteristics:
Is Abstract:  
Parent Role: select
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements: treeitem
Supported States and Properties: multiselectable
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: treeitem

An option item of a tree. This is an element within a tree that may be expanded or collapsed

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element: tree
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

3.4.4 Document Structure

These roles are similar to roles from the XHTML Roles Module [XHTML-ROLES]. See Introduction to using roles for more information.

Roles in this section include:

Role: section

A base abstract class representing a renderable structural containment unit found in a document or application.

Characteristics:
Is Abstract: True
Parent Role: structure
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties: templateid
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: sectionhead

The section head labels or summarizes the topic of its related section

Characteristics:
Is Abstract: True
Parent Role: structure
Child Roles:
Base Concept:  
Related Concepts:
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: document

Content that contains related information, such as a book.

The document role is used to tell the screen reader to use a document browsing mode, because screen readers use most of the keyboard navigation keys to provide their own keyboard user interface for this type of navigation.

Documents must also have an labelledby attribute leading to one or more elements with non-empty text content. This text should be suitable for use as a navigation preview or table-of-contents entry for the page section in question.

Exceptions: There may be a few exceptions where the host-language provides a useful label mechanism, such as:

  • The root element in an HTML document may omit the labelledby attribute - if the title element has been used.
  • Any group element in SVG may omit the labelledby attribute if it contains a non-empty title element.
Characteristics:
Is Abstract:  
Parent Role: structure
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: region

Region is a large perceivable section on the web page.

Region defines a group of elements that together form a large perceivable section, that the author feels should be included in a summary of page features. A region must have a heading, e.g., an instance of the heading role or a reference to an element with the labelledby property. A region does not necessarily follow the logical structure of the content, but follows the perceivable structure of the page.

When defining regions of a web page, authors should consider using standard document landmark roles defined by the XHTML Roles Module [XHTML-ROLES]. User agents and assistive technologies may treat these as standard navigation landmarks. If the definition of these regions are inadequate, authors should use the ARIA region role and provide the appropriate title text.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: heading

A heading for a section of the page.

This indicates that an object serves as a header. Often, headings will be referenced with the labelledby property of the section for which they serve as a header. If headings are organized into a logical outline, the level property can be used to indicate the nesting level.

Characteristics:
Is Abstract:  
Parent Role: sectionhead
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties: level
Inherited States and Properties:
Name From:  
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: list

Group of non-interactive list items. Lists contain children whose role is listitem.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:
Base Concept: HTML ul
Related Concepts:
Parent Element:  
Required Child Elements:
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: listitem

A single item in a list.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:
Base Concept: HTML li
Related Concepts:
Parent Element: list
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: group

A group is a section of user interface objects which would not be included in a page summary or table of contents by an assistive technology. See region for sections of user interface objects that should be included in a page summary or table of contents.

Authors should use a role of group to form logical collection of items in a widget such as a: row in a grid; children in a tree widget forming a collection of siblings in a hierarchy; or a collection of items having the same container in a directory. Therefore, proper handling of group by assistive technologies must be determined by the context in which it is provided. Group members that are outside the DOM subtree of the group would need to have explicit relationships assigned to participate in the group. Groups may also be nested. If the author believes a section is significant enough in terms of the entire delivery unit web page then the author should assign the section a role of region or a standard XHTML Role landmark.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: grid

A grid contains cells of tabular data arranged in rows and columns (e.g., a table).

This does not necessarily imply presentation.The table role is used as a container for tabular data. The table construct describes relationships between data such that it may be used for different presentations.

Grids contain cells that may be focusable. Grids allow the user to move focus between grid cells with 2-D navigation. Grids may have row and column headers which also have functional value based on the implementation. Grid cells may have values determined by an equation.

Grids are single selectable or multiselectable. Properties for selectable or multiselectable must be provided by the author. Grids may be used for spreadsheets such as in Open Office, Microsoft Office, etc.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:
Base Concept: HTML table
Related Concepts:
Parent Element:  
Required Child Elements: row
Supported States and Properties:
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: row

A row of table cells.

Characteristics:
Is Abstract:  
Parent Role: group
Child Roles:  
Base Concept: HTML tr
Related Concepts:
Parent Element:
Required Child Elements: gridcell
Supported States and Properties:
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: gridcell

A gridcell is a table cell in a grid. Gridcells may be active, editable, and selectable. Cells may have relationships such as controls to address the application of functional relationships.

Note: If the expanded property is provided, it applies only to the individual cell. It is not a proxy for the container row, which also can be expanded. The main use case for providing this property on a cell is pivot table type behavior.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:
Base Concept: HTML td
Related Concepts:
Parent Element: row
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: rowheader

A table cell containing header information for a row.

Rowheader can be used as a row header in a table or grid. It also could be used in a pie chart to show a similar relationship in the data.

The rowheader establishes a relationship between it and all cells in the corresponding row. It is a structural equivalent to an HTML th element with a row scope.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept: HTML th with scope=row
Related Concepts:
Parent Element: row
Required Child Elements:  
Supported States and Properties: sort
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: columnheader

A table cell containing header information for a column.

Columnheader can be used as a column header in a table or grid. It could also be used in a pie chart to show a similar relationship in the data.

The columnheader establishes a relationship between it and all cells in the corresponding row. It is a structural equivalent to an HTML th element with a column scope.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept: HTML th with scope=col
Related Concepts:
Parent Element: row
Required Child Elements:  
Supported States and Properties: sort
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: treegrid

A grid whose rows can be expanded and collapsed in the same manner as for a tree.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements: row
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: description

Descriptive content for a page element which references this element via describedby.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: directory

A list of references to members of a single group.

People should use this role for static tables of contents. This includes tables of contents built with lists, including nested lists. Dynamic tables of contents, however, would be a tree.

Note: directories do not have to contain links. They can have simply unlinked references.

Characteristics:
Is Abstract:  
Parent Role: list
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements: link
Supported States and Properties:  
Inherited States and Properties:
Name From:
  • subtree
  • author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: img

An img is a container for a collection elements that form an image.

An img can contain captions, descriptive text as well as multiple image files that when viewed together give the impression of a single image. An img represents a single graphic within a document whether or not it is formed by a collection of drawing objects. Elements with a role of img must have a label or alternative text.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational: True
Inherits Presentational:  

Role: presentation

An element whose role is presentational does not need to be mapped to the accessibility API.

Intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type.

Example use cases:

  • A layout table is a presentation.
  • An object tag whose content is decorative like a white space image or decorative flash object
  • An image used for white space

The user agent may remove all structural aspects of the element being repurposed. For example, a table marked as presentation would remove the table, td, th, tr, etc. elements while preserving the individual text elements within it. Because the user agent knows to ignore the structural aspects implied in a table, no harm is done by using a table for layout.

Characteristics:
Is Abstract:  
Parent Role: structure
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: separator

A line or bar that separates and distinguishes sections of content.

This is a visual separator between sections of content. For example, separators are found between lists of menu items in a menu.

Characteristics:
Is Abstract:  
Parent Role: structure
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational: True
Inherits Presentational:  

3.4.5 Specialized Regions

Roles in this section include:

Role: application

A software unit executing a set of tasks for its users.

The intent is to hint to the assistive technology to switch its normal browsing mode functionality to one in which they would for an application. To properly set the role of "application," an author should set the application role on a document element which encompasses the entirety of the web page for which assistive technology browser navigation mode is applied. Screen readers have a browse navigation mode where keys, such as up and down arrows, are consumed and used to browse the document. Consumption of these keys breaks use of these keys by the web application.

Use case: In an email application it has a document and an application in it. The author would want to use typical application navigation mode to cycle through the list of emails. Much of this navigation would be defined by the application author. However, when reading an email message the user may want to switch to a document mode where they control browsing navigation.

Applications must also have an labelledby attribute leading to one or more elements with non-empty text content. This text should be suitable for use as a navigation preview or table-of-contents entry for the page section in question.

Exceptions: There may be a few exceptions where the host-language provides a useful label mechanism, such as:

  • The root element in an HTML document may omit the labelledby attribute - if the title element has been used.

Any group element in SVG may omit the labelledby attribute if it contains a non-empty title element.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: dialog

A dialog is a small application window that sits above the application and is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response.

Dialog boxes should have a title. They must have a focused item.

Characteristics:
Is Abstract:  
Parent Role: window
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: alert

A message with an alert or error information.

Alerts are used to convey messages to alert the user. In the case of audio warnings this is an accessible alternative for a hearing impaired user. The alert role goes on the container of the document subtree containing the alert message. Alerts are specialized forms of the status role which should be processed as an atomic live region. Alerts do not require user input and therefore should not receive focus. Alerts should not receive focus or require user input and therefore users should not be required to close an alert. The user agent may consider firing an accessibility alert event, when the alert is created, provided one is specified by the intended accessibility API.

If an alert requires focus to close the alert then it is suggested that an alertdialog be used.

Characteristics:
Is Abstract:  
Parent Role: status
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: alertdialog

A separate window with an alert or error information.

Alertdialogs are used to convey messages to alert the user. The alertdialog role goes on the container of the subtree containing the alert message. Unlike alert, alertdialog requires a response from the user such as to confirm that the user understands the alert being generated. It is expected that authors shall set focus to an active document element within the alertdialog such as a form edit field or an ok pushbutton. The user agent may consider firing an accessibility alert event, when the alert is created, provided one is specified by the intended accessibility API.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: marquee

A marquee is used to scroll text across the page.

A common usage is a stock ticker. A marquee behaves like a region with an assumed default aria live property value of polite. An example of a marquee is a stock ticker.

Characteristics:
Is Abstract:  
Parent Role: section
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:  
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: log

A region where new information is added and old information may disappear such as chat logs, messaging, game log or an error log. In contrast to other regions, in this role there is a relationship between the arrival of new items in the log and the reading order. The log contains a meaningful sequence and new information is added only to the end of the log, not at arbitrary points.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: status

This is a container for process advisory information to give feedback to the user.

A status object must have content within it to provide the actual status information. This object typically does not receive focus.

Status is a form of live region. It's assumed default value for the live property is "polite" and that it is not controlled by another part of the page. If another part of the page does control it then that part of the page should assign a controls relationship on the object controlling the live region with an ID reference to the the live region. In this instance the role of the live region should be set to "region" and the appropriate live region properties should be set (Michael: link the live region properties phrase to the equivalent section in the adaptable states and properties module).

Some cells of a Braille display may be reserved to render the status.

Characteristics:
Is Abstract:  
Parent Role:
Child Roles:
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From:  
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

Role: progressbar

Used by applications for tasks that take a long time to execute, to show the execution progress.

This lets the user know that the user's action request has been accepted and that the application continues (or ceases, in the case of a static display) to make progress toward completing the requested action.

Characteristics:
Is Abstract:  
Parent Role: status
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational: True
Inherits Presentational:  

Role: timer

A numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.

The text contents of the timer object indicate the current time measurement, and are updated as that amount changes. However, unless the datatype attribute is used, the timer value is not necessarily machine parsable. The text contents are updated at fixed intervals except when the timer is paused or reaches an end-point.

A timer is a form of polite live region.

Characteristics:
Is Abstract:  
Parent Role: status
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

3.4.6 Landmark Roles Inherited from the XHTML Role Attribute Module

This section includes roles imported from the XHTML Role Attribute Module [XHTML-ROLES, Section 4]. These roles are included here in order to make them clearly part of the ARIA Role taxonomy. Role descriptions are taken from the description provided in the XHTML Role Attribute Module.

Roles in this section include:

Role: banner

A banner is usually defined as the advertisement at the top of a web page. The banner content typically contains the site or company logo and other key advertisements for the site.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: contentinfo

This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: definition

The contents of the associated element represent a definition (e.g., of a term or concept). If there is a dfn element within the contents, then that represents the term being defined.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: main

This defines the main content of a document.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: navigation

This is a collection of links suitable for use when navigating the document or related documents.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: note

The content is parenthetic or ancillary to the main content of the resource.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: search

This is the search section of a web document. This is typically a form used to submit search requests about the site or a more general Internet wide search service.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: secondary

This is any unique section of the document. In the case of a portal, this may include but not be limited to: show times; current weather; or stocks to watch.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  
Role: seealso

Indicates that the element contains content that is related to the main content of the page.

Characteristics:
Is Abstract:  
Parent Role: region
Child Roles:  
Base Concept:  
Related Concepts:
Parent Element:  
Required Child Elements:  
Supported States and Properties:  
Inherited States and Properties:
Name From: author
Accessible Name Required:  
Inherits Name Required:  
Children Presentational:  
Inherits Presentational:  

4 Supported States and Properties

This section is normative.

The terms "states" and "properties" refer to similar features. Both provide specific information about an object, and both form part of the definition of the nature of roles. In this document, states and properties are treated nearly identically. However, they are maintained conceptually distinct because there is a subtle difference in their meaning. In the definitions for states and properties in this document, states are introduced with the "State" prefix and properties are introduced with the "Property" prefix.

4.1 Characteristics of States and Properties

This section is normative.

The States and Properties Module supports the following characteristics:

Characteristics of States and Properties
Characteristic Description
Related Concepts Advisory information about features from this or other languages that correspond to this state or property. While the correspondence may not be exact, it is useful to help understand the intent of the state or property.
Used in Roles Advisory information about roles from the ARIA Roles specification that use this state or property. This information is provided to help understand the appropriate usage of the state or property. Since the ARIA Roles and the ARIA States and Properties are separate specifications, use of a given state or property is not limited just to the roles identified here.
Inherits into Roles Advisory information about roles from the ARIA Roles specification that inherit the state or property from an ancestor role.
Value Value restrictions for the state or property. These restrictions are expressed in terms of XML Schema Datatypes [XSD]. The following XSD Datatypes are used in this specification.
  • boolean: a true/false value, expressed in attribute values as "true" or "false".
  • decimal: a real number, represented as a decimal.
  • integer: a positive or negative integer, expressed as a decimal number.
  • string: an arbitrary string value.
  • IDREF: a reference to the ID of another element in the same document.
  • IDREFS: a whitespace-delimited list of references to the ID of one or more elements in the same document.
  • NMTOKEN: a value selected from a set of allowed values, which are defined by an enumeration constraint.
  • NMTOKENS: a whitespace-delimited list of one or more values selected from a set of allowed values, which are defined by an enumeration constraint.
  • anyURI: a Uniform Resource Identifier Reference (URI).

Values of type boolean, NMTOKEN, and NMTOKENS are further explained by listing the allowed values and their meanings below the table of characteristics. When a value is indicated as the default, the behavior prescribed by this value should be followed when the state or property is not provided.

Note: in the XHTML module, value restrictions are necessarily expressed in DTD notation, not XSD. DTD notation does not provide the precise value restrictions supported by XSD, and therefore the values in the DTD often have a wider scope of allowed values than what is actually allowed by this specification. Implementers should be sure to observe the value restrictions defined here and not rely simply on DTD validation.

4.2 Definitions for States and Properties

This section is normative.

States and properties are categorized as follows:

  1. Widget states
  2. Live Regions
  3. Drag and Drop
  4. Focus
  5. Relationships
  6. User Interface Properties

Below is an alphabetical list of ARIA states and properties to be used by rich internet application authors. A detailed definition of the taxonomy supporting these ARIA states and properties follows.

States
StateDefinition
busyIndicates whether a live region is finished updating.
checked The checked state indicates something has been rendered as being chosen by the user in the sense that it is a binary or tertiary operation. An example is a checkbox.
disabledIndicates that the widget is present, but the value cannot be set and it cannot be internally navigated.
expandedIndicates whether an expandable/collapsible group of elements is currently expanded or collapsed.
grabThis property is set to show an object's state in drag and drop.
hiddenDefines whether or not the object is visible to the user.
invalidIndicates that the element's value is currently invalid, which discourages the form from being submitted.
pressedUsed for buttons that are toggleable to indicate their current pressed state.
selectedSets whether the user has selected an item or not.
Properties
StateDefinition
activedescendantAn element which has focus may specify its current active child. This is used when a element is responsible for managing its current active child to reduce the overhead of having all children be focusable.
atomicAtomic is an optional property of live regions. When the region is updated, the atomic property is used to indicate if the assistive technology should present all or part of the changed region to the user.
autocompleteIndicates whether user input completion suggestions are provided.
channelThis property specifies which channel should be used to present the updates for its associated live region.
controlsDefines the elements that are controlled by the current element.
datatypeDatatype defines the format type of an element.
describedbyPoints to an element which describes the object.
dropeffectThis property is set for the target of a drag and drop operation to show the effect when the dragged object is released.
flowtoEstablishes the recommended reading order of content, overriding the general default to read in document order.
haspopupIndicates that element may launch a pop-up window such as a context menu or submenu.
labelledbyPoints to the element which labels the current element.
levelLevel is the hierarchical level of an element within a structure.
liveDescribes the types of updates the user agent, assistive technology, and user can expect from an alert or live region of Web content.
multilineIndicates whether a text box accepts only a single line, or if it can accept multiline input.
multiselectableIndicates that the user may select more than one item from the current list.
ownsDefines an object as a parent of another document element, when the child does not appear directly in the subtree of the owner.
posinsetIndicates an item's number or position within the current level of a tree or list.
readonlyIndicates that the widget is not editable.
relevantIndicates the relevant areas of change within a live region.
requiredIndicates that user input is required on the control before a form may be submitted.
secretProvides the user with the ability to supply information to the system in a manner that makes it difficult for someone else (who may be watching) to discern the value that is being supplied.
setsizeThe setsize property refers to the number of items in the current level of a list or tree.
sortThe sort property is used to indicate if items in a table or grid are sorted in ascending or descending order.
tabindexIndicates tab order of elements. Elements with negative values are able to receive focus but are not included in the basic tabbing navigation list or cycle.
templateidThe templateid is a unique identifier, represented as a URI, for which an assistive technology may customize its user interface.
valuemaxMaximum allowed value for a range type of widget.
valueminMinimum allowed value for a range type of widget.
valuenowThe current value of a widget.

4.2.1 Widget states and properties

This section contains states specific to user common interface elements found on GUI systems or in rich Internet applications which receive user input and process user actions. These states are used to support the widget roles found in the ARIA Roles taxonomy. Widget states may be mapped by a user agent to platform accessibility API states, for access by an assistive technology, or they may be accessed directly from the DOM. Changes in states should result in a notification to an assistive technology either through DOM attribute change events or platform accessibility API events.

States and properties in this section include:

Property: autocomplete

Indicates whether user input completion suggestions are provided.

For a text box, it is assumed that the completion suggestion appears inline after the caret. The haspopup property can be used to indicate that a popup containing choices appears, notwithstanding the fact that it is a simple text box.

For an element which already has a drop-down (i.e., a combobox), it is assumed that the dropdown behavior is still present. This means that if autocomplete is true, haspopup should also be true on a combobox.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
inline:   the system provides text after the caret as a suggestion for how to complete the field
list:   a list of choices appears from which the user can choose, but the edit box retains focus
both:   a list of choices appears and the top-rated selection also appears inline
none: (default) Only values from the value list can be selected

State: checked

The checked state indicates something has been rendered as being chosen by the user in the sense that it is a binary or tertiary operation. An example is a checkbox.

Characteristics:
Related Concepts:
Used in Roles: option
Inherits into Roles:
Value: NMTOKEN
Values:
true:   indicates that the current item is checked.
false:   roles that support being checked but are not currently checked.
mixed:   indicates a mixed mode for a tri-state checkbox. This is only supported on checkbox and menuitemcheckbox.  
undefined (default) the object does not support being checked.

Property: datatype

Datatype defines the format type of an element.

Datatype should be a qname that refer to an XML Schema Datatypes [XSD] defined type. For example, a datatype may be xsd:integer. The author may also reference their own custom datatypes as long as they are simple types. Clearly XSD base types are simpler for the user agent to understand.

Datatype applies to the content of an element, e.g., the value of an input element that the user could change. This can facilitate automatic validation of user input. If no datatype is provided, the default value the user agent should assume is "xsd:string", which is a simple character string with no intrinsic format.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: string

State: disabled

Indicates that the widget is present, but the value cannot be set and it cannot be internally navigated.

For example, irrelevant options in a radio group may be disabled. Disabled elements often do not receive focus.

There should be a change of appearance to indicate that the item has been disabled (grayed out, etc.).

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: boolean
Values:
true:   todo
false: (default) todo

State: expanded

Indicates whether an expandable/collapsible group of elements is currently expanded or collapsed.

Examples include: to expand or collapse a portion of the tree, or an "expanded" version such as acronyms, rollovers, diagram sections.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
true:   the group is expanded
false:   the group is collapsed
undefined: (default) the group is neither expandable nor collapsible (all its child elements are shown)

Property: haspopup

Indicates that element may launch a pop-up window such as a context menu or submenu.

This is a special case of owns where activation renders conditional content. Note that tooltips are not considered popups in this context.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: boolean
Values:
true:   indicates it has a popup menu, either as a descendant or pointed to by owns 
false: (default) has no popup

State: invalid

Indicates that the element's value is currently invalid, which discourages the form from being submitted.

If the state is computed to be invalid, out-of-range, or required this value should be set as true.

Characteristics:
Related Concepts:
Used in Roles: input
Inherits into Roles:
Value: boolean
Values:
true:   Todo:
false: (default) Todo

Property: level

Level is the hierarchical level of an element within a structure.

This can be applied inside trees to tree items, to headings inside a document, to nested grids, and to other structural items that may appear inside a container or participate in an ownership hierarchy. Levels must be 1 or greater.

Levels should increase with depth increases relative to the level of the parent. Level information should be maintained by the author.

This property is applied to leaf nodes, not to containers. This means that multiple elements in a set may have the same value for this property. Although it would be less repetitive to provide a single value on the container, it is not always possible for authors to do so. Restricting this to leaf nodes ensures that there is a single way for assistive technology to use the property.

In many cases the user agent may be able to calculate the level of an item if it can be determined correctly from the document structure. This property may be used to provide an explicit indication of the level if that is not possible from the document structure. User agent automatic support for automatic calculation of level may vary; it is recommended that authors test with user agents and assistive technologies to determine whether this property is needed.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: integer

Property: multiline

Indicates whether a text box accepts only a single line, or if it can accept multiline input.

Characteristics:
Related Concepts:
Used in Roles: textbox
Inherits into Roles:
Value: boolean
Values:
true:   this is a multiline text box
false: (default) this is a single-line text box

Property: multiselectable

Indicates that the user may select more than one item from the current list.

Examples include: lists, trees, spreadsheets

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: boolean
Values:
true:   todo
false: (default) todo

State: pressed

Used for buttons that are toggleable to indicate their current pressed state.

Toggle buttons require a full pressed and released cycle to toggle their value. Activating it once changes the pressed state to "true", and activating it another time changes the pressed state back to "false". If the state is not present, the button is not a toggle button.

The pressed state is similar but not identical to the checked state. Operating systems support pressed on buttons and checked on checkboxes.

Characteristics:
Related Concepts:
Used in Roles: button
Inherits into Roles:
Value: NMTOKEN
Values:
true:   indicates that the button is depressed.
false:   the button is not depressed.
mixed:   The elements on the page that are affected by the button do not all share the same value. Direct user action on the object having the pressed state cannot automatically put it into the mixed state.
undefined: (default) The button is not a toggle button.

Property: readonly

Indicates that the widget is not editable.

This means the user can read but not set the value of the widget. Readonly objects are relevant to the user and can navigated internally..

Examples include:

  • A form element which represents a constant.
  • Row or column headers in a spreadsheet.
  • The result of a calculation such as a shopping cart total.
Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: boolean
Values:
true:   todo
false: (default) todo

Property: required

Indicates that user input is required on the control before a form may be submitted.

For example, if a user must fill in an address field, then required is set to true.

Note: the fact that the element is required is often visually presented (such as a sign or symbol after the control). Using the required attribute makes it much easier for user agents to pass on this important information to the user.

Characteristics:
Related Concepts:
Used in Roles: input
Inherits into Roles:
Value: boolean
Values:
true:   todo
false: (default) todo

Property: secret

Provides the user with the ability to supply information to the system in a manner that makes it difficult for someone else (who may be watching) to discern the value that is being supplied.

Disadvantage: Passwords are entered without the usual echo to the screen. Web users who type badly and are used to having their input echoed are unable to confirm what is entered. This can create problems such as having their account locked if they enter the wrong password too many times.

Disadvantage: The policy not to display entered text is usually taken to be absolute. However, a user with their screen blank and audio output via an earphone may prefer to have their input echoed since in this situation it does not run the risk of being viewed by a bystander.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: boolean
Values:
true:   text input should be masked or not echoed.
false: (default) no text input masking

State: selected

Sets whether the user has selected an item or not.

Selecting an element indicates that it is chosen for an action, and most likely has focus. However, this does not imply anything about other states. For example, a role such as a radio button may support being selected, but that does not affect the value of the checked state, though it may need to first be selected in order to be checked.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
true:   a selectable element is actually selected.
false:   the element is not selected.
undefined: (default) the element is not selectable.

Property: valuemax

Maximum allowed value for a range type of widget.

A range control may start with a given value, which can be increased until a maximum value, defined by this property, is reached.

Declaring the valuemax will allow for alternate device to calibrate an arrow up effect, validate, or simply let the user know the size of the range on offer. If the valuenow has a known maximum and minimum, the author should provide properties for valuemax and valuemin.

The type of valuemin is a number. If the value type of the widget is not a number, the value must be provided in child content and the type indicated with datatype.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: decimal

Property: valuemin

Minimum allowed value for a range type of widget.

A range control may start with a given value, which can be decreased until a minimum value, defined by this property, is reached.

Declaring the valuemin allows for alternate device to calibrate an arrow up effect, validate, or simply let the user know the size of the range on offer. If the valuenow has a known maximum and minimum, the author should provide properties for valuemax and valuemin.

The type of valuemin is a number. If the value type of the widget is not a number, the value must be provided in child content and the type indicated with datatype.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: decimal

Property: valuenow

The current value of a widget.

Used, for example, for a range control such as a slider or progress bar, and for a date.

If the value is not known (as often occurs with progress bars) then the valuenow attribute should not be set at all. If the valuenow attribute is absent, no information is implied about the current value. If the valuenow has a known maximum and minimum, the author should provide properties for valuemax and valuemin.

The type of valuenow is a number. If the value type of the widget is not a number, the value must be provided in child content and the type indicated with datatype.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: decimal

4.2.2 Live Regions

This section contains properties specific to live regions in rich Internet applications. These properties may be applied to any element. The purpose of these properties is to indicate that changes to this section may occur without it having focus and to provide the assistive technology information on how to process live updates in this section of the page. If possible, it is best that the live property be assigned to sections of the document with a pre-defined specific role such as the standard XHTML role landmarks or custom regions such as log.

States and properties in this section include:

Property: atomic

Atomic is an optional property of live regions. When the region is updated, the atomic property is used to indicate if the assistive technology should present all or part of the changed region to the user.

Both accessibility APIs and the Document Object Model [DOM] provide events to allow the assistive technology to determine changes areas of the document.

When a node changes, the AT should look at the current element and then traverse the ancestors to find the first element with aria:atomic set.

  1. If none of the ancestors have explicitly set atomic, this is the default (aria:atomic="false") case, and the AT only needs to present the changed node to the user.
  2. If aria:atomic is explicitly set to false, then the AT can stop searching up the ancestor chain, and should present only the changed node to the user.
  3. If aria:atomic is explicitly set to true, then the AT should present the entire subtree that aria:atomic="true" was set on.

The AT may choose to combine several changes and present the entire changed region at once.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: boolean
Values:
true:   the assistive technology should present the entire region as a whole.
false: (default) a change within the region may be processed by the assistive technology on its own

State: busy

Indicates whether a live region is finished updating.

The default is that busy is false. For example, if authors know that multiple parts of the same live region need to be loaded, they can set busy to true when the first part is loaded and then set busy to false when the last part is loaded.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
true:   The live region is still being updated
false: (default) There are no more expected updates for that live region
error:   An error has occurred and the live region may not have received all the updates that it should have

Property: channel

This property specifies which channel should be used to present the updates for its associated live region.

The default value is "main".

The mapping of hardware channels (speech synthesizer, braille, etc.) to the main and notify channels is implementation/configuration dependent.

If multiple hardware channels are available, the AT should allow users to map the main and notify channels as they wish.

If there is only one hardware channel available, the AT should render both channels on the same hardware channel. The notify channel is higher priority than the main channel for live regions of the same politeness; if the events from the two channels are of differing politeness levels, the channel with the higher priority event should have higher priority than the other channel. Note that events from one channel cannot interrupt or clear out events on another channel.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
main: (default) The default channel on which to send live region events
notify:   A channel with higher priority than the Main channel on which to send the live regions events

Property: live

Describes the types of updates the user agent, assistive technology, and user can expect from an alert or live region of Web content.

It is essential to describe the types of updates the user agent and user can expect from a live region of Web content. The values of this state are expressed in terms of "politeness" levels. "Polite" regions notify of updates but do not interrupt users, and updates take low priority. An appropriate use of more assertive content would be to notify users of a site that the connection is going down in 5 minutes, since the importance of the message is greater than the problem caused by the interruption.

Examples of live regions include:

  • A section of updated basketball statistics.
  • A region that updates in response to a user's control of a Web page (such as requesting a photograph).

When the property is not set on an object that needs to send updates, the politeness level is inherited from the value of the nearest ancestor that sets the live property.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
off: (default) The region is not currently live.
polite:   (Background change) This is normal operation and the default behavior for live regions. It is not necessary to respond until user completes their current activity.
assertive:   This information has a higher priority than normal but does not necessarily interrupt immediately.
rude:   This information has the highest priority and should typically result in an interrupt to the user. This may disorientate users causing them not to continue in their current task.

Property: relevant

Indicates the relevant areas of change within a live region.

The property is represented as space delimited list of the following values: additions, removals, text, all.

Relevant is an optional property of live regions within a document. Relevant is unrestrictive as to how an assistive technology processes attributes. When the relevant property is not provided, the default is to assume there are text changes and additions.

Both accessibility APIs and the Document Object Model [DOM] provide events to allow the assistive technology to determine changes areas of the document.

When this value is not set, the value inherits from an object's nearest ancestor. It is not additive, meaning the set of values provided and not provided on an object completely override any inheritance of values.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKENS
Values:
additions:   Nodes are added to the DOM within the region
removals:   Nodes are removed from the DOM
text: (default) Text is added or removed from the DOM
all:   Additions, removals, text

4.2.3 Drag and Drop

This section defines properties which must be applied by an author to indicate the state of objects which may be "grabbed" for a drag operation as well as the state of drop targets once a drag operation has been started. This information is designed to facilitate a drag and drop operation by identifying "draggable" objects and drop target. This information should either be rendered visually or provided to the user by an assistive technology through an alternative modality.

States and properties in this section include:

Property: dropeffect

This property is set for the target of a drag and drop operation to show the effect when the dragged object is released.

More than one drop effect may be supported for a given element. Therefore, the value of this property is a space-delimited set of tokens indicating the possible effects, or "none" if there is no supported operation. This property also allows authors to provide a visual indication of the drag source to the user during drag operations with a style sheet. If only one type of operation is supported, it can be set at page load.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: NMTOKENS
Values:
copy:   A duplicate of the source object will be dropped into the target.
move:   The source object will be removed from its original location and dropped into the target.
reference:   A reference or short cut to the dragged object will be created in the target object.
none: (default) No operation can be performed; effectively cancels the drag operation if an attempt is made to drop on this object

State: grab

This property is set to show an object's state in drag and drop.

When it is set to "true" it has been selected for dragging, "supported" indicates that the object is grabable, but is not currently grabbed, "false" indicates the object is not grabable (default).

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: NMTOKEN
Values:
true:   Indicates that the document element has been "grabbed" for dragging.:
supported:   Indicates that the document element supports being dragged.
false: (default) Indicates that the document element does not support being dragged.

4.2.4 Focus

This section defines properties that are used to help the user agent and assistive technology process user focus.

States and properties in this section include:


Property: activedescendant

An element which has focus may specify its current active child. This is used when a element is responsible for managing its current active child to reduce the overhead of having all children be focusable.

Examples include: multi-level lists, trees, spreadsheets.

When the author sets the activedescendant property, they should ensure that the object is either a descendant of the container in the DOM, or can be accessed by the owns property. The user agent is not expected to check that the activedescendant is an actual descendant of the container.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: IDREF

Property: tabindex

Indicates tab order of elements. Elements with negative values are able to receive focus but are not included in the basic tabbing navigation list or cycle.

Elements of types div, span, p, td, th and li for which no TABINDEX value is given likewise do not participate in the 'tabbing' navigation list.

Elements with disabled="true" do not participate in the tabbing navigation list.

Elements bearing positive values of TABINDEX are navigated first as specified in the HTML 4.01 Specification ([HTML], section 17.11.1):

Those elements that support the tabindex attribute and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tabindex values should be navigated in the order they appear in the character stream.

Elements bearing a zero value of TABINDEX, together with elements of types A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA bearing a zero value or no value of TABINDEX, are navigated next, as specified in HTML 4.01. These elements are navigated in the order they appear in the character stream.

Elements with a negative value for tabindex can be programmatically focused, but do not participate in the tab order. They therefore receive focus only when an event handler sets the focus. It is necessary to provide a value for tabindex because otherwise scripts cannot set the focus. Typically, the value -1 is used for this scenario.

Note: The applicability of this attribute has been extended to all visible elements, within the XHTML namespace. It should not be used with a prefix referring to the aria namespace. Refer to the earlier discussion on tabindex for more background.

When tabindex is used on elements with the presentation role or state hidden set to "true", it overrides the default behavior not to render such elements. This is because there must be an object in the accessibility hierarchy for the focus event to be fired on, and the element must be visible if it receives focus. Note this is not the case for disabled = "true". It is common for disabled menu items to be key navigable.
Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: integer

4.2.5 Relationships

This section defines relationships or associations between elements which cannot be readily determined from the document structure.

States and properties in this section include:


Property: describedby

Points to an element which describes the object.

(A label should provide the user with the essence of the what the object does whereas describedby is intended to provide additional information which some users might need. )

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: IDREFS

Property: flowto

Establishes the recommended reading order of content, overriding the general default to read in document order.

When flowto has a single IDREF, it instructs assistive technology to skip normal document reading order to go to the targeted ID. Flowto in subsequent elements would follow a process similar to next focus in XHTML2 ([XHTML], Section 13). However, when flowto is provided with multiple IDs, then they should be processed as path choices by the AT, such as the case in a model based authoring tool. This means that the user should be given the option of navigating to any of the elements targeted. The name of the path can be determined by the target element of the flowto. Accessibility APIs can provide named path relationships.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: IDREFS

Property: labelledby

Points to the element which labels the current element.

The label should provide the user with the essence of the what the object does whereas describedby provides additional information which some users might need.

Note: the expected spelling of this property in U.S. English would be "labeledby". However, the accessibility API features to which this property is mapped have established the "labelledby" spelling. This property is spelled that way to match the convention and minimize the difficulty for developers.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: IDREFS

Property: owns

Defines an object as a parent of another document element, when the child does not appear directly in the subtree of the owner.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: IDREFS

Property: posinset

Indicates an item's number or position within the current level of a tree or list.

For example, if this element is the third item in a group then posinset is equal to three. The range of values is 1 to the size of the set.

If all items in a set are present in the document structure, the user agent should be able to calculate the set size and position in the set of each item. However, if the set is elided and only a portion of it is present in the document structure, this property is needed to provide an explicit indication. User agent automatic support for automatic calculation of position and setsize may vary; it is recommended that authors test with user agents and assistive technologies to determine whether this property is needed.

Posinset should be used together with setsize.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: integer

Property: setsize

The setsize property refers to the number of items in the current level of a list or tree.

For example, if this element is in a group of six items at the same level then setsize is equal to six. Setsize must be >= 1.

This property is applied to leaf nodes, not to containers. This means that multiple elements in a set may have the same value for this property. Although it would be less repetitive to provide a single value on the container, it is not always possible for authors to do so. Restricting this to leaf nodes ensures that there is a single way for assistive technology to use the property.

If all items in a set are present in the document structure, the user agent should be able to calculate the set size and position in the set of each item. However, if the set is elided and only a portion of it is present in the document structure, this property is needed to provide an explicit indication. User agent automatic support for automatic calculation of position and setsize may vary; it is recommended that authors test with user agents and assistive technologies to determine whether this property is needed.

Setsize should be used together with posinset.

Characteristics:
Related Concepts:
Used in Roles: listitem
Inherits into Roles:
Value: integer
 

4.2.6 User interface properties

This section defines properties that are affect or describe user interface rendering.

States and properties in this section include:

State: hidden

Defines whether or not the object is visible to the user.

For example, if a menu is only visible after some user action, this property would be set to true until the user performs the necessary action at which time this property would then be set to false.

It is recommended that authors key visibility of objects off this attribute, rather than change visibility and separately have to remember to update this property. CSS 2 provides a way to select on attribute values ([CSS], Section 5.8.1). The following pair of CSS declarations make content visible unless the hidden property is true; scripts need only update the value of this property to change visibility:

[aria-hidden=true] {visibility :hidden;} 

Note that this CSS example, while technically correct, will not work in most browsers at the time of this writing. It may be necessary to set the style using script.

Characteristics:
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles:  
Value: boolean
Values:
true:   Indicates that this section of the document and its children are hidden from the rendered view.
false: (default) Indicates that this section of the document is rendered.

Property: sort

The sort property is used to indicate if items in a table or grid are sorted in ascending or descending order.

Should be applied only to table or grid headers. If the property is not provided, there is no defined sort order.

Characteristics:
Related Concepts:
Used in Roles:
Inherits into Roles:
Value: NMTOKEN
Values:
ascending:   items are sorted in ascending order by this column
descending:   items are sorted in descending order by this column
none: (default) there is no special sort applied to the column
other:   a sort algorithm other than ascending or descending has been applied

Property: templateid

The templateid is a unique identifier, represented as a URI, for which an assistive technology may customize its user interface.

Values of this can be set to any appropriate URI. The W3C does not maintain information about URIs that are in common use for this purpose.

Characteristics:
Related Concepts:
Used in Roles:

section

Inherits into Roles:
Value: anyURI

5 Implementation in Host Languages

This section is normative.

The taxonomy of roles, states, and properties defined in ARIA is applicable to any language for Web content. This specification focuses on implementation in markup languages. There are two broad approaches to implementation, one for XML [XML] based languages that support extensions via XML namespaces [XML-NAMES], and one for markup languages, such as HTML, without the use of namespace extensions.

ARIA Roles, States, and Properties are implemented as attributes of elements. Roles use a special-purpose "role" attribute whose value is the name of the role. States and properties each use their own attribute, with values as defined for each particular state or property in this specification. The name of the attribute is based on the name of the state or property but depends on whether ARIA is used with namespace extensions, explained in further detail below.

5.1 Implementation in HTML and other markup languages without requiring namespace support

Most implementations of ARIA in content that is sent to user agents should use this approach. User agents expect to see ARIA as a de facto extension of their supported languages. The approach for implementation without namespaces may be used even in languages that support namespaces, if the language allows. For instance, SVG supports namespace extensions but it is preferred to use ARIA without namespaces in order to have an equivalent DOM as HTML.

ARIA roles are applied to an element with the "role" attribute. This attribute is derived from the XHTML Role Attribute Module [XHTML-ROLES] but is not technically an actual usage of that specification. As in the XHTML Role Attribute Module, this attribute is in no namespace. However, values of the attribute are not CURIEs [CURIE], but simply strings.

The role attribute indicates what type of object the element represents. The value of this attribute is the name of a role in this specification (including roles defined in the XHTML Role Attribute Module that are imported into the ARIA specification - see Landmark Roles inherited from the XHTML Role Attribute Module).

To support future extensibility, and to allow for the provision of other roles than those from ARIA, the role attribute allows multiple values, separated by whitespace. From the list of values, the first role that is recognized by the user agent as an ARIA role is the one processed according to the ARIA specification. Subsequent values serve as fallbacks, either for roles defined in later versions of the ARIA specification or roles that are intended to extend the roles defined in the ARIA specification. Authors should therefore provide roles in the order of newest or most precise first, and most likely to be recognized last, so the most appropriate role recognized by the user agent will be encountered first.

Note: ARIA roles are in the namespace of the rest of the document, if defined, and do not require a namespace prefix. If other roles are provided in the role attribute, they MUST have namespace prefixes. The namespace prefixes are not processed as namespaces per se but serve to distinguish non-ARIA roles.

Each ARIA state and property is represented with its own attribute. The state and property attributes are in no namespace, meaning the attributes are implemented without namespace qualifiers like other attributes of the host language. To minimize the chance of conflict with attribute names defined in the host language, the attribute name for each state and property is the prefix "aria-" plus the name of the state or property. For example, the attribute name for the checked state is aria-checked.

Note: In most cases, the attributes required to represent the ARIA states and properties are not defined in the host language. The role attribute may also not be defined. If the host language does not provide an extensibility mechanism, documents that implement ARIA in this manner will not pass DTD-based validation. However, user agents that conform to ARIA will process such documents.

Editorial note: we are exploring mechanisms to provide automated conformance checking for documents that include ARIA. This might be provided informatively as a tool, and conformance checking with it is NOT required. Providing an unofficial version of the HTML DTD with ARIA support added to drive existing validators might be useful as well.

Allowed values of the state and property attributes are defined in this specification. These attributes must have values meeting the restriction for data type or enumerated value. These values define the specific meaning associated with the state or property.

To support compatibility with future versions of ARIA, attribute names beginning with "aria-" should be treated as reserved in host languages likely to use ARIA. This is not a conformance requirement, but a request to enhance compatibility.

Note: Some user agents process languages in namespaces, such as XHTML and HTML 5, and languages in no namespace, such as HTML 4. Such user agents should recognize ARIA state and property attributes in the namespaces of the various technologies supported by the user agent. For instance, a user agent that supports HTML, XHTML, and SVG will recognize ARIA attributes on HTML elements as well as elements in the XHTML and SVG namespaces.

5.2 Implementation using namespaces

XML languages that support namespaces may support ARIA without specific modification of the language, by using namespaces to differentiate the ARIA attributes. This approach is mainly useful for content that will eventually be transformed before delivery to the user agent. During that transformation, the ARIA features should be converted into the non-namespace version described above. User agents are not expected to support content with ARIA in namespaces.

This implementation method requires three things:

  1. The availability of an attribute defined to attach ARIA roles. The "role" attribute defined in the XHTML Role Attribute Module [XHTML-ROLES] is designed for this and may be used in its namespace, http://www.w3.org/1999/xhtml. Alternatively, the language may provide its own role attribute, which should be used if available. The role attribute must support CURIE [CURIE] values. The XHTML Role attribute supports CURIE values.
  2. Values for the role attribute are a CURIE composed of the name of the appropriate ARIA role, in the ARIA Role namespace http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#. This namespace is bound to the prefix "ariarole" for examples in this document. For example, an element with a role of checkbox might be implemented as xhtml:role="ariarole:checkbox".
  3. States and properties are provided as attributes having the name of the state or property, in the ARIA States and Properties namespace http://www.w3.org/2005/07/aaa. Values of these attributes are as defined by the particular state or property. This namespace is bound to the prefix "aria" for examples in this document. For example, an element that has a checked state of true might be implemented as aria:checked="true".

The start tag of a root element that includes the appropriate namespace declarations might look like:

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

The following example demonstrates using ARIA with SVG [SVG]:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-flat-20030114.dtd">
<svg xmlns="http://www.w3.org/2000/svg" 
    xmlns:xhtml="http://www.w3.org/1999/xhtml"
    xmlns:ariarole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
    xmlns:aria="http://www.w3.org/2005/07/aaa" 
    width="100% " height="100% ">

<desc>
Example of using state-attributes from Accessible Adaptable Applications Namespace:

</desc>

<!-- an expanded group of rectangles -->
<g aria:expanded="true ">
<!-- this rectangle is zoomed -->

<rect x="1cm " y="3cm " width="1cm " height="1cm " />
<rect x="3cm " y="3cm " width="1cm " height="1cm " />
</g>
</svg>

5.2.1 The States and Properties Module

Appendix A.2 provides a driver DTD which integrates a new profile for XHTML which augments XHTML 1.1 Full with the capabilities in the new module introduced here. This uses XHTML Modularization [XHTMLMOD] to extend XHTML 1.1.

5.2.1.1 Using the XHTML 1.1 Module

Valid XHTML 1.1 documents that wish to use this profile must use the following DOCTYPE declaration:

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
 "http://www.w3.org/2005/07/aaa/xhtml11-aria.dtd">

Set the namespace prefix for ARIA to http://www.w3.org/2005/07/aaa. This is typically done on the root element of the document:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:aria="http://www.w3.org/2005/07/aaa">
  ...
</html>

Note that XHTML 1.0 does not support modularization. The ARIA States and Properties attributes will be understood by user agents in XHTML 1.0 by declaring and using the appropriate namespace the same as for XHTML 1.1, but such documents will not validate to the XHTML 1.0 DTD.

5.2.1.2 Tabindex in XHTML 1.1

tabindex is not a state or property and has not been added to the http://www.w3.org/2005/07/aaa namespace. However, to help the accessibility of accessible XHTML applications, tabindex has been added to all visible elements in the extended XHTML Doctype. The tabindex change enables support of User Agent Accessibility Guidelines[UAAG]. tabindex should not be used with a prefix, because it is an existing XHTML attribute. The States and Properties DTD simply adds this attribute, without a prefix, to an extended set of elements. See Tabindex in XHTML 1.1 for more information.

tabindex also supports the values of "0" and "-1." See section 4.4 for details.

Tabindex is used only to provide focus support to XHTML documents and HTML 4 documents. Other content languages already provide the needed focus control features. Therefore, tabindex is not defined and not expected to be used when ARIA is used in other languages.

Editorial note: It has been proposed that tabindex be made a global attribute, which can be used on any element. The group has not fully considered the technical consequences of this but is considering making this change in a future draft.

5.2.1.3 XHTML 1.1 Example

The following example shows a role being used to make a simple widget known to the user agent, so that the user agent can handle it correctly. In this example a div has been used with scripts to act as a tristate checkbox. The ARIA State and Properties of checked has been set to true.

The XHTML role element gives the use agent information about the behavior of the widget. For more information on Roles see Using Roles.

<span
    class="checkbox" 
    id="chbox1" 
    role="ariarole:checkbox" 
    aria:checked="true" 
    tabindex="0"
    onkeydown="return checkBoxEvent(event);" 
    onkeyup="return checkBoxEvent(event);" >
  A checkbox label
</span>

JavaScript can then manipulate the widget via the DOM. However, because States and Properties are mapped to the accessibility platforms, the assistive technology and user agents can understand the widget behavior and respond appropriately.

java script snippet :
  if ((event.type == "keyup" && event.button == 0)) {

    // Toggle checkbox

    var checkbox = event.target;

    if (checkbox.getAttributeNS("http://www.w3.org/2005/07/aaa",
      "checked") == "true") {

        checkbox.removeAttributeNS("http://www.w3.org/2005/07/aaa",
        "checked");


      return false;  // Don't continue propagating event}
    }

    return true;  // Browser can still use event

}

5.2.2 Using ARIA in other Namespace-aware XML Languages

Other languages may use ARIA, using namespaces to distinguish values of the role attribute, and state and property attributes. Because of the use of namespaces, it is not strictly necessary to extended such languages. Maintainers of such languages MAY choose to integrate the module in a way which makes this document the governing specification for the semantics of these language features. Appropriate methods of module integration include but are not limited to the methods as specified in XHTML Modularization [XHTMLMOD].

6 Conformance Requirements

This section is normative.

6.1 Document Conformance

The ARIA roles, states, and properties is not a stand-alone document type. It is intended to be integrated into other host languages such as XHTML [XHTML]. A conforming document is a document that requires only the facilities described as mandatory in this specification and the facilities described as mandatory in its host language. Such a document must meet all the following criteria:

  1. The document must conform to the constraints expressed in Appendix A - RDF Schema combined with the constraints expressed in its host language implementation.

  2. The document must contain an xmlns declaration for the role Namespace [XML-NAMES]. The namespace name for the roles defined here is

    http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#

  3. The document must conform to the constraints expressed in XHTML 1.1 For Accessible Adaptable Applications DTD combined with the constraints expressed in its host language implementation.

  4. The document must use either of the following:
    1. The following Doctype declaration: <DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Adaptable Applications//EN" "http://www.w3.org/2005/07/aaa/xhtml11-aaa.dtd"> This extends XHTML with ARIA States and Properties added to the common attribute set.

      Editorial Note: the public string of the DTD may need to be updated to match ARIA name, here and elsewhere it appears. We also need to look at what this would do to the aria namespace, and whether it should have trailing slash (currently does because of link checker).

    2. The document may also contain an XML Namespace [XML-NAMES] declaration for the author properties namespace. The namespace for States and Properties module is defined to be: http://www.w3.org/2005/07/aaa. An example start tag of a root element might look like:
      <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" xmlns:aria="http://www.w3.org/2005/07/aaa" >

6.2 User Agent Conformance

User agents that conform to States and Properties Module for Accessible Rich Internet Applications expose state information provided by the author to assistive technologies, and if they are assistive technologies themselves, use state information to enhance the presentation and interaction. Conformance requirements:

  1. User agents MUST support the role attribute and attributes for each state and property (prefixed with "aria-") in no namespace, when specified on elements in the namespaces of supported languages, and in the namespace of languages for which the user agent provides ARIA support (e.g., XHTML, SVG).

  2. User agents MUST process values of the role attribute as follows:

    • Create a set of zero or more tokens by splitting the value string on spaces, using the HTML 5 algorithm for Tokens ([HTML5], Section 3.2.6). Tokens are case-sensitive opaque strings that are matched against a list of ARIA keywords. Execute the following on each token in order.
    • If the token matches a role as defined in this specification, use this token as the ARIA role and end processing of the value.
    • If the token matches a supported custom role that is known to map to an accessibility API, use this token as the ARIA role and end processing of the value.
    • If all tokens are processed and no supported role has been found, the element is not treated in accordance with ARIA roles.

    Note: this procedure applies to processing of the role attribute for ARIA only. There may be values of this attribute that are of interest but not for ARIA purposes. Processing the attribute for those purposes should neither interfere with nor be disrupted by the processing described here for ARIA.

  3. User agents MUST process attributes in no namespace that are specified on elements that support ARIA whose name begins with "aria-" by truncating the prefix and using the resulting value as the name of the state or property. The attribute value MUST be processed in accordance with the specification for that particular state or property.

  4. User agents MUST make all author provided roles, states and properties, and their values available in the DOM, using the attribute name, namespace, and values defined in this specification. The value of the role attribute so exposed must be the entire string value, not the particular token recognized by the user agent as the supported role. This requirement parallels User Agent Accessibility Guidelines 1.0 Section 6.2: DOM access to HTML/XML content ([UAAG], Section 6.2) and is also required by the DOM Core specification.

  5. User agents SHOULD expose role, state, and property information provided by the author to the platform accessibility API (using the values as determined in steps 2 and 3 above). Refer to Mapping States and Properties to Accessibility APIs ([ARIA-PRACTICES], Section 12.1) for guidance about how to expose this information. This requirement parallels User Agent Accessibility Guidelines 1.0 Section 6.3: Programmatic Access to non-HTML/XML Content ([UAAG], Section 6.3), except that it applies even to HTML and XML content.

    Note: Not all platforms provide accessibility APIs, or provide interfaces that map to all the roles, states, and properties defined in this specification. User agents should expose those roles, states, and properties that are supported in order to support assistive technologies that work through the accessibility API. The remaining roles, states, and properties are available to assistive technologies via the DOM as per point 1 above, for those that provide explicit support for this specification.

  6. User agents MUST override implicit roles of elements with roles provided by the author. This applies to elements that have particular default roles because of the semantics declared by the content technology. Processing, mapping to the accessibility API, and presentation must be appropriate to the declared ARIA role.

  7. User agents MUST NOT implement ARIA support in such a manner that they recognize the ARIA attributes in any namespace, since this excessively restricts the possibilities for local names in those namespaces. User agents MUST recognize ARIA attributes only in the namespaces of technologies for which ARIA is explicitly supported. When user agents add ARIA support to a technology in this manner, the specification for that technology SHOULD be updated to indicate that ARIA is supported by the specification.

  8. Assistive technologies that conform to this specification MUST use role information to present content to, and support interaction with, users in a manner appropriate to that role, and use state and property information to present content to, and support interaction, with users in a manner appropriate to that state or property. The manner in which this is done is specific to each user agent but should be appropriate to the specified description of the state or property. This requirements parallels User Agent Accessibility Guidelines 1.0 Section 6.5: Programmatic operation of user agent user interface and Section 6.6: Programmatic notification of changes ([UAAG], Section 6.5 and 6.6) except that it applies to content, not just the user agent itself.

    Note: This does not specify how assistive technology obtains role, state, and property information. Assistive technologies may obtain this information directly from content, through the DOM, or through the platform accessibility API. In the latter case, only incomplete state and property information may be available. This point only requires that assistive technology use the states and properties that are actually available to it to support the user.

7 Appendices

7.1 Implementations

7.1.1 Roles Implementation

This section is informative.

Editorial note: the following references are used by the RDF but are not otherwise referenced in the document, and therefore are uncited. Explanations of these resources will be integrated into the prose.

[SKOS]
SKOS is an area of work developing specifications and standards to support the use of knowledge organisation systems (KOS) such as thesauri, classification schemes, subject heading lists, taxonomies, terminologies, glossaries and other types of controlled vocabulary within the framework of the Semantic Web.
[DAISY]
DAISY denotes the Digital Accessible Information System
[NIMAS]
NIMAS the National Instructional Materials Accessibility Standard (NIMAS), is a voluntary standard to guide the production and electronic distribution of flexible digital instructional materials, such as textbooks, so that they can be more easily converted to Braille, text-to-speech, and other accessible formats.
[DTB]
The Digital Talking Book standard that defines the format and content of the electronic file set that comprises a digital talking book (DTB) and establishes a limited set of requirements for DTB playback devices.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
  <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
  <!ENTITY dc "http://dublincore.org/2003/03/24/dces#">
  <!ENTITY owl "http://www.w3.org/2002/07/owl#">
  <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
  <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <!ENTITY states "http://www.w3.org/2005/07/aaa#">
]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:role="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
         xmlns:states="http://www.w3.org/2005/07/aaa#"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
         xmlns:dc="http://purl.org/dc/elements/1.1/#"
         xmlns:owl="http://www.w3.org/2002/07/owl#"
         xml:base="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy"><!--==Objects==--><owl:ObjectProperty rdf:ID="relatedConcept">
      <rdfs:comment xml:lang="en">The URI of similar/related types from
		  other specifications (See SKOS). This has been replaced in the implementation
		  with rdfs:seeAlso.</rdfs:comment>
      <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI"/>
      <rdfs:domain rdf:resource="#roletype"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="baseConcept">
      <rdfs:comment xml:lang="en">This is similar to type but without
		  inheritance of limitations and properties. role:baseConcepts are designed as
		  a substitute for inheritance for external concepts. </rdfs:comment>
      <rdfs:subpropertyOf rdf:resource="#relatedConcept"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="supportedState">
      <rdfs:comment xml:lang="en">A state that can be supported for this a
		  Role</rdfs:comment>
      <rdfs:domain rdf:resource="#roletype"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="scope">
      <rdfs:comment xml:lang="en">Context where this role is
		  allowed</rdfs:comment>
      <rdfs:domain rdf:resource="#roletype"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="mustContain">
      <rdfs:comment xml:lang="en">A child that must be contained by this
		  role</rdfs:comment>
      <rdfs:subpropertyOf rdf:resource="#scope"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="default">
      <rdfs:comment>Default value of a supported state in the context of
		  this role</rdfs:comment>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="nameFrom">
      <rdfs:comment>How a role type name is extracted and referenced 
		  inside a document. Values are "author": name comes from values 
		  provided by the author in explict markup features; and "subtree": 
		  name comes from the text value of the element node.</rdfs:comment>
      <rdfs:domain rdf:resource="#widget"/>
   </owl:ObjectProperty>
   <owl:ObjectProperty rdf:ID="childrenArePresentational">
      <rdfs:comment xml:lang="en">The children are presenational. Assistive
				technologies may choose to hid the children from the user.</rdfs:comment>
      <rdf:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
      <rdfs:domain rdf:resource="#roletype"/>
   </owl:ObjectProperty>
   <!--== Base Types ==--><owl:Class rdf:ID="roletype">
      <rdfs:subClassOf>
         <owl:Restriction>
            <owl:onProperty rdf:resource="http://dublincore.org/2003/03/24/dces#description"/>
            <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#string">1</owl:cardinality>
         </owl:Restriction>
      </rdfs:subClassOf>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/xhtml-role/#s_role_module_attributes"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/struct/links.html#edef-LINK"/>
      <rdfs:seeAlso rdf:resource="http://purl.org/dc/elements/1.1/type"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#datatype"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#describedby"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#dropeffect">
         <role:default>none</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#flowto"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#grab">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#haspopup">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#hidden">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#labelledby"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#owns"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#tabindex"/>
   </owl:Class>
   <owl:Class rdf:ID="widget">
      <rdfs:subClassOf rdf:resource="#roletype"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#controls"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#disabled">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="structure">
      <rdfs:subClassOf rdf:resource="#roletype"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#atomic">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#busy">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#channel">
         <role:default>main</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#live">
         <role:default>off</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#relevant">
         <role:default>text</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="composite">
      <rdfs:subClassOf rdf:resource="#widget"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#activedescendant"/>
   </owl:Class>
   <owl:Class rdf:ID="window">
      <rdfs:subClassOf rdf:resource="#roletype"/>
   </owl:Class>
   <!--== User Input Controls ==--><owl:Class rdf:ID="input">
      <rdfs:subClassOf rdf:resource="#widget"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-input"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#invalid">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#required">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="select">
      <rdfs:subClassOf rdf:resource="#composite"/>
      <rdfs:subClassOf rdf:resource="#group"/>
      <rdfs:subClassOf rdf:resource="#input"/>
   </owl:Class>
   <owl:Class rdf:ID="listbox">
      <rdfs:subClassOf rdf:resource="#list"/>
      <rdfs:subClassOf rdf:resource="#select"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/interact/forms.html#edef-SELECT"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-selectMany"/>
      <role:mustContain rdf:resource="#option"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#multiselectable">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="combobox">
      <rdfs:subClassOf rdf:resource="#select"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/interact/forms.html#edef-SELECT"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-selectMany"/>
      <role:mustContain rdf:resource="#option"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#autocomplete">
         <role:default>none</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="option">
      <rdfs:subClassOf rdf:resource="#input"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/interact/forms.html#edef-OPTION"/>
      <rdfs:seeAlso rdf:resource="#listitem"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-item"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#checked">
         <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>
   <owl:Class rdf:ID="checkbox">
      <rdfs:subClassOf rdf:resource="#option"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/interact/forms.html#edef-INPUT"/>
   </owl:Class>
   <owl:Class rdf:ID="radio">
      <rdfs:subClassOf rdf:resource="#checkbox"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/interact/forms.html#edef-INPUT"/>
   </owl:Class>
   <owl:Class rdf:ID="radiogroup">
      <rdfs:subClassOf rdf:resource="#select"/>
      <role:mustContain rdf:resource="#radio"/>
   </owl:Class>
   <owl:Class rdf:ID="textbox">
      <rdfs:subClassOf rdf:resource="#input"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-input"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/interact/forms.html#edef-TEXTAREA"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#autocomplete">
         <role:default>none</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#multiline">
         <role:default>false</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#secret">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="range">
      <rdfs:subClassOf rdf:resource="#input"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuemax"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuemin"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuenow"/>
   </owl:Class>
   <owl:Class rdf:ID="spinbutton">
      <rdfs:subClassOf rdf:resource="#composite"/>
      <rdfs:subClassOf rdf:resource="#range"/>
   </owl:Class>
   <!--== User Interface Elements ==--><owl:Class rdf:ID="button">
      <rdfs:subClassOf rdf:resource="#widget"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON"/>
      <rdfs:seeAlso rdf:resource="#link"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-button"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#pressed">
         <role:default>undefined</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="link">
      <rdfs:subClassOf rdf:resource="#widget"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/struct/links.html#edef-LINK"/>
   </owl:Class>
   <owl:Class rdf:ID="menu">
      <rdfs:subClassOf rdf:resource="#list"/>
      <rdfs:subClassOf rdf:resource="#select"/>
      <rdfs:seeAlso rdf:resource="http://www.loc.gov/nls/z3986/v100/dtbook110doc.htm#sidebar"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-selectMany"/>
      <rdfs:seeAlso rdf:resource="http://java.sun.com/j2se/1.3/docs/api/javax/accessibility/AccessibleRole.html#MENU"/>
      <role:mustContain rdf:resource="#menuitem"/>
   </owl:Class>
   <owl:Class rdf:ID="menubar">
      <rdfs:subClassOf rdf:resource="#group"/>
      <rdfs:seeAlso rdf:resource="#toolbar"/>
   </owl:Class>
   <owl:Class rdf:ID="toolbar">
      <rdfs:subClassOf rdf:resource="#group"/>
      <rdfs:seeAlso rdf:resource="#menubar"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#multiselectable">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="menuitem">
      <rdfs:subClassOf rdf:resource="#listitem"/>
      <rdfs:subClassOf rdf:resource="#option"/>
      <rdfs:seeAlso rdf:resource="http://java.sun.com/j2se/1.3/docs/api/javax/accessibility/AccessibleRole.html#MENU_ITEM"/>
      <role:scope rdf:resource="#menu"/>
   </owl:Class>
   <owl:Class rdf:ID="menuitemcheckbox">
      <rdfs:subClassOf rdf:resource="#checkbox"/>
      <rdfs:subClassOf rdf:resource="#menuitem"/>
      <rdfs:seeAlso rdf:resource="#menuitem"/>
      <role:scope rdf:resource="#menu"/>
   </owl:Class>
   <owl:Class rdf:ID="menuitemradio">
      <rdfs:subClassOf rdf:resource="#menuitem"/>
      <rdfs:subClassOf rdf:resource="#radio"/>
      <rdfs:seeAlso rdf:resource="#menuitem"/>
      <role:scope rdf:resource="#menu"/>
   </owl:Class>
   <owl:Class rdf:ID="slider">
      <rdfs:subClassOf rdf:resource="#range"/>
   </owl:Class>
   <owl:Class rdf:ID="tooltip">
      <rdfs:subClassOf rdf:resource="#description"/>
   </owl:Class>
   <owl:Class rdf:ID="tabpanel">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="tablist">
      <rdfs:subClassOf rdf:resource="#directory"/>
      <rdfs:seeAlso rdf:resource="http://www.daisy.org/z3986/2005/z3986-2005.html#Guide"/>
   </owl:Class>
   <owl:Class rdf:ID="tab">
      <rdfs:subClassOf rdf:resource="#sectionhead"/>
      <rdfs:subClassOf rdf:resource="#widget"/>
      <role:scope rdf:resource="#tablist"/>
   </owl:Class>
   <owl:Class rdf:ID="tree">
      <rdfs:subClassOf rdf:resource="#select"/>
      <role:mustContain rdf:resource="#treeitem"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#multiselectable">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="treeitem">
      <rdfs:subClassOf rdf:resource="#listitem"/>
      <rdfs:subClassOf rdf:resource="#option"/>
      <role:scope rdf:resource="#tree"/>
      <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#level"/>
   </owl:Class>
   <!--== Document Structure ==--><owl:Class rdf:ID="section">
      <rdfs:subClassOf rdf:resource="#structure"/>
      <rdfs:seeAlso rdf:resource="http://www.loc.gov/nls/z3986/v100/dtbook110doc.htm#frontmatter"/>
      <rdfs:seeAlso rdf:resource="http://www.loc.gov/nls/z3986/v100/dtbook110doc.htm#level"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/REC-smil/#par"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#templateid"/>
   </owl:Class>
   <owl:Class rdf:ID="sectionhead">
      <rdfs:subClassOf rdf:resource="#structure"/>
   </owl:Class>
   <owl:Class rdf:ID="document">
      <rdfs:subClassOf rdf:resource="#structure"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/di-gloss/#def-delivery-unit"/>
   </owl:Class>
   <owl:Class rdf:ID="region">
      <rdfs:subClassOf rdf:resource="#section"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/present/frames.html#edef-FRAME"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/di-gloss/#def-perceivable-unit"/>
      <rdfs:seeAlso rdf:resource="#section"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#controls"/>
      <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#level"/>
   </owl:Class>
   <owl:Class rdf:ID="heading">
      <rdfs:subClassOf rdf:resource="#sectionhead"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H1"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H2"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H3"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H4"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H5"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html4/struct/global.html#edef-H6"/>
      <rdfs:seeAlso rdf:resource="http://www.loc.gov/nls/z3986/v100/dtbook110doc.htm#levelhd"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#level"/>
   </owl:Class>
   <owl:Class rdf:ID="list">
      <rdfs:subClassOf rdf:resource="#region"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/lists.html#edef-UL"/>
      <role:mustContain rdf:resource="#group"/>
      <role:mustContain rdf:resource="#listitem"/>
   </owl:Class>
   <owl:Class rdf:ID="listitem">
      <rdfs:subClassOf rdf:resource="#section"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/lists.html#edef-LI"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-item"/>
      <role:scope rdf:resource="#list"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#posinset"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#setsize"/>
   </owl:Class>
   <owl:Class rdf:ID="group">
      <rdfs:subClassOf rdf:resource="#section"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/interact/forms.html#edef-FIELDSET"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#activedescendant"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#controls"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#expanded">
         <role:default>undefined</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="grid">
      <rdfs:subClassOf rdf:resource="#composite"/>
      <rdfs:subClassOf rdf:resource="#section"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TABLE"/>
      <role:mustContain rdf:resource="#row"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#level"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#multiselectable">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#readonly">
         <role:default>false</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="row">
      <rdfs:subClassOf rdf:resource="#group"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TR"/>
      <role:scope rdf:resource="#grid"/>
      <role:scope rdf:resource="#treegrid"/>
      <role:mustContain rdf:resource="#gridcell"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#disabled">
         <role:default>false</role:default>
      </role:supportedState>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#level"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#selected">
         <role:default>undefined</role:default>
      </role:supportedState>
   </owl:Class>
   <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>
   <owl:Class rdf:ID="rowheader">
      <rdfs:subClassOf rdf:resource="#gridcell"/>
      <rdfs:subClassOf rdf:resource="#sectionhead"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TH"/>
      <role:scope rdf:resource="#row"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#sort">
         <role:default>none</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="columnheader">
      <rdfs:subClassOf rdf:resource="#gridcell"/>
      <rdfs:subClassOf rdf:resource="#sectionhead"/>
      <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TH"/>
      <role:scope rdf:resource="#row"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#sort">
         <role:default>none</role:default>
      </role:supportedState>
   </owl:Class>
   <owl:Class rdf:ID="treegrid">
      <rdfs:subClassOf rdf:resource="#grid"/>
      <rdfs:subClassOf rdf:resource="#tree"/>
      <role:mustContain rdf:resource="#row"/>
   </owl:Class>
   <owl:Class rdf:ID="description">
      <rdfs:subClassOf rdf:resource="#section"/>
   </owl:Class>
   <owl:Class rdf:ID="directory">
      <rdfs:subClassOf rdf:resource="#list"/>
      <rdfs:seeAlso rdf:resource="http://www.daisy.org/z3986/2005/z3986-2005.html#Guide"/>
      <role:mustContain rdf:resource="#link"/>
   </owl:Class>
   <owl:Class rdf:ID="img">
      <rdfs:subClassOf rdf:resource="#section"/>
      <rdfs:seeAlso rdf:resource="http://www.loc.gov/nls/z3986/v100/dtbook110doc.htm#imggroup"/>
   </owl:Class>
   <owl:Class rdf:ID="presentation">
      <rdfs:subClassOf rdf:resource="#structure"/>
   </owl:Class>
   <owl:Class rdf:ID="separator">
      <rdfs:subClassOf rdf:resource="#structure"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/html401/present/graphics.html#edef-HR"/>
   </owl:Class>
   <!--== Specialized Regions ==--><owl:Class rdf:ID="application">
      <rdfs:subClassOf rdf:resource="#region"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/di-gloss/#def-delivery-unit"/>
   </owl:Class>
   <owl:Class rdf:ID="dialog">
      <rdfs:subClassOf rdf:resource="#window"/>
   </owl:Class>
   <owl:Class rdf:ID="alert">
      <rdfs:subClassOf rdf:resource="#status"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-alert"/>
   </owl:Class>
   <owl:Class rdf:ID="alertdialog">
      <rdfs:subClassOf rdf:resource="#alert"/>
      <rdfs:subClassOf rdf:resource="#dialog"/>
      <rdfs:seeAlso rdf:resource="http://www.w3.org/TR/2007/REC-xforms-20071029/#ui-common-elements-alert"/>
   </owl:Class>
   <owl:Class rdf:ID="marquee">
      <rdfs:subClassOf rdf:resource="#section"/>
   </owl:Class>
   <owl:Class rdf:ID="log">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="status">
      <rdfs:subClassOf rdf:resource="#composite"/>
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="progressbar">
      <rdfs:subClassOf rdf:resource="#status"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuemax"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuemin"/>
      <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#valuenow"/>
   </owl:Class>
   <owl:Class rdf:ID="timer">
      <rdfs:subClassOf rdf:resource="#status"/>
   </owl:Class>
   <!--== Landmark Roles Inherited from the XHTML Role Attribute Module ==--><owl:Class rdf:ID="banner">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="contentinfo">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="definition">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="main">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="navigation">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="note">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="search">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="secondary">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
   <owl:Class rdf:ID="seealso">
      <rdfs:subClassOf rdf:resource="#region"/>
   </owl:Class>
</rdf:RDF>

7.1.2 Qualified Names Module

Note that this module defines the parameter entity aria.attrs.qname;. This entity is intended to be used in the attribute lists of elements in any host language that permits the use of aria attributes on elements in its own namespace. In this case the Host Language driver should set a parameter entity %aria.prefixed; to INCLUDE. The default prefix to be used is aria:.

<!-- ...................................................................... -->
<!-- aria-qname Module ................................................... -->
<!-- file: aria-qname.mod

PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications Namespace//EN"
SYSTEM "http://www.w3.org/2005/07/aaa/aria-qname.mod"
xmlns:aria="http://www.w3.org/2005/07/aaa"
...................................................................... -->

<!ENTITY % XHTML.version
    "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications Namespace//EN" >

<!-- 1. Namespace declarations ::::::::::::::::::::::::::::: -->

<!ENTITY % NS.prefixed "IGNORE" >
<!ENTITY % aria.prefixed "%NS.prefixed;" >

<!-- Declare the actual namespace of this module -->

<!ENTITY % aria.xmlns "http://www.w3.org/2005/07/aaa" >

<!ENTITY % aria.prefix   "aria" >
<![%aria.prefixed;[
<!ENTITY % aria.xmlns.extra.attrib "" >
]]>

<!ENTITY % aria.xmlns.extra.attrib "" >

<![%aria.prefixed;[
<!ENTITY % aria.pfx  "%aria.prefix;:" >

<!ENTITY % aria.xmlns.attrib "
    xmlns:%aria.prefix;  CDATA   #FIXED '%aria.xmlns;'
    %aria.xmlns.extra.attrib;
">
]]>

<!ENTITY % aria.pfx "" >
<!ENTITY % aria.xmlns.attrib "
    xmlns CDATA #FIXED '%aria.xmlns;'
    %aria.xmlns.extra.attrib;
">

<![%NS.prefixed;[
<!ENTITY % XHTML.xmlns.extra.attrib "%aria.xmlns.attrib;" >
]]>

<!-- 2. XML Qualified Names for ARIA ::::::::::::::::::::::::::::: -->

<!--   This section declares parameter entities used to provide
        namespace-qualified names for all element types.
-->

<!ENTITY % xhtml-datatypes.mod
    PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN"
    "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-datatypes-1.mod" >
%xhtml-datatypes.mod;

<!-- core attributes to add to all elements; -->

<!-- states -->

<!ENTITY % aria.busy.qname "%aria.pfx;busy">
<!ENTITY % aria.checked.qname "%aria.pfx;checked">
<!ENTITY % aria.disabled.qname "%aria.pfx;disabled">
<!ENTITY % aria.expanded.qname "%aria.pfx;expanded">
<!ENTITY % aria.grab.qname "%aria.pfx;grab">
<!ENTITY % aria.hidden.qname "%aria.pfx;hidden">
<!ENTITY % aria.invalid.qname "%aria.pfx;invalid">
<!ENTITY % aria.pressed.qname "%aria.pfx;pressed">
<!ENTITY % aria.selected.qname "%aria.pfx;selected">

<!-- properties -->


<!-- tabindex -->

<!ENTITY % aria.tabindex.qname "tabindex">

<!-- The following defines a PE for use in the attribute sets of elements in
     other namespaces that want to incorporate the XML Role attributes. Note
     that in this case the XML-ROLES.pfx should always be defined. -->
     
<!ENTITY % aria.states.qname "

    %aria.busy.qname; ( true | false | error ) 'false'
    %aria.checked.qname; ( true | false | mixed |  ) ''
    %aria.disabled.qname; ( true | false ) 'false'
    %aria.expanded.qname; ( true | false | undefined ) 'undefined'
    %aria.grab.qname; ( true | supported | false ) 'false'
    %aria.hidden.qname; ( true | false ) 'false'
    %aria.invalid.qname; ( true | false ) 'false'
    %aria.pressed.qname; ( true | false | mixed | undefined ) 'undefined'
    %aria.selected.qname; ( true | false | undefined ) 'undefined'
">

<!ENTITY % aria.props.qname "

">

<!ENTITY % aria.extra.attrs.qname
    "%aria.tabindex.qname;   %Number.datatype;   #IMPLIED"
>

<!ENTITY % aria.attrs.qname "
    %aria.states.qname;
    %aria.props.qname; 
    %aria.extra.attrs.qname;
">

<!ENTITY % aria-qname.module "IGNORE" >

<!-- End aria-qname Module ................................................... -->

7.1.3 ELEMENTS XHTML 1.1 For Accessible Adaptable Applications DTD

This DTD extends XHTML 1.1 and adds the States and Property attributes to all its elements.

The attribute tabindex is added to elements p, div, span, th, td and li

<!-- ELEMENTS  DTD XHTML 1.1 For Accessible Rich Internet Applications -->
<!-- File: xhtml11-aria-base.dtd

 This DTD module is identified by the PUBLIC and SYSTEM identifiers:

 PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
 SYSTEM "http://www.w3.org/2005/07/aaa/xhtml11-aria-base.dtd"
 xmlns:aria="http://www.w3.org/2005/07/aaa"

 The DOCTYPE declaration that should be used is as follows;

        <!DOCTYPE html
        PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
        "http://www.w3.org/2005/07/aaa/xhtml11-aria-base.dtd">

...................................................................... -->

<!ENTITY % XHTML.version
    "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Adaptable Applications//EN" >

<!-- ARIA module -->

<!ENTITY % aria-qname.mod
    PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Adaptable Applications Namespace//EN"
    "http://www.w3.org/2005/07/aaa/aria-qname.mod" >

%aria-qname.mod;

<!-- XHTML Role attribute module -->

<!ENTITY % role-qname.mod
	PUBLIC "-//W3C//ENTITIES XHTML Role Attribute Qnames 1.0//EN"
	"http://www.w3.org/MarkUp/DTD/xhtml-role-qname-1.mod" >

%role-qname.mod;

<!-- add ARIA attribute set to all XHTML elements -->
<!-- also add XHTML Role attribute to all XHTML elements -->

<!ENTITY % Common.extra.attrib
    "%aria.attrs.qname;
    %xhtml-role.attrs.qname;"
>

<!ENTITY % xhtml11.mod
    PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"

>

%xhtml11.mod;

<!-- add tabindex to text containers -->

<!ATTLIST %div.qname;
    %aria.extra.attrs.qname;
>

<!ATTLIST %span.qname;
    %aria.extra.attrs.qname;
>

<!ATTLIST %p.qname;
    %aria.extra.attrs.qname;
>

<!ATTLIST %th.qname;
    %aria.extra.attrs.qname;
>

<!ATTLIST %td.qname;
    %aria.extra.attrs.qname;
>

<!ATTLIST %li.qname;
    %aria.extra.attrs.qname;
>

<!ENTITY % aria.prefixed "INCLUDE">

<!-- End xhtml11-aria-base.dtd  -->

7.1.4 XHTML 1.1 For Accessible Adaptable Applications DTD

This DTD requires the use of the "aria" prefix.

<!-- DTD XHTML 1.1 For Accessible Adaptable Applications -->

<!-- File: xhtml11-aria.dtd

 This DTD module is identified by the PUBLIC and SYSTEM identifiers:

 PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
 SYSTEM "http://www.w3.org/2005/07/aaa/xhtml11-aria.dtd"
 xmlns:aria="http://www.w3.org/2005/07/aaa"

 The DOCTYPE declaration that should be used is as follows;

        <!DOCTYPE html
        PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
        "http://www.w3.org/2005/07/aaa/xhtml11-aria.dtd">


...................................................................... -->

<!ENTITY % XHTML.version
    "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"

>

<!-- Enable prefixing -->

<!ENTITY % aria.prefixed "INCLUDE">

<!ENTITY % xhtml11-aria.mod
    PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Rich Internet Applications//EN"
    "http://www.w3.org/2005/07/aaa/xhtml11-aria-base.dtd" >

%xhtml11-aria.mod;

<!-- End xhtml11-aria.dtd -->

7.2 Glossary

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) [ATK], 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 specification, 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.

Managed State
 
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.

Widget

7.3 References

This section is informative.

[AAC]
Apple Accessibility for Cocoa. Available at: http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/index.html.
[ARIA-PRACTICES]
WAI-ARIA Best Practices. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Best Practices is available at http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/. Latest version of WAI-ARIA Best Practices available at http://www.w3.org/TR/wai-aria-practices/.
[ARIA-PRIMER]
WAI-ARIA Primer. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Primer is available at http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/. Latest version of WAI-ARIA Primer available at http://www.w3.org/TR/wai-aria-primer/.
[ARIA-ROADMAP]
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap), R. Schwerdtfeger, Editor, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Roadmap is available at http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/. Latest version of WAI-ARIA Roadmap available at http://www.w3.org/TR/wai-aria-roadmap/.
[ATK]
Gnome Accessibility Toolkit. Available at http://library.gnome.org/devel/atk/unstable/.
[CSS]
Cascading Style Sheets, level 2 (CSS2) Specification, I. Jacobs, B. Bos, H. Lie, C. Lilley, Editors, W3C Recommendation, 12 May 1998, http://www.w3.org/TR/1998/REC-CSS2-19980512/. Latest version of CSS2 available at http://www.w3.org/TR/REC-CSS2/.
[CURIE]
CURIE Syntax 1.0, M. Birbeck, S. McCarron, Editors, W3C Working Draft (work in progress), 26 November 2007, http://www.w3.org/TR/2007/WD-curie-20071126/. Latest version of CURIE Syntax available at http://www.w3.org/TR/curie/.
[DOM]
Document Object Model (DOM) Level 2 Core Specification, L. Wood, G. Nicol, A. Le Hors, J. Robie, S. Byrne, P. Le Hégaret, M. Champion, Editors, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/. Latest version of DOM Core available at http://www.w3.org/TR/DOM-Level-2-Core/.
[HTML5]
HTML 5, D. Hyatt, I. Hickson, Editors, W3C Working Draft (work in progress), 22 January 2008, http://www.w3.org/TR/2008/WD-html5-20080122/. Latest version of HTML 5 available at http://www.w3.org/TR/html5/.
[IA2]
IAccessible2. Available at http://www.linux-foundation.org/en/Accessibility/IAccessible2.
[JAPI]
Java Accessibility API (JAPI). Available at http://java.sun.com/javase/technologies/accessibility/index.jsp.
[MSAA]
Microsoft Active Accessibility (MSAA). Available at http://msdn2.microsoft.com/en-us/library/ms697707.aspx.
[OWL]
OWL Web Ontology Language Overview, D. L. McGuinness, F. van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/. Latest version of OWL Overview available at http://www.w3.org/TR/owl-features/.
[RDF]
Resource Description Framework (RDF): Concepts and Abstract Syntax, G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Latest version of RDF Concepts available at http://www.w3.org/TR/rdf-concepts/.
[RDFS]
RDF Vocabulary Description Language 1.0: RDF Schema, D. Brickley, R. V. Guha, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Latest version of RDF Schema available at http://www.w3.org/TR/rdf-schema/.
[SMIL]
Synchronized Multimedia Integration Language (SMIL) 1.0 Specification, P. Hoschka, Editor, W3C Recommendation, 15 June 1998, http://www.w3.org/TR/1998/REC-smil-19980615/. Latest version of SMIL available at http://www.w3.org/TR/REC-smil/.
[SVG]
Scalable Vector Graphics (SVG) 1.1 Specification, D. Jackson, J. Ferraiolo, 藤沢, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/. Latest version of SVG available at http://www.w3.org/TR/SVG11/.
[UAAG]
User Agent Accessibility Guidelines 1.0, I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/. Latest version available at http://www.w3.org/TR/UAAG10/.
[XFORMS]
XForms 1.0 (Third Edition), J. Boyer, Editor, W3C Recommendation, 29 October 2007, http://www.w3.org/TR/2007/REC-xforms-20071029/. Latest version of XForms available at http://www.w3.org/TR/xforms/.
[XHTML]
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), S. Pemberton, Editor, W3C Recommendation, 1 August 2002, http://www.w3.org/TR/2002/REC-xhtml1-20020801/. Latest version of XHTML 1.0 available at http://www.w3.org/TR/xhtml1/.
[XHTML2]
XHTML™ 2.0, M. Birbeck, J. Axelsson, S. Pemberton, B. Epperson, S. McCarron, M. Ishikawa, A. Navarro, M. Dubinko, Editors, W3C Working Draft (work in progress), 26 July 2006, http://www.w3.org/TR/2006/WD-xhtml2-20060726/. Latest version of XHTML 2.0 available at http://www.w3.org/TR/xhtml2/.
[XHTMLMOD]
XHTML™ Modularization 1.1, M. Altheim, F. Boumphrey, S. McCarron, S. Schnitzenbaumer, S. Dooley, T. Wugofski, Editors, W3C Working Draft (work in progress), 5 July 2006, http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/. Latest version of XHTML Modularization available at http://www.w3.org/TR/xhtml-modularization/.
[XHTML-ROLES]
XHTML Role Attribute Module, T. V. Raman, M. Birbeck, R. Schwerdtfeger, S. McCarron, S. Pemberton, Editors, W3C Working Draft (work in progress), 4 October 2007, http://www.w3.org/TR/2007/WD-xhtml-role-20071004/. Latest version of XML Role Attribute Module available at http://www.w3.org/TR/xhtml-role/.
[XML]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, E. Maler, C. M. Sperberg-McQueen, F. Yergeau, Editors, W3C Recommendation, 16 August 2006, http://www.w3.org/TR/2006/REC-xml-20060816/. Latest version of XML available at http://www.w3.org/TR/xml/.
[XML-EVENTS]
XML Events 2, M. Birbeck, S. McCarron, Editors, W3C Working Draft (work in progress), 16 February 2007, http://www.w3.org/TR/2007/WD-xml-events-20070216/. Latest version of XML Events available at http://www.w3.org/TR/xml-events/.
[XML-NAMES]
Namespaces in XML 1.0 (Second Edition), D. Hollander, A. Layman, R. Tobin, T. Bray, Editors, W3C Recommendation, 16 August 2006, http://www.w3.org/TR/2006/REC-xml-names-20060816/. Latest version of XML Namespaces available at http://www.w3.org/TR/xml-names/.
[XSD]
XML Schema Part 0: Primer Second Edition, D. C. Fallside, P. Walmsley, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/. Latest version of XML Schema Primer available at http://www.w3.org/TR/xmlschema-0/.

7.4 Acknowledgments

This section is informative.

The following contributed to the development of this document.

7.4.1 Participants active in the PFWG at the time of publication

  • Chris Blouch (AOL)
  • Charles Chen (Google)
  • Michael Cooper (W3C/MIT)
  • Dimitar Denev (FIT)
  • Donald Evans (AOL)
  • Kentarou Fukuda (IBM)
  • Alfred S. Gilman (W3C Invited Expert)
  • Jon Gunderson (UIUC)
  • Kenny Johar (Vision Australia)
  • Diego La Monica (IWA/HWG)
  • Aaron Leventhal (IBM)
  • Thomas Logan (Invited Expert, BayFirst Solutions)
  • Matt May (Adobe)
  • Charles McCathieNevile (Opera)
  • Lisa Pappas (Invited Expert, SAS)
  • Dave Pawson (RNIB)
  • David Poehlman (Invited Expert, State of MD)
  • Gregory Rosmaita (Invited Expert, The Linux Foundation)
  • Janina Sajka (Invited Expert, The Linux Foundation)
  • Stefan Schnabel (SAP)
  • Richard Schwerdtfeger (IBM)
  • Lisa Seeman (UB Access)
  • Marc Silbey (Microsoft)
  • Mike Squillace (IBM)
  • Gottfried Zimmermann (Access Technologies Group)

7.4.2 Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification

Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility API bindings.

Jim Allan (TSBVI), Simon Bates, Judy Brewer (W3C/MIT), Christian Cohrs, Becky Gibson (IBM), Andres Gonzalez (Adobe), Georgios Grigoriadis (SAP AG), Jeff Grimes (Oracle), Barbara Hartel, Sean Hayes (Microsoft), John Hrvatin (Microsoft), Earl Johnson (Sun), Masahiko Kaneko (Microsoft), Jael Kurz, Alex Li (SAP AG), William Loughborough, Linda Mao (Microsoft), Anders Markussen (Opera), Dave Pawson (RNIB), T.V. Raman (Google), Vitaly Sourikov, Ryan Williams (Oracle), Tom Wlodkowski.

7.4.3 Enabling funders

This publication has been funded in part with Federal funds from the U.S. Department of Education under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.