States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) Version 1.0

1.1 Terms and Definitions

This section is informative.

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

Accessibility API

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

Assistive Technology

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

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

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

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

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

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

Attribute

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

Characteristic

An assertion which can be a constraint.

Class

An abstract type of object.

Element

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

Event

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

Namespace

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

Object

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

Property

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

Relationship

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

Role

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

State

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

User Agent

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

Value

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

1.2 Design Aims

This section is informative.

The design aims of creating this specification include:

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

1.3 Building Accessible Applications

This section is informative.

An application becomes accessible when:

1. Each element or widget has with full and correct semantics that completely describes its behavior (using element names or roles).
2. The relationships between elements and groups are known.
3. States, properties, and relationships are valid for each element's behavior and are accessible via the Document Object Model [DOM].
4. Allow script author to move focus to allow all document elements in the body to receive focus with or without effecting the tab order.

Features of the States and Properties Module can be used to provide information about any missing states, properties, and relationships that the assistive technology needs to understand the behavior of the elements inside the application.

States and Properties can be used to assign meaningful properties that change with time and events. For element types and semantics that do not change with time, use a role taxonomy such as such as that defined in Roles for Accessible Rich Internet Applications [ARIA-ROLE].

To build an accessible application first check that each element or widget is marked with full and correct semantics that fully describes its behavior. The procedure for this is described in ARIA Roles [ARIA-ROLE, Section 2.1]. Then use the features of this specification to ensure:

1. States, properties, and relationships are valid for each element's behavior and are accessible via the [DOM].
2. Elements have the correct input focus.

This requires the author to:

1. Set properties to define the behavior of the element.
2. Control the behavior of the element using device-independent events, states, and properties.
3. Where possible, tie the behavior of the user interface to accessible states and properties using style sheet selectors.

For example: If the user is required to fill in a form element, set the aria:required property to "true" on that element.

The States and Properties module also defines ways to indicate certain relationships. 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 aria:controls property in region B to reference region A (by ID).

Sometimes the relationships can be made clear via facilities of the native markup language, such as the label tag in [HTML]. Relationships can also be implied via the [DOM]. For example, when a well marked-up list contains list items, it is known that they belong to the containing list. In such cases you do not need to set properties from this specification to make the relationship explicit.

2.1 Using States and Properties Attached to an Element

This section is normative.

The use of ARIA states and properties in other non-xml host languages may help accessibility. If the host language produced a dynamic user interface where content may be scripted to produce new user interface concepts. Outside the host markup, the use of ARIA states and properties will help authors support platform assistive technologies when made available to them by the user agent.

Language profiles wishing to use these states and properties must 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 all methods as specified in XHTML Modularization [XHTMLMOD].

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

<?xml version="1.0" encoding="UTF-8"?>

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Rich Internet Applications//EN">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<title>DHTML Checkbox</title>
</head>

<body>

<p>Here's a three state checkbox that you can click on.</p>

<div class="checkbox " role="checkbox" id="chbox1" aria:required="true" 
  aria:readonly="true" onkeydown="return checkBoxEvent(event);"
  onclick="return checkBoxEvent(event);" >
Sign me up for all the weekly rdf and xml newsletters :)
</div>

</body>
</html>

<!DOCTYPE html PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Adaptable Applications//EN"

"http://www.w3.org/2005/07/aaa/xhtml11-aria-base.dtd" [

<!ENTITY % aria.prefixed "INCLUDE">

<!ENTITY % aria.prefix "state">

]>

 xmlns:aria="http://www.w3.org/2005/07/aaa"

<?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: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>

2.2 Examples

This section is informative.

This 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 the Roles for Accessible Rich Internet Applications [ARIA_ROLE].

<span
    class="checkbox" 
    id="chbox1" 
    role="wairole: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

}

Typically, States and Properties will work well with other supporting technologies, such as the Roles for Accessible Rich Internet Applications [ARIA_ROLE] and [XML events].

3.1 Characteristics of States and Properties

