Foundations: introduction to WAI-ARIA
Posted on 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.
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”.
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.
- 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
- 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
Related WCAG 2.1 Success Criteria
- Success Criterion 4.1.2 Name, Role, Value (Level A)
- 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.
We like to listen. If you have a project, product, problem, or idea that you want to discuss, get in touch!