ARIA or semantic HTML.
If semantic HTML already carries an element’s role, adding ARIA brings no benefit; ARIA is only for what HTML cannot express.
The two approaches are not rivals but a sequence. The first rule in the W3C’s guidance on using ARIA is this: if there is an HTML element with the right meaning, use it and do not add ARIA. ARIA is a complement, not an alternative.
Why ARIA adds no behaviour
This is the most commonly misunderstood point. ARIA attributes only write information into the accessibility tree; they make the browser do nothing. Giving a div role="button" does not make it focusable, does not make it respond to Enter, and does not stop clicks when it is disabled. All three have to be written by hand, and all three are frequently forgotten.
A real button element, by contrast, carries all of them natively and behaves consistently across browser versions. The same relationship holds for lists, headings, navigation, form fields and tables. What semantic markup is is written separately.
Where ARIA is genuinely required
Some components have no HTML equivalent: a tab panel, a tree view, a combo box, a slider. They cannot be described to assistive technology without ARIA, and the W3C’s authoring patterns were written for exactly these components.
The second group is relationships. Which field a form error belongs to, the name of a region, announcing content that changes without a page load — none of these has an HTML equivalent. On this site the error messages in the contact form are announced as a live region, and their relationship to the field is established with aria-describedby. The form as a whole is described separately.
The test: neither too little nor too much
The practical rule is this: if removing an attribute makes what the screen reader says poorer, it is necessary; if nothing changes, it is unnecessary and brings nothing but maintenance. Auditing tools mostly do not catch excess ARIA — because it is technically valid, merely wrong. The limits of automated auditing are written separately.
Criterion
- Role information — Semantic HTML: Comes from the element itself — button, nav, main · ARIA: Declared by hand with an attribute — role="button"
- Keyboard behaviour — Semantic HTML: Provided by the browser: focus, Enter, Space · ARIA: Must be written — ARIA declares, it does not add behaviour
- State management — Semantic HTML: Handled by the browser (disabled, checked) · ARIA: Must be updated by hand (aria-expanded, aria-checked)
- Risk of error — Semantic HTML: Low — behaviour is built in · ARIA: High — a wrong role misleads assistive technology
- Code cost — Semantic HTML: Close to zero · ARIA: Separate update code for every state
- When it is needed — Semantic HTML: Wherever an equivalent exists · ARIA: For components with no HTML equivalent — tab panel, tree, combo box
- Live updates — Semantic HTML: No separate mechanism · ARIA: Announced with aria-live — no HTML equivalent
FREQUENTLY ASKED QUESTIONS
Does adding ARIA everywhere improve accessibility?
No, it usually reduces it. Wrong or unnecessary ARIA tells assistive technology that an element is something other than what it really is; having no ARIA at all is better than that.
When is ARIA needed?
When you build a component HTML has no equivalent for: a tab panel, a tree view, a combo box, a live region. And for relationships HTML cannot express — such as which field an error belongs to.
Is role="button" the same as <button>?
It is not. role="button" declares the role only; focusability, response to Enter and Space, and the disabled state all have to be written by hand. <button> gets all of them from the browser.