UX Design and Development course

Notes on ARIA use in HTML

Accessible Rich Internet Applications specification, which defines a way to make Web content and Web applications more accessible to people with disabilities.

The Roles Model

This section defines the WAI-ARIA role taxonomy and describes the characteristics and properties of all roles. A formal RDF/OWL representation of all the information presented here is available in Schemata Appendix.

The roles, their characteristics, the states and properties they support, and specification of how they may be used in markup, shall be considered normative. The RDF/OWL representation used to model the taxonomy shall be considered informative. The RDF/OWL taxonomy may be used as a vehicle to extend WAI-ARIA in the future or by tool manufacturers to validate states and properties applicable to roles per this specification.

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.). Note that some assistive technologies provide special modes of interaction for regions marked with role application or document.

I highly suggest reading more on the Categorization of Roles

First rule of ARIA use

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Under what circumstances may this not be possible?

  • If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
  • If the feature is not currently available in HTML.
  • If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.

Second rule of ARIA use

Do not change native semantics, unless you really have to.

For example: Developer wants to build a heading that's a button.

Do not do this:

<h1 role=button>heading button</h1>

Do this:

<h1><button>heading button</button></h1>

Or if you can't possibly use the correct element, do this:

<h1><span role=button>heading button</span></h1>

Note: if a non interactive element is used as the basis for an interactive element, developers have to add the semantics using ARIA and the appropriate interaction behavior using scripting. In the case of a button, for example, it is much better and easier to Just use a (native HTML) button.

Note: it is OK to use native HTML elements, that have similar semantics to ARIA roles used, for fall-back. For example, using HTML list elements for the skeleton of an ARIA enabled, scripted tree widget.

Third rule of ARIA use

All interactive ARIA controls must be usable with the keyboard.

If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.

All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.

For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.

Refer to the keyboard and structural navigation and design patterns sections of the WAI-ARIA 1.0 Authoring Practices.

What does adding a role do to the native semantics?

Adding an ARIA role overrides the native role semantics.

For example, this code in the HTML tree:

<h1 role=button>text</h1>

Becomes this in the accessibility tree:


What adding a role does not do?

Adding an ARIA role does not change the behaviours, states and properties:

For example, this code in the HTML tree:

<button role="heading" aria-level="1">text</button>

Becomes this in the accessibility tree:


But it can still be pressed, it is still in the default tab order, still looks like a button, still triggers any associated actions when pressed. That's why it is a HTML5 conformance error to change a button into a heading.

Note: likewise, changing the role of an element does not add behaviors, properties or states of the role used. You must add those yourself.

ARIA and Progressive Enhancement

by DEREK FEATHERSTONE November 30, 2010, A List Apart

ARIA is an emerging specification from the W3C and is an accessibility effort that a number of companies support. ARIA is designed to provide accessibility at a technical level—what you might call “programmatic accessibility”—where it doesn’t already exist. For example, many of the date pickers and other advanced widgets that we add to our websites are nothing more than a collection of <div> and <span> elements that have no semantic meaning; ARIA attempts to provide that semantic meaning.

ARIA and State

Accessible Rich Internet Applications (WAI-ARIA) 1.0

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 often 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. Note that the frequency of change difference is not a rule; a few properties, such as aria-activedescendant, aria-valuenow, and aria-valuetext are expected to change often. Because the distinction between states and properties is of little consequence to most web content authors, this specification refers to both "states" and "properties" simply as "attributes" whenever possible. See the definitions of state and property for more information.

aria-hidden (state)

If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true. When the element is presented, authors MUST set the aria-hidden attribute to false or remove the attribute, indicating that the element is visible. Some assistive technologies access WAI-ARIA information directly through the DOM and not through platform accessibility supported by the browser. Authors MUST set aria-hidden="true" on content that is not displayed, regardless of the mechanism used to hide it. This allows assistive technologies or user agents to properly skip hidden elements in the document.

It is recommended that authors key visibility of elements 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]). The following CSS declaration makes content visible unless the aria-hidden attribute is true; scripts need only update the value of this attribute to change visibility:

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

Testing ARIA

There is nothing special required to test ARIA in HTML5. As the spec evolves, this will be easily validated using standard HTML5 validators.