Introduction to ARIA Attributes

ARIA stands for Accessible Rich Internet Applications. It is a set of HTML attributes that provide additional information to assistive technologies when native HTML elements alone are not enough. ARIA was created by the W3C to bridge the gap between the complex interactive interfaces of modern web applications and the relatively simple document structure that HTML was originally designed for.

Consider a custom dropdown menu built from divs and JavaScript. To a sighted user, it looks and behaves like a dropdown — they can click to open it, see the options, and select one. But to a screen reader, it is just a stack of divs. The screen reader has no idea that it is a dropdown, that it can be opened, what the current selection is, or how to interact with it. ARIA attributes fill in this missing information: they tell the screen reader "this is a listbox," "it is currently collapsed," "the selected option is Option 2," and "press Enter to open."

However — and this is critical — ARIA should be your last resort, not your first tool. The most important rule of ARIA is called the "First Rule of ARIA": if you can use a native HTML element that already has the semantics and behavior you need, use it instead of adding ARIA to a generic element. A is always better than

. A is always better than a custom ARIA listbox. Native elements come with built-in keyboard behavior, focus management, and screen reader support that ARIA cannot fully replicate.

Think of ARIA as a translation layer. Native HTML elements speak the accessibility language fluently — they come with built-in semantics, keyboard behavior, and screen reader support. ARIA is like subtitles — it can convey meaning, but it does not provide the actual behavior. Adding role="button" to a div makes a screen reader announce it as a button, but it does not make it focusable, keyboard-operable, or clickable. You still have to add tabindex, keydown handlers, and click events manually. A real element gives you all of that for free.

Think of it this way: Native HTML elements are like appliances that come with an instruction manual in every language — screen readers, keyboards, and browsers all know exactly how to use them. ARIA is like writing a sticky note in one specific language and taping it to a blank box. The sticky note helps, but the box still does not work like a real appliance. Always use the real appliance (native HTML) when one exists.

Web Standard

The First Rule of ARIA (from the W3C ARIA Authoring Practices): "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so." This is not just a suggestion — it is the official W3C recommendation.

Tip

ARIA never changes the visual appearance or behavior of an element — it only changes what assistive technologies announce. Adding role="button" to a div does not make it look like a button, respond to Enter/Space keypresses, or receive keyboard focus. You still need CSS for styling, tabindex for focus, and JavaScript for keyboard events. This is why native

is almost always the better choice.

Learn more on MDN

HTMLMDN: ARIAHTMLMDN: ARIA roles

HTMLREAD ONLY

PREVIEW