Accessible Rich Internet Applications (WAI-ARIA) 1.0

1.1. Scope

The goals of this specification include:

• defining what information may be controlled by the author;
• supporting device independence for new devices such as telephones, PDAs, and televisions;
• improving the accessibility of dynamic content generated by scripts; and
• providing for interoperability with assistive technology.

This draft currently handles two aspects of roles: user interface functionality and structural relationships. For more information, see the WAI-ARIA Primer [ARIA-PRIMER] for the use of roles in making interactive content accessible.

The role 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 technology.

The schema to support this standard has been designed to be extensible 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 [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. The WAI-ARIA User Agent Implementation Guide [ARIA-IMPLEMENTATION] describes how user agents should expose ARIA features to platform accessibility APIs. These documents are intended to help authors learn the practice of putting WAI-ARIA to use.

1.2. Use Cases

Keyboard accessible content helps users of alternate input devices. The new semantics, when combined with the recommended keyboard interactions provided in WAI-ARIA Best Practices [ARIA-PRACTICES], work will allow alternate input solutions to facilitate command and control via an alternate input solution.

ARIA introduces navigation landmarks through its taxonomy and the XHTML role landmarks, which helps persons with dexterity and vision impairments by providing for improved keyboard navigation. ARIA may also be used to assist persons with cognitive learning disabilities. The additional semantics allow authors to restructure and substitute alternative content as needed.

Assistive technology needs the ability to support alternative inputs by getting and setting the current value of widgets. Assistive technology also needs to determine what objects are selected and manage widgets that allow multiple selections, such as list boxes and grids.

ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that is equivalent to the ARIA feature, use the host language feature. ARIA should only be used in cases where the host language lacks the needed role, state, or property indicator. First use a host language feature that is as similar as possible to the ARIA feature, then refine the meaning by adding ARIA. For instance, a multi-selectable grid could be implemented as a table, and then ARIA used to clarify that it is a grid, not just a table. This allows for the best possible fallback for user agents that do not support ARIA and preserves the integrity of the host language semantics.

2.1. WAI-ARIA Roles

An ARIA role is set on an element using a role attribute, similar to the role attribute defined in the XHTML Role Attribute Module [XHTML-ROLES].

<li role="menuitem">Open file…</li>

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 [OWL] to document expected behaviors of each role. Features of the role taxonomy provide the following information for each role:

• an informative description of the role;
• hierarchical information about related roles (e.g., a directory is a type of list);
• context of the role (e.g., a listitem should be inside a list);
• references to related concepts in other specifications;
• use of OWL to provide a type hierarchy allowing for semantic inheritance (similar to a class hierarchy); and
• supported states and properties for each role (e.g., a checkbox supports being checked via the aria-checked attribute).

Attaching a role gives assistive technology information about how to handle each element.

2.2. WAI-ARIA States and Properties

ARIA provides a collection of accessibility states and properties which are used to support platform accessibility APIs on the various operating system platforms. 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, the 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 the assistive technology, which may alert the user that a change has occurred.

In the following example, a list item (html:li) has been used to create a checkable menu item, and JavaScript events will capture mouse and keyboard events to toggle value of aria-checked. A role is used to make the behavior of this simple widget known to the user agent. attributes that change with user actions (such as aria-checked) are defined in the states and properties section.

<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>

Some accessibility states, called managed states, are controlled by the user agent. Examples of managed state include keyboard focus and selection. Managed states often have corresponding CSS pseudo-classes (such as :focus and ::selection) to define style changes. In contrast, the states in this specification are typically controlled by the author and are called unmanaged states. Some states managed by the user agent, such as aria-posinset and aria-setsize, can be overridden by web application authors, but the author should only override them if the DOM is incomplete and would cause the user agent calculation to be incorrect. User agents map both managed and unmanaged states to the platform accessibility APIs.

Most modern user agents support CSS attribute selectors ([CSS], Section 5.8), and can allow the author to create UI changes based on ARIA attribute information, reducing the amount of scripts necessary to achieve equivalent functionality. In the following example, a CSS selector is used to determine whether or not an image of a check mark is shown, based on the value of the aria-checked attribute.

[aria-checked="true"]:before { background-image: url(checked.gif); }

Note: At the time of this writing, this CSS example, while technically correct, will not redraw styles properly in some browsers if the attribute's value is changed dynamically. It may be necessary to toggle a class name, or otherwise to force the browser to redraw the styles properly.

2.3. Managing Focus

An application should always have an element with focus when in use, as applications require users to have a place to provide user input. The element with focus should not be destroyed, hidden, or scrolled off screen. All interactive elements should be focusable. There should be an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element. See User Agent Accessibility Guidelines, Guideline 9 ([UAAG], Guideline 9).

When using standard (X)HTML and basic WAI-ARIA widgets, application developers can simply manipulate the tab order or use a script to create keyboard shortcuts to elements in the document. Use of more complex widgets requires the author to manage focus within them.

WAI-ARIA includes a number of "managing container" widgets, also known as "composite" widgets. Typically, the container is responsible for tracking the last descendant which was active (the default is usually the first item in the container). When a previously focused container is refocused, the new active descendant should be the same element as the active descendant when the container was last focused. For example, if the second item of a tree group was the active descendant when the user tabbed out of the tree group, then the second item of the tree group remains the active descendant when the tree group gets focus again. The user may also activate the container by clicking on one of the descendants within it.

When something in the container has focus, the user may navigate through the container by pressing additional keys such as the arrow keys to move relative to the current item. Any additional press of the main navigation key (generally the Tab key) will move out of the container to the next widget.

For example, a grid may be used as a spreadsheet with thousands of gridcell elements, all of which may not be present in the document at one time. This requires their focus to be managed by the container using the aria-activedescendant attribute, on the managing container element, or by the container managing the tabindex of its child elements and setting focus on the appropriate child. For more information, see Providing Keyboard Focus in WAI-ARIA Best Practices ([ARIA-PRACTICES], section 3.2).

Containers that manage focus in this way are:

• combobox
• grid
• listbox
• menu
• menubar
• tree
• treegrid
• tablist
• toolbar

More information on managing focus can be found in the Using Tabindex to Manage Focus Among Widgets section of the WAI-ARIA Best Practices [ARIA-PRACTICES].

2.4. Building Accessible Applications with WAI-ARIA

This section provides a brief introduction to the process of making applications accessible using ARIA. The choice and usage of roles can be complex and context dependent. It is beyond the scope of this document to explain implementations for all the possible ARIA use cases. ARIA Best Practices [ARIA-PRACTICES] provides detailed guidance on ARIA implementation methodology as well as references to sample code.

First steps to making an application accessible:

1. Each element or widget has correct and complete semantics that fully describe its behavior (using element names or roles);
2. The relationships between elements and groups are defined;
3. States, properties, and container relationships are valid for each element's behavior and are accessible via the Document Object Model [DOM] and the platform accessibility API; and
4. Keyboard focus should be maintained for the duration of the user's interaction with the application.
5. All interactive components should be keyboard operable.

ARIA provides authors with the means to make the different elements in a web application semantically rich. User agents use the role semantics to understand how to handle each element. Roles convey additional 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 augment or override those of the host language) and present them to an assistive technology through the Document Object Model or the platform accessibility API. The user agent will create an accessible representation of each element in the web page, and will use the appropriate accessibility API to notify assistive technology of changes to the semantics of those elements.

