What Are ARIA Attributes and When Should You Use Them?
Learn what ARIA attributes are, the three categories, the First Rule of ARIA, and when to use them vs native HTML.
Expected Interview Answer
ARIA (Accessible Rich Internet Applications) attributes are HTML properties that expose role, state, and relationship information to assistive technologies like screen readers when native HTML semantics alone cannot describe custom or dynamic UI, and the first rule of ARIA is to use it only after native HTML elements cannot do the job.
ARIA attributes fall into three groups: roles (like role="dialog" or role="tablist") that tell assistive tech what a generic element functionally is, states and properties (like aria-expanded, aria-checked, aria-selected) that describe current, changeable conditions, and relationships (like aria-controls, aria-labelledby, aria-describedby) that connect elements that are not naturally linked in the DOM tree. ARIA never changes an element's appearance or behavior — it only affects the accessibility tree that screen readers and other assistive technologies consume, so a div with role="button" still needs manually added keyboard handlers and tabindex to actually behave like a button. The W3C's "First Rule of ARIA Use" states that if a native HTML element or attribute already has the semantics and behavior you need (like <button> or <nav>), use that instead of recreating it with ARIA on a generic div or span, because native elements come with built-in keyboard support, focus management, and semantics for free. Misused or excessive ARIA is worse than no ARIA at all — it can announce incorrect or conflicting information to screen reader users.
- Exposes custom widget roles and states to assistive technology that native HTML cannot describe
- Enables accessible custom components like tabs, modals, and comboboxes
- Live regions (aria-live) let async content updates be announced without a page reload
- Improves usability for screen reader and other assistive technology users when applied correctly
AI Mentor Explanation
ARIA is like the extra hand signals an umpire gives when the scoreboard alone cannot capture what is happening — a raised finger for out, arms crossed for a dead ball. Native elements are like the scoreboard itself: if it already displays the score correctly, you do not need a hand signal to repeat it. But when a generic gesture, like pointing at the pitch, could mean several things, the umpire adds a specific signal so everyone watching, including those who cannot hear the commentary, understands exactly what is happening. Overusing hand signals for things the scoreboard already shows just creates confusion instead of clarity.
Step-by-Step Explanation
Step 1
Try a native element first
Check if <button>, <nav>, <dialog>, or another semantic HTML element already provides the needed role and behavior.
Step 2
Add a role only when necessary
If a custom widget has no native equivalent, assign the closest matching ARIA role (e.g., role="tablist").
Step 3
Reflect state with ARIA properties
Use aria-expanded, aria-selected, or aria-checked and keep them in sync with the actual UI state via JavaScript.
Step 4
Verify with a screen reader
Test with a real screen reader (VoiceOver, NVDA) to confirm announced roles, states, and labels match the visual behavior.
What Interviewer Expects
- Understanding of the First Rule of ARIA: prefer native HTML semantics first
- Ability to name the three ARIA categories: roles, states/properties, relationships
- Awareness that ARIA changes only the accessibility tree, not behavior or styling
- Knowledge that incorrect ARIA can be worse than no ARIA at all
Common Mistakes
- Adding role="button" to a div without also adding tabindex and keyboard event handlers
- Sprinkling ARIA attributes on already-semantic native elements redundantly
- Setting aria-expanded or aria-selected once and never updating it when state changes
- Using ARIA roles that do not match the actual widget behavior, confusing screen reader users
Best Answer (HR Friendly)
“ARIA attributes are extra bits of information added to HTML so that people using screen readers can understand custom parts of a website the same way sighted users see them, like a custom dropdown or a pop-up dialog. The rule of thumb is to only use ARIA when a normal HTML tag cannot already do the job, because native tags come with accessibility built in for free.”
Code Example
<button
type="button"
aria-expanded="false"
aria-controls="filters-panel"
id="filters-toggle"
>
Show Filters
</button>
<div id="filters-panel" role="region" aria-labelledby="filters-toggle" hidden>
<!-- filter controls -->
</div>
<script>
const toggle = document.getElementById('filters-toggle')
const panel = document.getElementById('filters-panel')
toggle.addEventListener('click', () => {
const isOpen = toggle.getAttribute('aria-expanded') === 'true'
toggle.setAttribute('aria-expanded', String(!isOpen))
panel.hidden = isOpen
})
</script>Follow-up Questions
- What is the difference between aria-labelledby and aria-describedby?
- How does aria-live work and when would you use assertive vs polite?
- Why does role="button" on a div require manual keyboard handling?
- How would you audit a page for ARIA misuse?
MCQ Practice
1. What is the First Rule of ARIA Use?
Native elements provide semantics and keyboard behavior for free; ARIA is a fallback for custom widgets.
2. What does ARIA actually change about an element?
ARIA only affects what assistive technologies perceive; it never adds behavior or styling on its own.
3. What must accompany role="button" on a <div> for it to work like a real button?
ARIA roles do not add keyboard focus or activation behavior, so developers must implement it manually.
Flash Cards
First Rule of ARIA? — Use native HTML semantics before reaching for ARIA.
Three ARIA categories? — Roles, states/properties, and relationships.
Does ARIA add keyboard behavior? — No — it only affects the accessibility tree, not behavior.
Example of an ARIA relationship attribute? — aria-labelledby or aria-controls.