Posted on Friday, 10 February 2023 by Henny Swan in Design and development

Tags: Assistive Technology, Code, Foundations, WCAG

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.

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

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

• 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

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.