Accessibility specialists

Foundations: introduction to WAI-ARIA

Posted on by Henny Swan in Design and development

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
  • Success Criterion 4.1.2 Name, Role, Value (Level A)

More information

Next steps

Read more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.

Henny Swan

Henny is a Director. She specialises in embedded and sustainable accessibility, inclusive user experience and design.

Having started her career focusing on the usability of dual language web platforms in China in the late 1990's, Henny moved into accessibility on her return to the UK in the early 2000s. Since then she has worked for the RNIB, Opera Software, TPGi and the BBC. It was at BBC she developed her passion for inclusive TV and streaming experiences.

Henny is co-author of the Inclusive Design Principles, was lead author of the BBC Mobile Accessibility Guidelines, and is a regular speaker at conferences. In 2022 Henny graduated the Goldman Sachs 10,000 Small Businesses.

Henny Swan
Photograph of Henny, whose bedhead hair clearly didn't get the 'dress code' memo, wearing a big smile, black glasses and a swan necklace

We like to listen

Wherever you are in your accessibility journey, get in touch if you have a project or idea.