What are ARIA roles and attributes and when should you use them?
Learn what ARIA roles, states, and properties do, when to use them over native HTML, and how to expose custom widgets accessibly to screen readers.
Expected Interview Answer
ARIA (Accessible Rich Internet Applications) is a set of roles, states, and properties you add to HTML to communicate the purpose and status of UI elements to assistive technologies like screen readers, used mainly when native HTML semantics cannot express a widget's behaviour.
ARIA has three families: roles that describe what an element is (role="dialog", role="tablist"), properties that describe relationships and labels (aria-label, aria-labelledby, aria-controls), and states that convey dynamic status (aria-expanded, aria-checked, aria-hidden). The golden rule is 'no ARIA is better than bad ARIA': always prefer a native element like <button> or <nav> that carries built-in semantics and keyboard behaviour, and reach for ARIA only for custom widgets, live regions, or gaps that HTML cannot fill. Misused ARIA overrides native semantics and can make a page less accessible than plain HTML.
- Exposes custom widgets correctly to screen readers
- Communicates dynamic state changes via aria-expanded and aria-checked
- Adds accessible names with aria-label and aria-labelledby
- Announces async updates through live regions (aria-live)
- Improves compliance with WCAG accessibility standards
AI Mentor Explanation
ARIA is like the on-field signals an umpire gives so spectators who cannot hear the decision still understand it — a raised finger means out, arms wide means a wide. When the game itself already makes the call obvious you add nothing, but for ambiguous moments the explicit signal ensures everyone, including those relying on it, reads the situation correctly.
Step-by-Step Explanation
Step 1
Prefer native HTML first
Use <button>, <nav>, <input> and other semantic elements — they carry roles, states and keyboard behaviour for free.
Step 2
Identify the gap
Reach for ARIA only when building a custom widget (tabs, dialog, combobox) or exposing dynamic updates HTML can't describe.
Step 3
Add a role
Give the element the correct role, such as role="tablist" or role="dialog", so assistive tech knows what it is.
Step 4
Wire up properties and states
Add aria-labelledby for names, aria-controls for relationships, and states like aria-expanded that you update in JavaScript.
Step 5
Test with assistive tech
Verify with a screen reader and keyboard that roles are announced, focus is managed, and states change correctly.
What Interviewer Expects
- Knows ARIA covers roles, properties, and states
- Cites 'no ARIA is better than bad ARIA' and native-first
- Gives examples like aria-label, aria-expanded, role="dialog"
- Understands live regions for dynamic announcements
- Knows ARIA does not add behaviour, only semantics
Common Mistakes
- Adding role="button" to a div instead of using <button>
- Using aria-label where native text already provides a name
- Forgetting to update ARIA states like aria-expanded in JavaScript
- Assuming ARIA adds keyboard behaviour (it does not)
- Overusing aria-hidden and hiding important content
Best Answer (HR Friendly)
“ARIA is a way to add extra labels and status information to web page elements so screen readers can describe them accurately to people with disabilities. The best practice is to use normal HTML elements whenever possible and only add ARIA for custom components that HTML can't describe on its own.”
Code Example
<button
aria-expanded="false"
aria-controls="panel-1"
id="toggle-1"
>
Shipping details
</button>
<div id="panel-1" role="region" aria-labelledby="toggle-1" hidden>
Your order ships within 2 business days.
</div>
<!-- In JS, toggle aria-expanded and the hidden attribute together -->
<script>
const btn = document.getElementById('toggle-1');
const panel = document.getElementById('panel-1');
btn.addEventListener('click', () => {
const open = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!open));
panel.hidden = open;
});
</script>Follow-up Questions
- Why is 'no ARIA is better than bad ARIA' a guiding principle?
- What is the difference between aria-label and aria-labelledby?
- How do aria-live regions announce dynamic content changes?
- Does adding role="button" give an element keyboard support?
- When should you use aria-hidden and what are its risks?
MCQ Practice
1. What does the aria-expanded attribute communicate?
aria-expanded is a state that tells assistive tech whether a controlled region is currently expanded (true) or collapsed (false).
2. Which is the best practice when a native element exists?
Native elements carry built-in semantics and keyboard behaviour, so 'no ARIA is better than bad ARIA' favours using them directly.
3. What does ARIA NOT provide?
ARIA only conveys semantics; you must implement keyboard interaction yourself, which is why native elements are preferred.
Flash Cards
What are the three ARIA families? — Roles (what it is), properties (labels/relationships), and states (dynamic status).
The golden rule of ARIA — No ARIA is better than bad ARIA — prefer native HTML semantics first.
aria-label vs aria-labelledby — aria-label sets a name from a string; aria-labelledby references another element's id for the name.
Does ARIA add keyboard behaviour? — No — ARIA only adds semantics; you must code focus and key handling yourself.
What is aria-live for? — It marks a region so assistive tech announces dynamic content updates automatically.