Introduction to ARIA Attributes
Learn when and how to use ARIA roles, labels, and live regions to enhance accessibility beyond native HTML.
What is ARIA and why does it exist?
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 <button> is always better than <div role="button">. A <select> 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 <button> element gives you all of that for free.
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.
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 <button> is almost always the better choice.