This section is normative.

The States and Properties Module supports the following characteristics:

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

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

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

@namespace waistate url("http://www.w3.org/2005/07/aaa");
[waistate|hidden=true] {visibility: collapsed;} 

4.1 Document Conformance

This section is normative.

States and Properties is not a stand-alone document type. It is intended to be integrated into other host languages such as 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. DTD Implementation combined with the constraints expressed in its host language implementation.

2. 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" >

4.2 Host Language Conformance

This section is normative.

When States and Properties are included in a host language, all of the facilities required in this specification must be included in the host language.

4.3 User Agent Conformance

This section is normative.

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 make all states and properties, and their values, provided by the author available in the DOM, using the attribute name, namespace, and values defined in this specification. This requirement parallels User Agent Accessibility Guidelines 1.0 Section 6.2: DOM access to HTML/XML content [UAAG, Section 6.2].

2. User agents SHOULD expose state and property information provided by the author to the platform accessibility API. Refer to Mapping States and Properties to Accessibility APIs in the Best Practices 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 states and properties defined in this specification. User agents should expose those states and properties that are supported in order to support assistive technologies that work through the accessibility API. The remaining 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.

3. Assistive technologies that conform to this specification MUST 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 state and property information. Assistive technologies may obtain state and property 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.

5.1 DTD Implementation

This section is normative.

<!-- ...................................................................... -->
<!-- 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.busy-list.qname "%aria.pfx;busy-list">
<!ENTITY % aria.checked.qname "%aria.pfx;checked">
<!ENTITY % aria.checked-list.qname "%aria.pfx;checked-list">
<!ENTITY % aria.disabled.qname "%aria.pfx;disabled">
<!ENTITY % aria.disabled-list.qname "%aria.pfx;disabled-list">
<!ENTITY % aria.expanded.qname "%aria.pfx;expanded">
<!ENTITY % aria.expanded-list.qname "%aria.pfx;expanded-list">
<!ENTITY % aria.grab.qname "%aria.pfx;grab">
<!ENTITY % aria.grab-list.qname "%aria.pfx;grab-list">
<!ENTITY % aria.hidden.qname "%aria.pfx;hidden">
<!ENTITY % aria.hidden-list.qname "%aria.pfx;hidden-list">
<!ENTITY % aria.invalid.qname "%aria.pfx;invalid">
<!ENTITY % aria.invalid-list.qname "%aria.pfx;invalid-list">
<!ENTITY % aria.pressed.qname "%aria.pfx;pressed">
<!ENTITY % aria.pressed-list.qname "%aria.pfx;pressed-list">
<!ENTITY % aria.selected.qname "%aria.pfx;selected">
<!ENTITY % aria.selected-list.qname "%aria.pfx;selected-list">

<!-- properties -->

