WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a W3C specification that defines a set of HTML attributes for making dynamic web content accessible to people who use assistive technologies. ARIA provides three categories of attributes:
- Roles: define what an element is (button, slider, dialog, region, alert).
- States: describe the current condition of an element (aria-pressed, aria-expanded, aria-checked).
- Properties: provide additional information about an element (aria-label, aria-describedby, aria-valuemin).
ARIA was created because native HTML lacks semantics for many common UI patterns: tab panels, tree views, drag-and-drop interfaces, live updating regions, and custom media players.
Why it matters
The first rule of ARIA is: if you can use a native HTML element that already has the semantics you need, use that instead. A <button> is always better than a <div role="button">. But when native HTML cannot express the widget’s purpose, ARIA is the only mechanism for making it accessible.
For TTS implementations, ARIA is critical. Custom audio players built with styled div elements are invisible to screen readers without ARIA. WCAG success criterion 4.1.2 (Name, Role, Value) specifically requires all interactive controls to expose their name, role, and state to assistive technologies. ARIA is how this requirement is met.
ARIA in audio players
A compliant TTS audio player requires the following ARIA attributes at minimum:
| Element | Required ARIA |
|---|---|
| Player container | role="region" with aria-label="Audio player for [title]" |
| Play/pause button | aria-label="Play" or aria-label="Pause", aria-pressed for toggle state |
| Volume slider | role="slider", aria-valuemin, aria-valuemax, aria-valuenow, aria-valuetext |
| Playback rate | aria-label="Playback speed", current value announced |
| Status changes | aria-live="polite" region announcing “Playing”, “Paused”, “Speed set to 1.5x” |
Common mistakes
- Using ARIA instead of semantic HTML:
<div role="button" onclick="...">instead of<button>. The native element provides keyboard support and focus management for free. - Missing aria-label on icon buttons: a play icon with no text and no aria-label is invisible to screen readers.
- Forgetting state updates: toggling a play/pause button without updating
aria-pressedmeans screen readers announce the wrong state. - Overusing aria-hidden: hiding elements with
aria-hidden="true"removes them from the accessibility tree entirely. Only use this for decorative elements.
See the EAA Voice Accessibility Guide for a complete audio player implementation checklist.
Frequently Asked Questions
What is ARIA?
ARIA stands for Accessible Rich Internet Applications. It is a W3C specification that adds HTML attributes to communicate the purpose and state of interactive elements to assistive technologies like screen readers.
When should you use ARIA?
Use ARIA when native HTML elements cannot convey the semantics of a custom widget. For example, a custom audio player built with div elements needs ARIA roles and labels to be accessible. The first rule of ARIA: do not use ARIA if a native HTML element can do the job.
What are ARIA roles?
ARIA roles define what an element is or does. Examples include role="button" for clickable elements, role="slider" for range controls, and role="region" for landmark areas. Roles help screen readers announce elements correctly.
What is aria-label used for?
aria-label provides an accessible name for an element when the visible text is insufficient or absent. For example, a play button icon with no visible text needs aria-label="Play article audio" so screen readers can announce its purpose.
How does ARIA relate to WCAG?
WCAG success criterion 4.1.2 (Name, Role, Value) requires all interactive elements to have accessible names, correct roles, and expose their current state. ARIA is the primary mechanism for meeting this requirement in custom widgets.