ARIA States 101

See Also: ARIA Roles 101

As part of the Web Accessibility Initiative (WAI), the Accessible Rich Internet Applications Suite (ARIA), defines a way to make Web content and Web applications more accessible. It is used to improve the accessibility of dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

ARIA specifies the following:

• Roles to describe the type of widget presented, such as “menu,” “treeitem,” “slider,” and “progressmeter”
• Roles to describe the structure of the Web page, such as headings, regions, and tables (grids)
• Properties to describe the state widgets are in, such as “checked” for a check box, or “haspopup” for a menu.
• Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page
• Properties for drag-and-drop that describe drag sources and drop targets
• A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

This article will focus on the third item in the list relating to states. ARIA states work now in many browsers and screen readers. When they don’t, they are harmless. The use of ARIA states goes beyond basic HTML role definitions and moves into widget and web app development. Perhaps for this reason, clear information about states is less available.

The W3C definition of state.

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

The W3C further defines how states (and properties) are related to ARIA roles, and how states and properties differ.

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

Global States

Some states are considered global, meaning they can be applied to any element regardless of whether a role is applied to the element. These states are listed, with links going to the W3C for further information on each state.

• aria-busy
• aria-disabled
• aria-grabbed
• aria-hidden
• aria-invalid
  

Widget States

Attributes of widgets that require user interaction that express state are the following:

• aria-checked
• aria-disabled
• aria-expanded
• aria-hidden
• aria-invalid
• aria-pressed
• aria-selected

Code Examples

It is hard at this point in ARIA use/adoption to find examples of ARIA states in use. If you can point me to examples, I’d like to see them. Few people outside the W3C are trying to explain ARIA states in educational articles like this one and the examples are limited. The topic needs are great deal more explaining, in my opinion.

ARIA states can be used with forms. In this example, aria-required="true" adds information about the state the object is in.  The value “true” is an example of numerous values that can be applied to ARIA states such as “number” or “string”.

<label for="firstName">First name:</label>
<input id="firstName" type="text" aria-required="true">

Here’s another:

<li role="menuitemcheckbox" aria-checked="true">Item text</li>

Resources

• WAI-ARIA
• Using WAI-ARIA