The following steps are recommended as ARIA is applied to content:

1. Use native markup when possible.

   Use the semantic elements that are defined in the host markup language. For example, with HTML or 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 gridcell elements 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 augmented or overridden by the role behavior.

2. Apply the appropriate roles.

   Set roles to make sure elements behave predictably and correctly describe the behavior of each element within the application, unless element behaviors are fully described by the native markup language. Roles for interactive elements should support all the attributes that the element could use. Once a role attribute is set it should not be changed as this may confuse the end user. This does not preclude an element being removed which has the role attribute set, but only states and properties (aria-* attributes) should be changed for a given element.

3. Preserve semantic structure.

   Structural information is critical to providing context to persons with disabilities. Preserve DOM hierarchy within structural elements and widgets. Form logical groups within user interface widgets, such as treeitem elements 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 specified as a live region, through the use of the aria-live attribute. Facilitate keyboard navigation through the use of document landmarks; full keyboard access and document semantics help everyone, including vision-impaired users, dexterity-impaired users, and even users with cognitive or learning impairments.

4. Build relationships.

   Look for relationships between elements, and mark them using the most appropriate property or attribute. For example, if a page contains both a search form and search results region, mark each container as a region and set the aria-controls attribute of the search form to reference the search results. See relationships in WAI-ARIA.

   Some relationships are determined automatically from the host language, like label elements associated with input elements in HTML.