<!ENTITY % aria.activedescendent.qname "%aria.pfx;activedescendent">
<!ENTITY % aria.activedescendent-list.qname "%aria.pfx;activedescendent-list">
<!ENTITY % aria.atomic.qname "%aria.pfx;atomic">
<!ENTITY % aria.atomic-list.qname "%aria.pfx;atomic-list">
<!ENTITY % aria.autocomplete.qname "%aria.pfx;autocomplete">
<!ENTITY % aria.autocomplete-list.qname "%aria.pfx;autocomplete-list">
<!ENTITY % aria.channel.qname "%aria.pfx;channel">
<!ENTITY % aria.channel-list.qname "%aria.pfx;channel-list">
<!ENTITY % aria.controls.qname "%aria.pfx;controls">
<!ENTITY % aria.controls-list.qname "%aria.pfx;controls-list">
<!ENTITY % aria.datatype.qname "%aria.pfx;datatype">
<!ENTITY % aria.datatype-list.qname "%aria.pfx;datatype-list">
<!ENTITY % aria.describedby.qname "%aria.pfx;describedby">
<!ENTITY % aria.describedby-list.qname "%aria.pfx;describedby-list">
<!ENTITY % aria.dropeffect.qname "%aria.pfx;dropeffect">
<!ENTITY % aria.dropeffect-list.qname "%aria.pfx;dropeffect-list">
<!ENTITY % aria.flowto.qname "%aria.pfx;flowto">
<!ENTITY % aria.flowto-list.qname "%aria.pfx;flowto-list">
<!ENTITY % aria.haspopup.qname "%aria.pfx;haspopup">
<!ENTITY % aria.haspopup-list.qname "%aria.pfx;haspopup-list">
<!ENTITY % aria.labelledby.qname "%aria.pfx;labelledby">
<!ENTITY % aria.labelledby-list.qname "%aria.pfx;labelledby-list">
<!ENTITY % aria.level.qname "%aria.pfx;level">
<!ENTITY % aria.level-list.qname "%aria.pfx;level-list">
<!ENTITY % aria.live.qname "%aria.pfx;live">
<!ENTITY % aria.live-list.qname "%aria.pfx;live-list">
<!ENTITY % aria.multiline.qname "%aria.pfx;multiline">
<!ENTITY % aria.multiline-list.qname "%aria.pfx;multiline-list">
<!ENTITY % aria.multiselectable.qname "%aria.pfx;multiselectable">
<!ENTITY % aria.multiselectable-list.qname "%aria.pfx;multiselectable-list">
<!ENTITY % aria.owns.qname "%aria.pfx;owns">
<!ENTITY % aria.owns-list.qname "%aria.pfx;owns-list">
<!ENTITY % aria.posinset.qname "%aria.pfx;posinset">
<!ENTITY % aria.posinset-list.qname "%aria.pfx;posinset-list">
<!ENTITY % aria.readonly.qname "%aria.pfx;readonly">
<!ENTITY % aria.readonly-list.qname "%aria.pfx;readonly-list">
<!ENTITY % aria.relevant.qname "%aria.pfx;relevant">
<!ENTITY % aria.relevant-list.qname "%aria.pfx;relevant-list">
<!ENTITY % aria.required.qname "%aria.pfx;required">
<!ENTITY % aria.required-list.qname "%aria.pfx;required-list">
<!ENTITY % aria.secret.qname "%aria.pfx;secret">
<!ENTITY % aria.secret-list.qname "%aria.pfx;secret-list">
<!ENTITY % aria.setsize.qname "%aria.pfx;setsize">
<!ENTITY % aria.setsize-list.qname "%aria.pfx;setsize-list">
<!ENTITY % aria.sort.qname "%aria.pfx;sort">
<!ENTITY % aria.sort-list.qname "%aria.pfx;sort-list">
<!ENTITY % aria.tabindex-list.qname "%aria.pfx;tabindex-list">
<!ENTITY % aria.templateid.qname "%aria.pfx;templateid">
<!ENTITY % aria.templateid-list.qname "%aria.pfx;templateid-list">
<!ENTITY % aria.valuemax.qname "%aria.pfx;valuemax">
<!ENTITY % aria.valuemax-list.qname "%aria.pfx;valuemax-list">
<!ENTITY % aria.valuemin.qname "%aria.pfx;valuemin">
<!ENTITY % aria.valuemin-list.qname "%aria.pfx;valuemin-list">
<!ENTITY % aria.valuenow.qname "%aria.pfx;valuenow">
<!ENTITY % aria.valuenow-list.qname "%aria.pfx;valuenow-list">

<!-- 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.busy-list.qname; 
    %aria.checked.qname; ( true | false | mixed |  ) ''
    %aria.checked-list.qname; 
    %aria.disabled.qname; ( true | false ) 'false'
    %aria.disabled-list.qname; 
    %aria.expanded.qname; ( true | false | undefined ) 'undefined'
    %aria.expanded-list.qname; 
    %aria.grab.qname; ( true | supported | false ) 'false'
    %aria.grab-list.qname; 
    %aria.hidden.qname; ( true | false ) 'false'
    %aria.hidden-list.qname; 
    %aria.invalid.qname; ( true | false ) 'false'
    %aria.invalid-list.qname; 
    %aria.pressed.qname; ( true | false | mixed | undefined ) 'undefined'
    %aria.pressed-list.qname; 
    %aria.selected.qname; ( true | false | undefined ) 'undefined'
    %aria.selected-list.qname; 
