Foundations: introduction to WAI-ARIA

Posted on Friday, 10 February 2023 by Henny Swan

The Web Accessibility Initiative Accessible Rich Internet Applications specification 1.2, or WAI-ARIA or ARIA for short, is a technical specification written by the World Wide Web Consortium (W3C).

In this post we explore what WAI-ARIA is, and how it can enhance the user experience for people using screen readers.

What is ARIA

Developers use WAI-ARIA 1.2 to define roles, states, properties, and values for interactive elements to make content more accessible to people with disabilities browsing with a screen reader. A screen reader is a software application that announces what is on the screen to people who cannot see or understand visual content.

The WAI ARIA homepage — Accessible Rich Internet Applications 1.2, specification outlining roles, states, properties, and values.

Why ARIA is needed

ARIA complements HTML semantics by providing a set of attributes that allow you to enhance the native roles of HTML elements to build more accessible user experiences. A native role is a default role in HTML, also known as the implicit role.

HTML interface controls are generally accessible to screen readers; this includes buttons, links, checkboxes and so on. For example, a screen reader can detect an HTML button and announce “button”.

A submit button with the open Accessibility Inspector in Chrome — An HTML button with the Chrome Accessibility Inspector open displaying its accessibility properties including the HTML role

Many static HTML elements can be enhanced using JavaScript to include dynamic interactions which give the user the ability to, for example, select, drag, drop, open, and close content. These behaviours are not native to HTML, so screen readers cannot detect these changes.

For example, a screen reader can detect an HTML button but not understand whether it is expanded or collapsed for a menu.

ARIA attributes provide additional semantics for HTML elements so that a screen reader can detect these enhancements including an element’s role, name and current state:

An element's role describes its purpose, for example “button”
An elements name identifies an element, for example “Settings”
An element’s state is its current condition, for example “Expanded”

Support for ARIA

ARIA is supported by all commonly used browsers and screen readers:

Browsers: Firefox, Chrome, Safari, Edge
Assistive technologies: JAWS, NVDA, Narrator, Orca, VoiceOver and the screen reader built into ZoomText

Support may vary, but it is always improving. You can check support at A11y support.

When to use ARIA

Always use native HTML elements or attributes rather than ARIA where they are available. This is because screen readers already recognise them, and interactive HTML elements are generally keyboard accessible by default. Some people may also still have older browsers and screen readers that don’t fully support ARIA.

Tips

Always use semantic HTML over ARIA when it is available
Do not change native HTML semantics unless you really have to
Use WAI-ARIA Authoring Practices 1.1 as a reference for how to apply role, name, description, state and keyboard behaviour for accessible custom components

Summary

ARIA is a technical specification written by the World Wide Web Consortium (W3C)
ARIA is used by developers to build interactive website content that is accessible to people with disabilities who use screen readers
ARIA is supported by the most commonly used browsers and screen readers
ARIA complements HTML by providing a set of attributes that allow you to enhance the native roles of HTML elements to build more accessible user experiences
ARIA requires JavaScript to provide keyboard functionality to make elements focusable and define event handlers

Related WCAG 2.1 Success Criteria

Success Criterion 4.1.2 Name, Role, Value (Level A)

More information

Accessible Rich Internet Applications 1.2, W3C
ARIA Authoring Practices Guide (APG), W3C
Using ARIA, W3C
Testing WAI-ARIA Role Support, Steve Faulkner
An introduction to Accessible Rich Internet Applications, Patrick H Lauke

For more information about the Web Content Accessibility Guidelines, read our WCAG primer. You can offer self-led training courses in Accessible web development and Accessible web QA.