5. Set states and properties in response to events.

   Once the role for an element has been set, change states and properties as appropriate during the element's life cycle, usually in response to user input events. Only use attributes supported for the chosen role or element.

   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 aria-multiline attribute (a property) is not something that changes frequently, whereas the aria-checked attribute (a state) changes frequently in response to user input.

6. Support full, usable keyboard navigation.

   Usable keyboard navigation in a rich internet application is different from the tabbing paradigm in a static document. Rich internet applications behave more like desktop applications where the user tabs to significant widgets and uses the arrow keys to navigate within a complex widget, such as a menu or spreadsheet. The changes that ARIA introduces in keyboard navigation make this enhanced accessibility possible. Tabbing in the document should follow a logical navigation structure. Authors implementing arrow key navigation should, where possible, follow the design patterns in the WAI-ARIA Best Practices Guide [ARIA-PRACTICES]. When using these features, it is important as always to ensure keyboard navigation is logical.

7. Synchronize the visual interface with the accessible interface.

   This will allow the state of your UI to be perceivable to the user as well as the assistive technology. For example, the author should have an associated selector that responds to a required form element (using aria-required) or a selected gridcell (using aria-selected). Authors may choose to achieve visual synchronization of these interface elements by using a script or by the use CSS attribute selectors. Refer to the WAI-ARIA Best Practices [ARIA-PRACTICES] for techniques for proper UI synchronization with the accessible state of the document.

2.5. Example: Building a Tree Widget

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.

To make this feature accessible we need to:

• Inform assistive technology about the role of each element;
• Inform assistive technology about the relationships between tree items;
• Give a clear keyboard focus that will not confuse users with disabilities; and
• Expose the changing states (expanded and collapsed) of the the tree items.

Following the steps below:

1. Look at the native markup language

   Although standard list behavior is supported by the native ul and li elements in HTML, there is no element that natively supports list expansion and selection. Since there is not, we will need to use roles.

2. Finding the right roles

   Since there is no native tree element in HTML, we need to add roles from this taxonomy that support the additional states and properties needed. The roles that support tree behavior are:

   • tree: A tree is the main container element for our tree. It is a form of a select where sub-level groups of treeitems may be collapsed and expanded.
   • treeitem: A treeitem is an option item of a tree. This is an element within a tree; sub-level groups of treeitems may be expanded or collapsed.
   • group: A group encloses a set of sub-level treeitems.

