Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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).
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.
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.
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.
This section is informative.
The design aims of creating this specification include:
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.
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.
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')}
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:
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
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.
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.
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.
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.
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.
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]
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.
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:
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.
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 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>
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.
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.
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.
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: 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. |
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.
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:
|
One of the following values:
|
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) |
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.
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).
Roles are categorized as follows:
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.
Role | Definition |
---|---|
alert | A message with an alert or error information. |
alertdialog | A separate window with an alert or error information. |
application | A software unit executing a set of tasks for its users. |
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. |
button | Allows for user-triggered actions. |
checkbox | A control that has three possible values, (true, false, mixed). |
columnheader | A table cell containing header information for a column. |
combobox | Combobox is a presentation of a select, where users can type to locate a selected item. |
contentinfo | This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here. |
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. Todo: not sure this is clear |
description | Descriptive content for a page element which references this element via describedby. |
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. |
directory | A list of references to members of a single group. |
document | Content that contains related information, such as a book. |
grid | A grid contains cells of tabular data arranged in rows and columns (e.g., a table). |
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. |
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. |
heading | A heading for a section of the page. |
img | An img is a container for a collection elements that form an image. |
link | Interactive reference to a resource (note, that in XHTML 2.0 any element can have an href attribute and thus be a link) |
list | Group of non-interactive list items. Lists contain children whose role is listitem. |
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. |
listitem | A single item in a list. |
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. |
main | This defines the main content of a document. |
marquee | A marquee is used to scroll text across the page. |
menu | Offers a list of choices to the user. |
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. |
menuitem | A link in a menu. This is an option in a group of choices contained in a menu. |
menuitemcheckbox | Defines a menuitem which is checkable (tri-state). |
menuitemradio | Indicates a menu item which is part of a group of menuitemradio roles. |
navigation | This is a collection of links suitable for use when navigating the document or related documents. |
note | The content is parenthetic or ancillary to the main content of the resource. |
option | A selectable item in a list represented by a select. |
presentation | An element whose role is presentational does not need to be mapped to the accessibility API. |
progressbar | Used by applications for tasks that take a long time to execute, to show the execution progress. |
radio | A radio is an option in single-select list. Only one radio control in a radiogroup can be selected at the same time. |
radiogroup | A group of radio controls. |
region | Region is a large perceivable section on the web page. |
row | A row of table cells. |
rowheader | A table cell containing header information for a row. |
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. |
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. |
seealso | Indicates that the element contains content that is related to the main content of the page. |
separator | A line or bar that separates and distinguishes sections of content. |
slider | A user input where the user selects an input in a given range. This form of range expects an analog keyboard interface. |
spinbutton | A form of Range that expects a user selecting from discrete choices. |
status | This is a container for process advisory information to give feedback to the user. |
tab | A header for a tabpanel. |
tablist | A list of tabs, which are references to tabpanels. |
tabpanel | Tabpanel is a container for the resources associated with a tab. |
textbox | Inputs that allow free-form text as their value. |
timer | A numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point. |
toolbar | A toolbar is a collection of commonly used functions represented in compact visual form. |
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. |
tree | A form of a list having groups inside groups, where sub trees can be collapsed and expanded. |
treegrid | A grid whose rows can be expanded and collapsed in the same manner as for a tree. |
treeitem | An option item of a tree. This is an element within a tree that may be expanded or collapsed |
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:
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.
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: |
widget
A component of a GUI (graphical user interface).
Widget Roles all map to accessibility APIs. Widgets are ... , see @@
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: |
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.
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: |
composite
A widget that may contain navigable descendants.
Descendants of this role may not have the "nameFrom" value of "subtree" set.
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: |
window
Browser or application window
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: |
Roles in this section include:
input
Generic type for widgets that can have a value.
Is Abstract: | True |
---|---|
Parent Role: | widget |
Child Roles: | |
Base Concept: | |
Related Concepts: | XForms input |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: | author |
Accessible Name Required: | |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
select
A form control that allows the user to make selections from a set of choices. A select must contain an option.
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: |
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.
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: |
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.
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: |
option
A selectable item in a list represented by a select.
An option must appear inside an element with select role.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
Is Abstract: | |
---|---|
Parent Role: | option |
Child Roles: | |
Base Concept: | |
Related Concepts: | HTML input (type : checkbox) |
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: |
radio
A radio is an option in single-select list. Only one radio control in a radiogroup can be selected at the same time.
Is Abstract: | |
---|---|
Parent Role: | checkbox |
Child Roles: | |
Base Concept: | |
Related Concepts: | HTML input (type : radio) |
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: |
radiogroup
A group of radio controls.
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: |
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.
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: |
range
Represents a range of values that can be set by the user.
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: |
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.
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: |
Roles in this section include:
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.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | True |
Inherits Presentational: |
link
Interactive reference to a resource (note, that in XHTML 2.0 any element can have an href attribute and thus be a link)
Is Abstract: | |
---|---|
Parent Role: | widget |
Child Roles: | |
Base Concept: | |
Related Concepts: | HTML link |
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: |
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.
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | group |
Child Roles: | |
Base Concept: | |
Related Concepts: | toolbar |
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | group |
Child Roles: | |
Base Concept: | |
Related Concepts: | menubar |
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | |
Child Roles: | |
Base Concept: | |
Related Concepts: | JAPI MENU_ITEM |
Parent Element: | menu |
Required Child Elements: | |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
menuitemcheckbox
Defines a menuitem which is checkable (tri-state).
The checked state indicates whether the menu item is checked, unchecked, or mixed.
Is Abstract: | |
---|---|
Parent Role: | |
Child Roles: | |
Base Concept: | |
Related Concepts: | menuitem |
Parent Element: | menu |
Required Child Elements: | |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
Is Abstract: | |
---|---|
Parent Role: | |
Child Roles: | |
Base Concept: | |
Related Concepts: | menuitem |
Parent Element: | menu |
Required Child Elements: | |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
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: |
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.
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: |
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.
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: |
tablist
Is Abstract: | |
---|---|
Parent Role: | directory |
Child Roles: | |
Base Concept: | |
Related Concepts: | DAISY Guide |
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: |
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.
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: |
|
Accessible Name Required: | |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
tree
A form of a list having groups inside groups, where sub trees can be collapsed and expanded.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
treeitem
An option item of a tree. This is an element within a tree that may be expanded or collapsed
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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:
section
A base abstract class representing a renderable structural containment unit found in a document or application.
Is Abstract: | True |
---|---|
Parent Role: | structure |
Child Roles: | |
Base Concept: | |
Related Concepts: | |
Supported States and Properties: | templateid |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
sectionhead
The section head labels or summarizes the topic of its related section
Is Abstract: | True |
---|---|
Parent Role: | structure |
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: |
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:
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: |
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.
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: |
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.
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: |
list
Group of non-interactive list items. Lists contain children whose role is listitem.
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: |
listitem
A single item in a list.
Is Abstract: | |
---|---|
Parent Role: | section |
Child Roles: | |
Base Concept: | HTML li |
Related Concepts: | XForms item |
Parent Element: | list |
Required Child Elements: | |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
Is Abstract: | |
---|---|
Parent Role: | section |
Child Roles: | |
Base Concept: | |
Related Concepts: | HTML fieldset |
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: |
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.
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: |
row
A row of table cells.
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: |
|
Accessible Name Required: | |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
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: |
|
Accessible Name Required: | True |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
treegrid
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: |
description
Descriptive content for a page element which references this element via describedby.
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | list |
Child Roles: | |
Base Concept: | |
Related Concepts: | DAISY Guide |
Parent Element: | |
Required Child Elements: | link |
Supported States and Properties: | |
Inherited States and Properties: | |
Name From: |
|
Accessible Name Required: | |
Inherits Name Required: | |
Children Presentational: | |
Inherits Presentational: |
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.
Is Abstract: | |
---|---|
Parent Role: | section |
Child Roles: | |
Base Concept: | |
Related Concepts: | DTB imggroup |
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: |
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:
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.
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | structure |
Child Roles: | |
Base Concept: | |
Related Concepts: | HTML hr |
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: |
Roles in this section include:
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:
Any group element in SVG may omit the labelledby attribute if it contains a non-empty title element.
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: |
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.
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | status |
Child Roles: | |
Base Concept: | |
Related Concepts: | XForms alert |
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: |
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.
Is Abstract: | |
---|---|
Parent Role: | |
Child Roles: | |
Base Concept: | |
Related Concepts: | XForms alert |
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: |
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.
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: |
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.
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: |
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.
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: |
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.
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: |
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.
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: |
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:
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.
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: |
contentinfo
This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.
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: |
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.
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: |
main
This defines the main content of a document.
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: |
navigation
This is a collection of links suitable for use when navigating the document or related documents.
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: |
note
The content is parenthetic or ancillary to the main content of the resource.
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: |
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.
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: |
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.
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: |
seealso
Indicates that the element contains content that is related to the main content of the page.
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: |
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.
This section is normative.
The States and Properties Module supports the following characteristics:
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.
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. |
This section is normative.
States and properties are categorized as follows:
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.
State | Definition |
---|---|
busy | Indicates 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. |
disabled | Indicates that the widget is present, but the value cannot be set and it cannot be internally navigated. |
expanded | Indicates whether an expandable/collapsible group of elements is currently expanded or collapsed. |
grab | This property is set to show an object's state in drag and drop. |
hidden | Defines whether or not the object is visible to the user. |
invalid | Indicates that the element's value is currently invalid, which discourages the form from being submitted. |
pressed | Used for buttons that are toggleable to indicate their current pressed state. |
selected | Sets whether the user has selected an item or not. |
State | Definition |
---|---|
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. |
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. |
autocomplete | Indicates whether user input completion suggestions are provided. |
channel | This property specifies which channel should be used to present the updates for its associated live region. |
controls | Defines the elements that are controlled by the current element. |
datatype | Datatype defines the format type of an element. |
describedby | Points to an element which describes the object. |
dropeffect | This property is set for the target of a drag and drop operation to show the effect when the dragged object is released. |
flowto | Establishes the recommended reading order of content, overriding the general default to read in document order. |
haspopup | Indicates that element may launch a pop-up window such as a context menu or submenu. |
labelledby | Points to the element which labels the current element. |
level | Level is the hierarchical level of an element within a structure. |
live | Describes the types of updates the user agent, assistive technology, and user can expect from an alert or live region of Web content. |
multiline | Indicates whether a text box accepts only a single line, or if it can accept multiline input. |
multiselectable | Indicates that the user may select more than one item from the current list. |
owns | Defines an object as a parent of another document element, when the child does not appear directly in the subtree of the owner. |
posinset | Indicates an item's number or position within the current level of a tree or list. |
readonly | Indicates that the widget is not editable. |
relevant | Indicates the relevant areas of change within a live region. |
required | Indicates that user input is required on the control before a form may be submitted. |
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. |
setsize | The setsize property refers to the number of items in the current level of a list or tree. |
sort | The sort property is used to indicate if items in a table or grid are sorted in ascending or descending order. |
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. |
templateid | The templateid is a unique identifier, represented as a URI, for which an assistive technology may customize its user interface. |
valuemax | Maximum allowed value for a range type of widget. |
valuemin | Minimum allowed value for a range type of widget. |
valuenow | The current value of a widget. |
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:
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.
Related Concepts: | XForms selection attribute in select |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | NMTOKEN |
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 |
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.
Related Concepts: | |
---|---|
Used in Roles: | option |
Inherits into Roles: | |
Value: | NMTOKEN |
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. |
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.
Related Concepts: | |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | string |
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.).
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | boolean |
true: | todo | |
---|---|---|
false: | (default) | todo |
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.
Related Concepts: | Tapered prompts in voice browsing. Switch in SMIL [SMIL]. |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | NMTOKEN |
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) |
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.
Related Concepts: |
|
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | boolean |
true: | indicates it has a popup menu, either as a descendant or pointed to by owns | |
---|---|---|
false: | (default) | has no popup |
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.
Related Concepts: | XForms [XForms] 'invalid' event http://www.w3.org/TR/2006/REC-xforms-20060314/slice4.html#evt-revalidate. Note: This state is true if a form field is required but empty. However, XForms's valid property would be set to false. |
---|---|
Used in Roles: | input |
Inherits into Roles: | |
Value: | boolean |
true: | Todo: | |
---|---|---|
false: | (default) | Todo |
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.
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | integer |
multiline
Indicates whether a text box accepts only a single line, or if it can accept multiline input.
Related Concepts: | |
---|---|
Used in Roles: | textbox |
Inherits into Roles: | |
Value: | boolean |
true: | this is a multiline text box | |
---|---|---|
false: | (default) | this is a single-line text box |
multiselectable
Indicates that the user may select more than one item from the current list.
Examples include: lists, trees, spreadsheets
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | boolean |
true: | todo | |
---|---|---|
false: | (default) | todo |
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.
Related Concepts: | |
---|---|
Used in Roles: | button |
Inherits into Roles: | |
Value: | NMTOKEN |
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. |
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:
Related Concepts: | XForms [XForms] Readonly |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | boolean |
true: | todo | |
---|---|---|
false: | (default) | todo |
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.
Related Concepts: | |
---|---|
Used in Roles: | input |
Inherits into Roles: | |
Value: | boolean |
true: | todo | |
---|---|---|
false: | (default) | todo |
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.
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | boolean |
true: | text input should be masked or not echoed. | |
---|---|---|
false: | (default) | no text input masking |
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.
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | NMTOKEN |
true: | a selectable element is actually selected. | |
---|---|---|
false: | the element is not selected. | |
undefined: | (default) | the element is not selectable. |
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.
Related Concepts: | XForms [XForms] range |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | decimal |
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.
Related Concepts: | XForms [XForms] range |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | decimal |
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.
Related Concepts: | XForms [XForms] range, start |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | decimal |
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:
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.
The AT may choose to combine several changes and present the entire changed region at once.
Related Concepts: | |
---|---|
Used in Roles: |
|
Inherits into Roles: |
|
Value: | boolean |
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 |
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.
Related Concepts: | |
---|---|
Used in Roles: |
|
Inherits into Roles: |
|
Value: | NMTOKEN |
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 |
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.
Related Concepts: | |
---|---|
Used in Roles: |
|
Inherits into Roles: |
|
Value: | NMTOKEN |
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 |
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:
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.
Related Concepts: | |
---|---|
Used in Roles: |
|
Inherits into Roles: |
|
Value: | NMTOKEN |
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. |
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.
Related Concepts: | |
---|---|
Used in Roles: |
|
Inherits into Roles: |
|
Value: | NMTOKENS |
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 |
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:
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.
Related Concepts: | |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | NMTOKENS |
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 |
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).
Related Concepts: | |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | NMTOKEN |
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. |
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:
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.
Related Concepts: | SVG [SVG] and DOM [DOM] active |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | IDREF |
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.Related Concepts: | SVG [SVG]: focus |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | integer |
This section defines relationships or associations between elements which cannot be readily determined from the document structure.
States and properties in this section include:
controls
Defines the elements that are controlled by the current element.
Related Concepts: | XML Events [XML events] object hyperlink target in HTML [HTML] |
---|---|
Used in Roles: | |
Inherits into Roles: |
|
Value: | IDREFS |
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. )
Related Concepts: | Related concepts: HTML label element, and HTML table cell headers are de facto describedby values. |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | IDREFS |
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.
Related Concepts: | XHTML 2 [XHTML2] :nextfocus :prevfocus |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | IDREFS |
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.
Related Concepts: | A related concept is label in XForms [XForms] and HTML [HTML]. |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | IDREFS |
owns
Defines an object as a parent of another document element, when the child does not appear directly in the subtree of the owner.
Related Concepts: | |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | IDREFS |
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.
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | integer |
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.
Related Concepts: | |
---|---|
Used in Roles: | listitem |
Inherits into Roles: | |
Value: | integer |
This section defines properties that are affect or describe user interface rendering.
States and properties in this section include:
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.
Related Concepts: | |
---|---|
Used in Roles: | All elements of the base markup |
Inherits into Roles: | |
Value: | boolean |
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. |
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.
Related Concepts: | |
---|---|
Used in Roles: | |
Inherits into Roles: | |
Value: | NMTOKEN |
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 |
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.
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.
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.
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:
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.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"
. 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>
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.
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.
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.
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 }
This section is normative.
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:
The document must conform to the constraints expressed in Appendix A - RDF Schema combined with the constraints expressed in its host language implementation.
The document must contain an xmlns
declaration for the
role Namespace [XML-NAMES]. The namespace name for the
roles defined here is
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.
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).
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" xmlns:aria="http://www.w3.org/2005/07/aaa" >
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:
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).
User agents MUST process values of the role attribute as follows:
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.
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.
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.
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.
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.
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.
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.
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.
<?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>
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 ................................................... -->
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 -->
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 -->
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.
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].
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:
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.
An assertion which can be a constraint.
An abstract type of object.
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.
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.
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].
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.
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.
A fact connecting two distinct, articulable things. Relationships may be of various types to indicate which object labels another, controls another, etc.
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.
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.
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.
A literal that concretizes the information expressed by a state or property.
This section is informative.
This section is informative.
The following contributed to the development of this document.
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.
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.