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

1.1 Terms and Definitions

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

Functionality

Processes and outcomes achievable through user action

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.

Assistive Technology

A user agent that:

1. Provides services beyond those offered by the host user agents to meet the requirements of users with disabilities. Additional services include alternative renderings (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).
2. Relies on services (such as retrieving Web content and parsing markup) provided by one or more other "host" user agents. Assistive technologies communicate data and messages with host user agents by using and monitoring APIs, especially Accessibility APIs.

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

• Screen magnifiers, which are used by people with visual disabilities to enlarge and change colors on the screen to improve the visual readability of rendered text and images;
• Screen readers, which are used by people who are blind or have reading disabilities to read textual information through synthesized speech or braille displays;
• 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;
• Alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

Note: This definition is based on the definition in Web Content Accessibility Guidelines 2.0 [WCAG20, Appendix A].

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

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 Adaptable Applications//EN"
 "http://www.w3.org/2005/07/aaa/xhtml11-aaa.dtd">

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

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Adaptable 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="checkboxtristate " role="checkboxtristate" id=" chbox1" aaa:required="true" aaa:readonly="true " aaa:random="sometext " 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-aaa-base.dtd" [

<!ENTITY % aaa.prefixed "INCLUDE">

<!ENTITY % aaa.prefix "state">

]>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For
    Accessible Adaptable Applications//EN"
    "http://www.w3.org/2005/07/aaa/xhtml11-aaa-base.dtd"> 
<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="checkboxtristate " role= "checkboxtristate"
        id="chbox1 " required="true" readonly="true " random="sometext "
        onkeydown="return checkBoxEvent(event);" onclick="return
        checkBoxEvent(event);">
      Sign me up for weekly rdf newsletter :)
    </div>
   </body>
</html>
				

 xmlns:aaa="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:aaa="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 aaa:expanded="true ">
<!-- this rectangle is zoomed -->

 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="checkboxtristate" 
    id="chbox1" 
    role="wairole:checkboxtristate" 
    aaa: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 Document Conformance

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 aaa 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:aaa=" http://www.w3.org/2005/07/aaa " >

3.2 Host Language Conformance

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.

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

4.1 Widget states

This section contains states specific to user common interface elements found on GUI systems or in a 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.

4.2 Live Regions

This section contains properties specific to live regions in your rich internet application. 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.

4.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 identify “draggable” objects and drop target. This information by rendered visually or provided to the user by an assistive technology through and alternative modality.

4.4 Focus

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

4.5 Relationships

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

4.6 Uncategorized states

This section defines miscellaneous accessibility properties in a rich internet application which do not fall under a specific category.

*{visibility: visible;}
*[waistate:hidden=true] {visibility: hidden;} 

5.1 Index of States and Properties

For reference purposes, here is an alphabetical list of states and properties defined in this specification.

5.2 DTD Implementation

This section is normative.

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

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

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

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

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

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

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

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

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

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

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

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

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

]]>

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

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

<!-- properties -->

<!ENTITY % aaa.activedescendent.qname "%aaa.pfx;activedescendent">
<!ENTITY % aaa.atomic.qname "%aaa.pfx;atomic">
<!ENTITY % aaa.controls.qname "%aaa.pfx;controls">
<!ENTITY % aaa.datatype.qname "%aaa.pfx;datatype">
<!ENTITY % aaa.describedby.qname "%aaa.pfx;describedby">
<!ENTITY % aaa.dropeffect.qname "%aaa.pfx;dropeffect">
<!ENTITY % aaa.flowto.qname "%aaa.pfx;flowto">
<!ENTITY % aaa.haspopup.qname "%aaa.pfx;haspopup">
<!ENTITY % aaa.labelledby.qname "%aaa.pfx;labelledby">
<!ENTITY % aaa.level.qname "%aaa.pfx;level">
<!ENTITY % aaa.live.qname "%aaa.pfx;live">
<!ENTITY % aaa.multiselectable.qname "%aaa.pfx;multiselectable">
<!ENTITY % aaa.owns.qname "%aaa.pfx;owns">
<!ENTITY % aaa.posinset.qname "%aaa.pfx;posinset">
<!ENTITY % aaa.readonly.qname "%aaa.pfx;readonly">
<!ENTITY % aaa.relevant.qname "%aaa.pfx;relevant">
<!ENTITY % aaa.required.qname "%aaa.pfx;required">
<!ENTITY % aaa.setsize.qname "%aaa.pfx;setsize">
<!ENTITY % aaa.sort.qname "%aaa.pfx;sort">
<!ENTITY % aaa.valuemax.qname "%aaa.pfx;valuemax">
<!ENTITY % aaa.valuemin.qname "%aaa.pfx;valuemin">
<!ENTITY % aaa.valuenow.qname "%aaa.pfx;valuenow">