3. Look for groups and build relationships

   Tree relationships can be made simply via the DOM and logical structure of the page. A tree element will be the main container encompassing all other elements in the tree. Each selectable item in the tree will be a treeitem.

   When a treeitem contains an embedded list of treeitems they will be all embedded in a group. A group should be contained inside the tree item that is the parent item.

   <h1 id="treelabel">ARIA Tree Example</h1>
   <ul role="tree" aria-labelledby="treelabel" aria-activedescendant="example_id" tabindex="0">
     <li role="treeitem" aria-expanded="true">Animals
       <ul role="group">
         <li role="treeitem">Birds</li>
         <li role="treeitem" aria-expanded="false">Cats
           <ul role="group">
             <li role="treeitem">Siamese</li>
             <li role="treeitem">Tabby</li>
           </ul>
         </li>
         <li role="treeitem" aria-expanded="true">Dogs
           <ul role="group">
             <li role="treeitem" aria-expanded="true">Small Breeds
               <ul role="group">
                 <li role="treeitem">Chihuahua</li>
                 <li role="treeitem" id="example_id">Italian Greyhound</li>
                 <li role="treeitem">Japanese Chin</li>
               </ul>
             </li>
             <li role="treeitem" aria-expanded="false">Medium Breeds
               <ul role="group">
                 <li role="treeitem">Beagle</li>
                 <li role="treeitem">Cocker Spaniel</li>
                 <li role="treeitem">Pit Bull</li>
               </ul>
             </li>
             <li role="treeitem" aria-expanded="false">Large Breeds
               <ul role="group">
                 <li role="treeitem">Afghan</li>
                 <li role="treeitem">Great Dane</li>
                 <li role="treeitem">Mastiff</li>
               </ul>
             </li>
           </ul>
         </li>
       </ul>
     </li>
     <li role="treeitem" aria-expanded="true">Minerals
       <ul role="group">
         <li role="treeitem">Zinc</li>
         <li role="treeitem" aria-expanded="false">Gold
           <ul role="group">
             <li role="treeitem">Yellow Gold</li>
             <li role="treeitem">White Gold</li>
           </ul>
         </li>
         <li role="treeitem">Silver</li>
       </ul>
     </li>
     <li role="treeitem" aria-expanded="true">Vegetables
       <ul role="group">
         <li role="treeitem">Carrot</li>
         <li role="treeitem">Tomato</li>
         <li role="treeitem">Lettuce</li>
       </ul>
     </li>
   </ul>

   The use of aria-expanded should mirror that which is visibly expanded on screen, so authors may wish to use CSS attribute selectors to toggle visibility or style of an item based on the value of an ARIA state or property. The following example would hide the sub-level groups of a collapsed tree node.

   [aria-expanded="false"] [role="group"] { display: none; }

   Note: At the time of this writing, this CSS example, while technically correct, will not redraw styles properly in some browsers if the attribute's value is changed dynamically. It may be necessary to toggle a class name, or otherwise to force the browser to redraw the styles properly.

   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. In the following example, the aria-owns attribute indicates that the div with id "external_listitem" should be considered a child of the ul element with the property, even though it is not a child in the DOM.

   <h3 id="header">Vegetables</h3>
   <ul role="list" aria-labelledby="header" aria-owns="external_listitem">
     <li role="listitem">Carrot</li>
     <li role="listitem">Tomato</li>
     <li role="listitem">Lettuce</li>
   </ul>
   …
   <div role="listitem" id="external_listitem">Asparagus</div>

   If the tree is not completely represented in the DOM at all times, don't use either the structured or aria-owns methods. Instead use aria-level, aria-posinset and aria-setsize.

4. Use states and properties in response to events

   Control the behavior of the element in response to user input events such as from the keyboard and the mouse. For example, a tree control will need to respond to click events on the expand/collapse triggers, and key events on the currently active descendant. Use device-independent events with supporting JavaScript to handle user interaction.

4.1. Relationships Between Concepts

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.

4.2. Characteristics of Roles

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.

4.3. Categorization of Roles

To support the current user scenario, this specification categorizes roles that define user interface widgets (sliders, tree controls, etc.) and those that define page structure (sections, navigation, etc.).

Class diagram of the relationships described in the role data model.

View larger version of class diagram

Roles are categorized as follows:

1. Base Types
2. User Input Widgets
3. User Interface Elements
4. Document Structure
5. Specialized Regions
6. Landmark Roles

4.4. Definition of Roles

Below is an alphabetical list of ARIA roles to be used by rich internet application authors.

Note: Abstract roles are used for the ontology. Authors SHOULD NOT use abstract roles in content.

alert

A message with important, and usually time-sensitive, information. Also see alertdialog and status.

alertdialog

A type of dialog that contains an alert message, where initial focus goes to the dialog or an element within it. Also see alert and dialog.

application

A region declared as a web application, as opposed to a web document.

article

A section of a page consisting of an independent part of a document, page, or site.

banner

A region that contains the primary heading or web site title.

button

An input that allows for user-triggered actions when clicked or pressed.

checkbox

An checkable input that has three possible values: true, false, or mixed.

columnheader

A cell containing header information for a column.

combobox

A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list.

complementary

A supporting section of the document that remains meaningful even when separated from the main content.

composite (abstract role)