">

<!ENTITY % aria.props.qname "

    %aria.posinset.qname; %Number.datatype; #IMPLIED
    %aria.posinset-list.qname; 
    %aria.setsize.qname; %Number.datatype; #IMPLIED
    %aria.setsize-list.qname; 
    %aria.activedescendent.qname; IDREF #IMPLIED
    %aria.activedescendent-list.qname; 
    %aria.atomic.qname; ( true | false ) 'false'
    %aria.atomic-list.qname; 
    %aria.autocomplete.qname; ( inline | list | both | none ) 'none'
    %aria.autocomplete-list.qname; 
    %aria.channel.qname; ( main | notify ) 'main'
    %aria.channel-list.qname; 
    %aria.controls.qname; IDREFS #IMPLIED
    %aria.controls-list.qname; 
    %aria.datatype.qname; CDATA #IMPLIED
    %aria.datatype-list.qname; 
    %aria.describedby.qname; IDREFS #IMPLIED
    %aria.describedby-list.qname; 
    %aria.dropeffect.qname; ( copy | move | reference | none ) 'none'
    %aria.dropeffect-list.qname; 
    %aria.flowto.qname; IDREFS #IMPLIED
    %aria.flowto-list.qname; 
    %aria.haspopup.qname; ( true | false ) 'false'
    %aria.haspopup-list.qname; 
    %aria.labelledby.qname; IDREFS #IMPLIED
    %aria.labelledby-list.qname; 
    %aria.level.qname; %Number.datatype; #IMPLIED
    %aria.level-list.qname; 
    %aria.live.qname; ( off | polite | assertive | rude ) 'off'
    %aria.live-list.qname; 
    %aria.multiline.qname; ( true | false ) 'false'
    %aria.multiline-list.qname; 
    %aria.multiselectable.qname; ( true | false ) 'false'
    %aria.multiselectable-list.qname; 
    %aria.owns.qname; IDREFS #IMPLIED
    %aria.owns-list.qname; 
    %aria.readonly.qname; ( true | false ) 'false'
    %aria.readonly-list.qname; 
    %aria.relevant.qname; ( additions | removals | text | all ) 'text'
    %aria.relevant-list.qname; 
    %aria.required.qname; ( true | false ) 'false'
    %aria.required-list.qname; 
    %aria.secret.qname; ( true | false ) 'false'
    %aria.secret-list.qname; 
    %aria.sort.qname; ( ascending | descending | none | other ) 'none'
    %aria.sort-list.qname; 
    %aria.tabindex-list.qname; 
    %aria.templateid.qname; CDATA #IMPLIED
    %aria.templateid-list.qname; 
    %aria.valuemax.qname; CDATA #IMPLIED
    %aria.valuemax-list.qname; 
    %aria.valuemin.qname; CDATA #IMPLIED
    %aria.valuemin-list.qname; 
    %aria.valuenow.qname; CDATA #IMPLIED
    %aria.valuenow-list.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 ................................................... -->

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

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

5.2 Managed States

This section is informative.

Managed states are state attributes managed and controlled by the user agent. 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 not managed (unmanaged) states.

Accessibility APIs typically map to both managed and unmanaged states. An example of a managed state would be element focus and hover.

Note: Invalid is a managed state in [XForms]. However in most other languages (such as [HTML] forms) it is not managed.

5.3 Elements with Tabindex added

Tabindex has been added to the following XHTML elements:

