ARIA (Accessible Rich Internet Applications, formally WAI-ARIA) is a W3C specification that adds extra attributes to HTML so assistive technology can understand interactive elements. It tells a screen reader things like "this is a menu", "this panel is expanded" or "this icon button means Close", which the visual design alone does not convey.
How ARIA works: roles, states and properties
Browsers build an accessibility tree from your page, a simplified version that assistive tools read. ARIA lets you adjust what goes into it, without changing how the page looks or behaves:
- Roles say what an element is, for example
role="dialog",role="tablist"orrole="alert". - States describe its current condition, such as
aria-expanded="true",aria-checkedoraria-invalid. - Properties give names and relationships:
aria-label,aria-labelledby,aria-describedby,aria-controls. - Live regions (
aria-live="polite") ask the screen reader to announce content that changes, like "Added to cart".
ARIA only changes what is announced. It does not add keyboard support: a div with role="button" still will not respond to the Enter key unless you write that code.
The first rule of ARIA
The W3C's own guidance says: if a native HTML element already does what you need, use it instead of ARIA. A real button element is focusable, works with Enter and Space and is announced as a button automatically. ARIA is for gaps HTML does not cover, such as tabs, comboboxes and custom menus.
A concrete example: an icon-only button
A shop header has a cart button showing only a bag icon. A screen reader announces it as "button", with no clue what it does. Adding aria-label="Cart, 2 items" makes it announce "Cart, 2 items, button". A mobile menu toggle is another typical case: aria-expanded switches between false and true as the menu opens, so a blind user knows whether it is open.
Does your site need ARIA?
A simple site built with proper headings, links, buttons and labelled form fields needs very little. ARIA becomes necessary once you have custom interactive widgets: dropdown menus, accordions, modals, carousels or icon-only controls. Those are also where accessibility audits against WCAG most often find failures.
ARIA mistakes
- Using ARIA instead of HTML. Clickable divs with roles are more fragile than real buttons and links.
- Labels that contradict the visible text. Voice-control users say what they see, so the accessible name should include it.
- Hiding focusable content.
aria-hidden="true"on something a keyboard can still reach creates a silent trap. - Stale states. An
aria-expandedthat never updates tells users the opposite of the truth.
Related terms
- Screen reader: the main consumer of ARIA information.
- WCAG: the guidelines ARIA helps custom widgets meet.
- Alt text: the image equivalent of giving an element an accessible name.
- Web accessibility: the overall goal ARIA serves.