A widget that may contain navigable descendants or owned children.

contentinfo

Metadata that applies to the parent document.

definition

A definition of a term or concept.

dialog

A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. Also see alertdialog.

directory

A list of references to members of a group, such as a static table of contents.

document

A region containing related information that is declared as document content, as opposed to a web application.

grid

A grid contains cells of tabular data arranged in rows and columns, like a table.

gridcell

A cell in a grid or treegrid.

group

A set of user interface objects which would not be included in a page summary or table of contents by an assistive technology.

heading

A heading for a section of the page.

img

A container for a collection of elements that form an image.

input (abstract role)

A generic type of widget that allows user input.

landmark (abstract role)

A region of the page intended as a navigational landmark.

link

An interactive reference to an internal or external resource.

list

A group of non-interactive list items.

listbox

A widget that allows the user to select one or more items from a list of choices.

listitem

A single item in a list, listbox, or directory.

log

A type of live region where new information is added in meaningful order and old information may disappear. Also see marquee.

main

The main content of a document.

marquee

A type of live region where non-essential information changes frequently. Also see log.

math

An element that represents a mathematical expression.

menu

A type of widget that offers a list of choices to the user.

menubar

A presentation of menu that usually remains visible and is usually presented horizontally.

menuitem

An option in a group of choices contained by a menu or menubar.

menuitemcheckbox

A checkable menuitem that has three possible values: true, false, or mixed.

menuitemradio

A checkable menuitem in a group of menuitemradio roles, only one of which can be checked at a time.

navigation

A collection of navigational elements (usually links) for navigating the document or related documents.

note

A section whose content is parenthetic or ancillary to the main content of the resource.

option

A selectable item in a select list.

presentation

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

progressbar

An element that displays the progress status for tasks that take a long time.

radio

A checkable input in a group of radio roles, only one of which can be checked at a time.

radiogroup

A group of radio buttons.

range (abstract role)

An input representing a range of values that can be set by the user.

region

A large perceivable section of a web page or document, that the author feels should be included in a summary of page features.

roletype (abstract role)

The base role from which all other roles in this taxonomy inherit.

row

A row of cells in a grid.

rowheader

A cell containing header information for a row in a grid.

search

The search tool of a web document.

section (abstract role)

A renderable structural containment unit in a document or application.

sectionhead (abstract role)

A structure that labels or summarizes the topic of its related section.

select (abstract role)

A form widget that allows the user to make selections from a set of choices.

separator

A divider that separates and distinguishes sections of content or groups of menuitems.

slider

A user input where the user selects a value from within a given range.

spinbutton

A form of range that expects a user to select from amongst discrete choices.

status

A container whose content is advisory information for the user but is not important enough to justify an alert. Also see alert.

structure (abstract role)

A document structural element.

tab

A header for a tabpanel.

tablist

A list of tab elements, which are references to tabpanel elements.

tabpanel

A container for the resources associated with a tab.

textbox

Input that allows 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 collection of commonly used function buttons represented in compact visual form.

tooltip

A contextual popup that displays a description for an element in a mouse hover or keyboard focused state. Supplement to the normal tooltip processing of the user agent.

tree

A type of list that may contain sub-level nested groups that 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 if it contains a sub-level group of treeitems.

widget (abstract role)

An interactive component of a graphical user interface (GUI).

window (abstract role)

A browser or application window.

<div role="img" aria-labelledby="caption">
  <img src="example.png" role="presentation" alt="">
  <p id="caption">A visible text caption labeling the image.</p>
</div>

<ul role="tree">
  <li role="presentation">
    <a role="treeitem" aria-expanded="true">An expanded tree node</a> 
  </li> 
  … 
</ul>

5.1. Clarification of States versus Properties

This section is informative.

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 both treated as aria-prefixed markup attributes. However, they are maintained conceptually distinct to clarify subtle differences in their meaning. One major difference is that the values of properties (such as aria-labelledby) are less likely to change throughout the application life-cycle than the values of states (such as aria-checked) which may change frequently due to user interaction. See the definitions of state and property for more information.

5.2. Characteristics of States and Properties

States and properties have the following characteristics:

5.3. Values for States and Properties

Many states and properties accept a specific set of tokens as values. The allowed values and explanation of their meaning is shown after the table of characteristics. The default value, if defined, is shown in strong type.

5.4. Global States and Properties

Some states and properties are applicable to all host language elements regardless of whether a role is applied. The following global states and properties are supported by all roles and by all base markup elements.

• aria-atomic
• aria-busy (state)
• aria-controls
• aria-describedby
• aria-disabled (state)
• aria-dropeffect (state)
• aria-flowto
• aria-grabbed (state)
• aria-haspopup
• aria-hidden (state)
• aria-invalid (state)
• aria-label
• aria-labelledby
• aria-live
• aria-owns
• aria-relevant
• aria-required

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.

5.5. Taxonomy of ARIA States and Properties

States and properties are categorized as follows:

1. Widget Attributes
2. Live Region Attributes
3. Drag-and-Drop Attributes
4. Relationship Attributes

5.6. Definitions of States and Properties (all aria-* attributes)

Below is an alphabetical list of ARIA states and properties to be used by rich internet application authors. A detailed definition of each ARIA state and property follows this compact list.

aria-activedescendant

Identifies the currently active descendant of a composite widget.

aria-atomic

Indicates if the assistive technology should present all or part of the changed region to the user when the region is updated. Also see aria-relevant.

aria-autocomplete

Indicates whether user input completion suggestions are provided.

aria-busy (state)

Indicates whether a live region is finished updating.

aria-checked (state)

Indicates the current "checked" state of checkboxes, radio buttons, and other widgets. Also see aria-pressed and aria-selected.

aria-controls

Identifies the element (or elements) whose contents or presence are controlled by the current element. Also see aria-owns.

aria-describedby

Identifies the element (or elements) that describes the object. Also see aria-labelledby.

aria-disabled (state)

Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. Also see aria-hidden and aria-readonly.

aria-dropeffect (state)

Indicates the effect of a drag-and-drop operation when the dragged object is released on the drop target.

aria-expanded (state)

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

aria-flowto

Identifies the next element (or elements) in the recommended reading order of content, overriding the general default to read in document source order.

aria-grabbed (state)

Indicates an element's "grabbed" state in a drag-and-drop operation.

aria-haspopup

Indicates that the element has a popup context menu or sub-level menu.

aria-hidden (state)

Indicates that the element is not visible or perceivable to the user. Also see aria-disabled.

aria-invalid (state)

Indicates the entered value does not conform to the format expected by the application.

aria-label

Defines a string value that labels the current element. Also see aria-labelledby.

aria-labelledby

Identifies the element (or elements) that labels the current element. Also see aria-label and aria-describedby.

aria-level

Defines the hierarchical level of an element within a structure.

aria-live

Indicates that an element will be updated, and describes the types of updates the user agent, assistive technology, and user can expect from the live region.

aria-multiline

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

aria-multiselectable

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

aria-owns

Identifies an element (or elements) in order to define a visual or functional, contextual parent/child relationship among DOM elements where the DOM hierarchy cannot be used to represent the relationship.

aria-posinset

Defines an element's number or position in the current set of listitems or treeitems. Not required if inferred by the DOM. Also see aria-setsize.

aria-pressed (state)

Indicates the current "pressed" state of toggle buttons. Also see aria-checked and aria-selected.

aria-readonly

Indicates that the element is not editable, but is otherwise operable. Also see aria-disabled.

aria-relevant

Indicates the nature of changes within a live region. Also see aria-atomic.

aria-required

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

aria-selected (state)

Indicates the current "selected" state of various widgets. Also see aria-checked and aria-pressed.

aria-setsize

Defines the number of items in the current set of listitems or treeitems. Not required if inferred by the DOM. Also see aria-posinset.

aria-sort

Indicates if items in a table or grid are sorted in ascending or descending order.

aria-valuemax

Defines the maximum allowed value for a range widget.

aria-valuemin

Defines the minimum allowed value for a range widget.

aria-valuenow

Defines the current value for a range widget. Also see aria-valuetext.

aria-valuetext

Defines the human readable text equivalent of aria-valuenow for a range widget.

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