Short answer: ARIA is a set of roles and attributes from the W3C that tells assistive technologies what an element is and what state it’s in. Its first rule is to use a native HTML element when one does the job. Add ARIA only for what HTML can’t say, and keep its states true.
What ARIA is
WAI-ARIA, the Accessible Rich Internet Applications Suite, is a W3C standard. It defines a way to make web content and applications more accessible to people with disabilities, especially dynamic content and advanced controls built with HTML and JavaScript.
MDN describes ARIA as a set of roles and attributes that supplements HTML. It passes interactions and widgets to assistive technologies when HTML has no other way, such as JavaScript widgets, form hints, error messages and live updates.
ARIA changes what assistive technologies are told, not how an element works. MDN warns that if you use ARIA, you’re responsible for recreating in script the behavior the browser gives native elements.
What ARIA adds to a page
| Part | What it tells assistive technologies | Examples from the W3C |
|---|---|---|
| Widget roles | What kind of control an element is | menu, treeitem, slider, progressbar |
| Structure roles | How the page is organized | Headings and regions |
| States | The condition a control is in | checked for a check box, readonly for most form controls |
| Live regions | Parts of the page likely to update | Stock quotes |
From the W3C’s WAI-ARIA Overview, read November 5, 2026.
MDN adds that some roles need their states. An element with role="checkbox" must also carry aria-checked, and the switch role works like a checkbox whose states mean on and off.
Names are a separate topic; our aria-label guide covers how elements get theirs.
The rules of ARIA
The W3C’s Using ARIA is now a discontinued draft, but it keeps its four rules for reference. For patterns, the W3C points to its Authoring Practices Guide. The first: if a native HTML element or attribute already has the meaning and behavior you need, use it instead of adding ARIA. The second: don’t change native semantics unless you really have to.
The third: every interactive ARIA control must work with the keyboard. An element with role="button" must take focus and respond to Enter and to the space bar; our keyboard navigation guide covers how to test that.
The fourth: never put role="presentation" or aria-hidden="true" on an element that can take focus. Our aria-hidden guide covers that rule in detail.
When ARIA does more harm than good
A wrong role tells a screen reader user that an element is something it isn’t, and a stale state describes the control wrongly. MDN sums it up with a saying: “No ARIA is better than bad ARIA.”
WebAIM’s 2026 study of the top million home pages found ARIA on 82.7% of them, not counting landmark roles, up from 79.4% a year earlier. Pages with ARIA averaged 59.1 detected errors, against 42 on pages without it.
WebAIM adds that this doesn’t prove ARIA caused the errors, because those pages were also more complex. Still, the more ARIA a page had, the more errors it tended to have.
How to use ARIA on your site
- Start with the native element: button, a, input, select, nav or progress.
- Add a role only when no HTML element does the job.
- Give each custom control the states its role needs, such as aria-checked or aria-expanded.
- Update those states in script every time the control changes.
- Keep the label of a switch or toggle button the same in both states; if it has to change, use a plain button.
- Make every custom control work with Tab, Enter and the space bar.
- Check the result in the browser’s accessibility tree and with a screen reader; our screen reader guide shows how.
What our own pages use
On November 5, 2026, we read where our pages use ARIA, as a new visitor: the home page and our keyboard navigation guide, in English and Spanish, on a computer and on a phone. Most of it hides decorative icons or names controls. The home page carries 39 elements with aria-hidden and 17 with aria-label. No focusable element was hidden or marked with role="none" or role="presentation".
One control broke a rule. Our light and dark button was marked as a switch, but its name said what it would do and changed with the theme. On a light page, the accessibility tree gave screen readers a switch named “Switch to dark mode” that was on, while dark mode was off.
We followed the W3C pattern: when the label changes, the button carries no state. We removed the switch role and its on and off state, and kept the native button with its name. Now the tree shows a button: “Switch to dark mode” in light and “Switch to light mode” in dark. The page looks exactly as before. The three switches in our cookie preferences stay switches, because their names, such as Analytics, never change.
Before you publish
- Every control is a native element, or has a role, a name and keyboard support.
- No element that takes focus has aria-hidden="true" or role="presentation".
- States such as aria-checked and aria-expanded change with the control.
- Switches and toggle buttons keep the same label when they turn on or off.
- Decorative icons are hidden from screen readers.
- The accessibility tree shows the right role and name for each control.
RememberUse HTML first. ARIA only changes what assistive technologies are told, so every role and state you add has to stay true.
Pages built this way are part of our web design service.
Quick answers about ARIA
What is ARIA?
ARIA, short for Accessible Rich Internet Applications, is a set of roles and attributes from the W3C. It tells assistive technologies what an element is and what state it’s in, so a screen reader can announce custom controls and content that changes.
What are ARIA roles?
A role tells assistive technologies what an element is, such as a menu, a slider, a progress bar or a region of the page. Some roles need states as well: MDN says an element with role="checkbox" must also carry aria-checked.
What are the rules of ARIA?
The W3C document Using ARIA, now a discontinued draft kept for reference, gives four. Use a native HTML element when one does the job, and don’t change native semantics unless you really have to. Make every interactive ARIA control work with the keyboard. Never put role="presentation" or aria-hidden="true" on a focusable element.
Is ARIA bad for accessibility?
Not when it fills a real gap, but bad ARIA is worse than none, as MDN’s saying goes. In WebAIM’s 2026 study of a million home pages, pages with ARIA averaged 59.1 detected errors against 42 without it, though those pages were also more complex.
Can a switch change its label when it turns on?
No. The W3C patterns say the label on a switch or a toggle button must not change when its state changes. If your design changes the label, as with Mute and Unmute, use a plain button that carries no on or off state.
Sources
Read on November 5, 2026. W3C Web Accessibility Initiative: WAI-ARIA Overview, Using ARIA, Button Pattern and Switch Pattern. MDN Web Docs: ARIA and WAI-ARIA Roles. WebAIM: The WebAIM Million. Our case: our own pages, read in a browser on November 5, 2026.