• abbr
• acronym
• address
• applet
• b
• bdo
• big
• blockquote
• body
• caption
• center
• cite
• custom
• dd
• del
• dfn
• dir
• div
• dl
• dt
• em
• fieldset
• font
• form
• frame
• frameset
• hn
• hr
• i
• iframe
• img
• ins
• isindex
• kbd
• label
• legend
• li
• listing
• marquee
• menu
• ol
• p
• plaintext
• pre
• q
• s
• samp
• small
• span
• strike
• sub
• sup
• table
• td
• th
• tr
• tt
• u
• ul
• var

Tabindex is not added to the following elements, because it is already supported in XHTML:

• a
• area
• button
• input
• object
• select
• textarea

5.4 Linearized version of data tables

@namespace waistate url("http://www.w3.org/2005/07/aaa");
[waistate|hidden=true] {visibility: collapsed;} 

5.5 References

This section is informative.

[AAC]

Apple Accessibility for Cocoa. Available at: http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/index.html.

[ARIA-ROLE]

Roles for Accessible Rich Internet Applications (WAI-ARIA Roles), L. Seeman, Editor. World Wide Web Consortium, 26 September 2006. This version of WAI-ARIA Roles is available at http://www.w3.org/TR/2006/WD-aria-role-20060926/. The latest version of WAI-ARIA Roles is available at http://www.w3.org/TR/aria-role/.

[ARIA-HTML]

Embedding ARIA in HTML 4.

[ARIA-ROADMAP]

Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap), R. Schwerdtfeger, Editor. World Wide Web Consortium, 26 September 2006. This version of WAI-ARIA Roadmap is available at http://www.w3.org/TR/2006/WD-aria-roadmap-20060926/. The latest version of WAI-ARIA Roadmap is available at http://www.w3.org/TR/aria-roadmap/.

[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 available at http://www.w3.org/TR/REC-CSS2/.

[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 available at http://www.w3.org/TR/DOM-Level-2-Core/.

[GAP]

Gnome Accessibility Project (GAP) State and StateSets. Available at: http://developer.gnome.org/projects/gap/tech-docs/at-spi-docs/at-spi-cspi-state-and-statesets.html.

[IA2]

IAccessible2. Available at http://www.linux-foundation.org/en/Accessibility/IAccessible2.

[JAPI]

Java Accessibility API (JAPI). Available at: http://java.sun.com/products/jfc/accessibility/index.jsp.

[MSAA]

Microsoft Active Accessibility (MSAA). Available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msaa/msaastart_9w2t.asp.

[RFC2119]

"Key words for use in RFCs to indicate requirement levels", RFC 2119, S. Bradner, March 1997. Available at: http://www.rfc-editor.org/rfc/rfc2119.txt.

[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 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 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/.

[WCAG20]

Web Content Accessibility Guidelines 2.0, M. Cooper, B. Caldwell, G. Vanderheiden, L. Guarino Reid, Editors, W3C Working Draft (work in progress), 17 May 2007, http://www.w3.org/TR/2007/WD-WCAG20-20070517/. Latest version available at http://www.w3.org/TR/WCAG20/.

[XFORMS]

XForms 1.0 (Second Edition), R. Merrick, M. Dubinko, T. V. Raman, J. Boyer, D. Landwehr, L. L. Klotz, Editors, W3C Recommendation, 14 March 2006, http://www.w3.org/TR/2006/REC-xforms-20060314/. Latest version 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 available at http://www.w3.org/TR/xhtml1/.

[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 available at http://www.w3.org/TR/xhtml-modularization/.

[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 available at http://www.w3.org/TR/xml/.

[XML-EVENTS]

XML Events, S. McCarron, S. Pemberton, T. V. Raman, Editors, W3C Recommendation, 14 October 2003, http://www.w3.org/TR/2003/REC-xml-events-20031014/. Latest version 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 available at http://www.w3.org/TR/xml-names/.

[XSD]

XML Schema Part 2: Datatypes Second Edition, A. Malhotra, P. V. Biron, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available at http://www.w3.org/TR/xmlschema-2/.

5.6 Acknowledgments

This section is informative.

The following contributed to the development of this document.