UX glossary · engl. ARIA
ARIA
ARIA is a W3C standard that adds roles, states and properties to HTML. It tells screen readers what an element is and how it currently behaves.
Imagine a team builds a custom dropdown menu for a website out of plain div elements. With a mouse, everything works. A screen reader, however, only announces “Products,” without saying that it’s a button or whether the menu is open. With a keyboard, it can’t be opened at all.
ARIA exists to close gaps like this. It’s also where a lot of mistakes happen.
Explained simply
ARIA stands for “Accessible Rich Internet Applications,” officially WAI-ARIA. It’s a standard from the W3C, the organization that develops web standards. ARIA adds extra attributes to HTML that tell assistive technologies such as a screen reader what an element is and what state it’s in. The current recommendation is WAI-ARIA 1.2 from 2023.
Think of ARIA as a label on a box. The label says “tools,” but it doesn’t put any tools inside. If the label promises something that isn’t there, everyone relying on it ends up frustrated.
Roles, states and properties
ARIA works with three building blocks:
- Roles say what an element is, such as
role="dialog"orrole="tab". - States describe what can change, such as
aria-expanded="true"for an open menu. - Properties provide extra information, such as
aria-labelfor a name when there’s no visible text.
Keep in mind: ARIA only changes what assistive technology announces. It doesn’t add behavior or keyboard support. If you give a div the role “button,” you have to build focus and keyboard handling yourself.
The first rule of ARIA
That leads to the often quoted first rule: if a native HTML element with the meaning and behavior you need exists, use it instead of repurposing another element with ARIA. The W3C’s ARIA Authoring Practices Guide sums this up, in essence, as: no ARIA is better than bad ARIA. In 2026, the “WebAIM Million” analysis found that home pages with ARIA had more detected errors on average than pages without it, although that doesn’t prove ARIA caused them.
An example
Here’s an example: the dropdown from the introduction first gets nothing more than role="button". The screen reader now says “button,” but Enter and Space do nothing.
The better fix: the team replaces the div with a real button element and only adds aria-expanded, which switches to “true” when the menu opens. Focus and keyboard support work automatically, and the state is announced correctly.
In practice
- Start with native HTML. Buttons, links, form fields and headings already come with meaning and keyboard accessibility.
- Keep your promises. Every role you assign requires matching behavior. Without keyboard support, it’s a false announcement.
- Test with real tools. Tools like axe DevTools catch invalid attributes, and a quick screen reader test shows how it actually sounds. More methods are covered in Accessibility Testing: Tools and Methods for UX Designers.
Related terms
Screen Reader, Accessibility, WCAG, Alt Text