ARIA stands for Accessible Rich Internet Applications. It is a set of HTML attributes that tell assistive technology what something is, what state it is in, and how it relates to other things on the page.
It exists because HTML ran out of elements before the web ran out of interface ideas. There is no <tab-panel>, no <combobox>, no <carousel>. Teams build those from divs, and a div means nothing to a screen reader. ARIA is how you say "this div is actually a tab panel, and this tab is the selected one".
The Thing to Understand First
ARIA changes what gets announced. It changes nothing else.
It adds no keyboard behaviour. It adds no focus management. It does not make anything clickable, focusable or operable. The specification says so in as many words, that where an ARIA role overrides the host language's own semantics there is no change to the page at all, only to the accessibility tree. Put role="button" on a div and a screen reader announces "button", and pressing Enter still does nothing, because you promised a button and delivered a div.
That gap is why ARIA has a reputation for making things worse. A role is a promise of functionality you have implemented. It is a label on a box, and if the box is empty the label is a lie. A confident lie is more damaging than silence, because the person acting on it has no reason to doubt it.
The first rule of ARIA
Do not use ARIA. That is the actual first rule of the four, phrased more politely. If a native HTML element or attribute already provides the semantics and behaviour you need, use it instead. A <button> gives you role, focusability, keyboard activation and state for free. A div with three ARIA attributes gives you one of those.
The Four Rules, in Plain Language
- Use native HTML if you can.
<button>,<nav>,<input type="checkbox">,<details>. They come with behaviour attached. - Do not change native semantics unless you really must. Putting
role="heading"on a button helps nobody. - Every interactive ARIA control must be keyboard operable. Build a slider from divs and you own the arrow-key handling.
- Do not put
role="presentation"oraria-hidden="true"on a focusable element. You create something a keyboard user can reach and a screen reader user cannot hear.
Two things about those four are worth knowing before you go looking for them. There were five once, and the document that carried them has been discontinued. W3C stopped work on it in February 2026, kept the four rules for reference, and pointed everyone at the ARIA Authoring Practices Guide instead. So if you find a page quoting five rules, including ours before this rewrite, it is quoting a version that no longer exists.
The fifth one was right, so keep it, as ours rather than as W3C's. Every interactive element needs an accessible name, because an icon button without one is announced as "button" and means nothing to the person hearing it. That requirement has not gone anywhere either. It lives in 4.1.2 Name, Role, Value, which is a Level A criterion.
One of the four has more force behind it than the plain wording suggests. ARIA itself puts a must-level duty on authors to manage focus for eight container roles, which are grid, listbox, menu, menubar, radiogroup, tree, treegrid and tablist. Claim one of those and the keyboard behaviour is a requirement of the specification, not an inference somebody drew from WCAG.
The Attributes Actually Worth Knowing
| Attribute | What it does | Watch out for |
|---|---|---|
| aria-label | Gives an element a name when there is no visible text | It overrides visible text, so match a visible label if there is one |
| aria-labelledby | Names an element using other text already on the page | Prefer this over aria-label when visible text exists |
| aria-describedby | Attaches extra explanation, like a hint or an error | Announced after the name, so keep it short |
| aria-expanded | Says whether a disclosure is open or closed | You have to update it in JavaScript, since it does not move on its own |
| aria-current | Marks the current page or step in a set | Use "page" for navigation, "step" for a wizard |
| aria-live | Announces content that changes without a page load | Overuse makes a page unbearable, and "polite" is nearly always right |
| aria-hidden | Removes something from the accessibility tree | Never put it on anything focusable |
| role | Says what a custom element is | You then owe the keyboard behaviour that role implies |
The Failures We Find Most
aria-labelon a plain div or span. The name never appears, and the reason is exact rather than mysterious. An author-supplied label only works on an element whose role permits naming, and a bare div has the generic role, which does not. Put the role on first and the name second, or the attribute does nothing at all.- A visible label and an
aria-labelthat disagree. Voice-control users say what they see, and the control does not respond. That is 2.5.3 Label in Name. aria-hidden="true"on a wrapper containing links. Reachable by keyboard, invisible to a screen reader, which is the exact thing the fourth rule exists to stop.role="button"with notabindexand no key handler. Announced as a button, behaves as nothing.- Stale
aria-expanded. The menu opens, the attribute still says false, and the screen reader reports the opposite of what is on screen. A state that is right on load and wrong afterwards is worse than no state at all. - Live regions on everything. A page announcing every hover and scroll is unusable, and that is audit experience rather than a measured figure.
role="presentation"on real content, which strips meaning from things that needed it.
We have fix guides for all of these, including labelling with aria-label, exposing widget state, and the failure case role=presentation on real content.
When ARIA Is Genuinely the Right Answer
None of the above means avoid it. There are jobs only ARIA does:
- Announcing dynamic changes. A cart total updating, a search result count, a save confirmation. That is
aria-live, and it is 4.1.3 Status Messages. - Naming icon-only controls. No visible text means no name without it.
- Composite widgets HTML does not have. Tabs, comboboxes, tree views, and grids. The ARIA Authoring Practices Guide gives you the expected markup and keyboard behaviour for each.
- Relationships across the page, like connecting an error message to the field it belongs to.
- Landmark regions where native elements do not fit the structure.
Read APG's own warning first
The Authoring Practices Guide is the right reference and it is not a code library. Every example page states that the code is not intended for production environments, and its Read Me First page says the patterns deliberately do not work around gaps in browser and screen reader support for ARIA 1.2. W3C's own conclusion is that testing assistive technology interoperability is essential before using any of it in production. If W3C says that about its own reference implementations, it is true of every component library you were about to install.
Five Common Components APG Has No Pattern For
Before you go looking, know what is not in there. The Authoring Practices Guide publishes 30 patterns, and there is no pattern for pagination, drag and drop, site search, toast notifications or date pickers. If you have ever spent an afternoon certain you were searching badly, you were not. The pattern does not exist.
Each absence has its own shape, and the shape is more useful than the gap.
- Pagination. No pattern and no example. Search the WCAG techniques instead and you land on one about EPUB page navigation, which introduces roles built for books rather than for a page of search results.
- Drag and drop. No pattern and no example.
- Site search. No pattern. APG covers the search landmark, which names the region and says nothing whatever about the widget sitting inside it.
- Toast notifications. No pattern. The Alert pattern is the nearest thing and it is a different animal, because an alert is a live region rather than a stack of dismissible messages on a timer. APG's own Alert pattern points at the criteria for content that disappears by itself, and both of those are Level AAA, so the standard's answer to a self-dismissing toast sits above the level most owners are held to.
- Date pickers. No pattern. There is a date picker dialog example filed under the Dialog pattern, and an example is not a pattern. That example is also dated February 2020.
The useful move when you hit one of these is to write it into the ticket. There is no canonical W3C pattern for this component, so the keyboard model is a decision somebody on your team is making rather than one they are copying. That single sentence turns an invisible risk into a named one. It is also why our guides on accessible pagination, drag and drop, site search, date pickers and notifications and toasts cite no pattern for their subject. There is not one to cite.
It runs the other way once, and it is worth knowing. Infinite scroll does have a pattern. It is called Feed, which is not a word anybody searches for, and it is described as a section of a page that automatically loads new content as the user scrolls. So the one component teams assume has no guidance is the one that does.
Why a Clean ARIA Report Proves Less Than It Looks Like
Automated tools check whether your ARIA is valid. Real roles, permitted attributes, allowed values. They cannot check whether it is true, and there is a number that makes the size of that gap concrete rather than rhetorical.
Name, Role, Value carries fifteen automated test rules, more than any other criterion in the standard, and ten of them name it as the thing they test. Seven of those ten ask whether a control has an accessible name, and every one of the seven passes on any string that is not empty. Not one of them reads the name and asks whether it describes the control. A button whose accessible name is the literal word button passes the entire set.
So aria-label="Close" on a button that submits an order is valid ARIA, a clean automated result, and a serious bug that will cost somebody money. Widen the lens and it is the same story across the standard, because 49 of the 86 criteria in WCAG 2.2 have no automated rule written against them at all.
None of that is a complaint about the rules, which are precise about what they test and honest about what they do not. It is the reason a clean scan and a working page are two different claims, and the reason our audit puts a screen reader user on the page rather than trusting a validator.
One honest limit
This page tells you what ARIA does and what to avoid. It cannot tell you whether the ARIA on your site is announcing the truth, because that needs somebody listening to it on the browser and screen reader combination your customers actually use. That is the human pass, and it is the half of testing no tool has yet replaced.