<!-- tabindex -->

<!ENTITY % aaa.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 % aaa.states.qname "
	%aaa.busy.qname; ( true | false | error ) 'false'
	%aaa.checked.qname; (true | false | mixed) #IMPLIED
	%aaa.disabled.qname; (true | false) #IMPLIED
	%aaa.expanded.qname; (true | false | undefined) #IMPLIED
	%aaa.grab.qname; ( true | supported | false ) 'false'
	%aaa.hidden.qname; ( true | false ) 'false'
	%aaa.invalid.qname; (true | false) #IMPLIED
	%aaa.pressed.qname; (true | false ) #IMPLIED
	%aaa.selected.qname; (true | false | undefined) #IMPLIED
">

<!ENTITY % aaa.props.qname "
	%aaa.activedescendent.qname; IDREF #IMPLIED
	%aaa.atomic.qname; (true | false) 'false'
	%aaa.controls.qname; IDREFS #IMPLIED
	%aaa.datatype.qname; CDATA #IMPLIED
	%aaa.describedby.qname; IDREFS #IMPLIED
	%aaa.dropeffect.qname; ( copy  | move | reference | none ) 'none'
	%aaa.flowto.qname; IDREF #IMPLIED
	%aaa.haspopup.qname; ( true | false )  'false'
	%aaa.labelledby.qname; IDREFS #IMPLIED
	%aaa.level.qname; %Number.datatype; #IMPLIED
	%aaa.live.qname; (off | polite | assertive | rude) 'off'
	%aaa.multiselectable.qname; (true | false) #IMPLIED
	%aaa.owns.qname; IDREFS #IMPLIED
	%aaa.posinset.qname; %Number.datatype; #IMPLIED
	%aaa.readonly.qname; (true | false) #IMPLIED
	%aaa.relevant.qname; (additions | removals | text | all) #IMPLIED
	%aaa.required.qname; (true | false) #IMPLIED
	%aaa.setsize.qname; %Number.datatype; #IMPLIED
	%aaa.sort.qname; (ascending | descending) #IMPLIED
	%aaa.valuemax.qname; CDATA #IMPLIED
	%aaa.valuemin.qname; CDATA #IMPLIED
	%aaa.valuenow.qname; CDATA #IMPLIED
">

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

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

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

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

<!-- ELEMENTS  DTD XHTML 1.1 For Accessible Adaptable Applications -->
<!-- File: xhtml11-aaa-base.dtd

 Copyright (c) 2005, Unbounded Access,
 All Rights Reserved.

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

 PUBLIC "-//W3C//ELEMENTS DTD XHTML 1.1 For Accessible Adaptable Applications//EN"
 SYSTEM "http://www.w3.org/2005/07/aaa/xhtml11-aaa-base.dtd"
 xmlns:aaa="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 Adaptable Applications//EN"
        "http://www.w3.org/2005/07/aaa/xhtml11-aaa-base.dtd">

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

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

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

%aaa-qname.mod;

<!-- add AAA attribute set to all XHTML elements -->

<!ENTITY % Common.extra.attrib
    "%aaa.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;
    %aaa.extra.attrs.qname;
>

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

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

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

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

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

<!ENTITY % aaa.prefixed "INCLUDE">

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

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

<!-- File: xhtml11-aaa.dtd

 Copyright (c) 2005, Unbounded Access,
 All Rights Reserved.

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

 PUBLIC "-//W3C//DTD XHTML 1.1 For Accessible Adaptable Applications//EN"
 SYSTEM "http://www.w3.org/2005/07/aaa/xhtml11-aaa.dtd"
 xmlns:aaa="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 Adaptable Applications//EN"
        "http://www.w3.org/2005/07/aaa/xhtml11-aaa.dtd">


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

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

>

<!-- Enable prefixing -->

<!ENTITY % aaa.prefixed "INCLUDE">

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

%xhtml11-aaa.mod;

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

5.3 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.4 Mapping States and Properties to Accessibility APIs

This section is informative.

Mapped properties (Please note: This is a common subset of all mapping options)

(As yet) unmapped properties are:

• domactive
• valuemax
• valuemin
• step
• invalid
• describedby
• labelledby
• tabindex
• flowto
• controls
• subpageof

5.5 References

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

5.6 Acknowledgments (Non-Normative)

This section is informative.

The following contributed to the development of this document.