A teammate builds a custom dropdown menu using a ` ` with `role="button"` and a list of ` ` elements, arguing it's more flexible to style than native ` ` or ` ` elements. Walk through how you'd evaluate this approach.

A strong answer covers: Names the first rule of ARIA directly: prefer native elements when they already provide the needed semantics, since ARIA only adds tree information, not behavior; Identifies the concrete gaps the div-based version likely has: keyboard focusability, arrow-key navigation between options, Enter/Escape handling, and correct aria-expanded/aria-activedescendant state management; Acknowledges the legitimate case for ARIA here too — a fully custom dropdown has no exact single native equivalent, so if going custom, correct ARIA (combobox/listbox pattern) plus full keyboard support is the actual bar, not just adding role attributes; Distinguishes 'flexible styling' as a real but separate concern from accessibility — native elements can usually be styled adequately, and styling difficulty alone doesn't justify skipping the behavior a native element provides for free.

Lesson 3 of 30

ARIA: When to Use It and the First Rule

ARIA has an actual first rule, and it's not 'add more of it': if a native element already has the semantics you need, use that element instead of rebuilding its meaning by hand.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A developer adds `role="button"` to a `<div>` and stops there, expecting it to now behave like a real button. What's missing?

Keyboard focusability and Enter/Space key activation, which a role attribute alone does not provideNothing — role="button" fully replicates native button behavior including keyboard handlingOnly the visual focus outline is missing; keyboard activation works automatically once role is set

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on ARIA: When to Use It and the First Rule

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate builds a custom dropdown menu using a `<div>` with `role="button"` and a list of `<div role="option">` elements, arguing it's more flexible to style than native `<select>` or `<button>` elements. Walk through how you'd evaluate this approach.

A strong answer covers

Names the first rule of ARIA directly: prefer native elements when they already provide the needed semantics, since ARIA only adds tree information, not behavior
Identifies the concrete gaps the div-based version likely has: keyboard focusability, arrow-key navigation between options, Enter/Escape handling, and correct aria-expanded/aria-activedescendant state management
Acknowledges the legitimate case for ARIA here too — a fully custom dropdown has no exact single native equivalent, so if going custom, correct ARIA (combobox/listbox pattern) plus full keyboard support is the actual bar, not just adding role attributes
Distinguishes 'flexible styling' as a real but separate concern from accessibility — native elements can usually be styled adequately, and styling difficulty alone doesn't justify skipping the behavior a native element provides for free

Likely follow-ups

If native <select> genuinely can't achieve the visual design required, what would 'doing this right' with ARIA actually require beyond just the role attributes?

The plain-language idea

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes — role, aria-label, aria-expanded, and dozens more — that add information to the accessibility tree. That word add is the whole story: ARIA can only tell the accessibility tree what something is. It cannot make the browser actually behave that way.

This is the First Rule of ARIA: if a native HTML element or attribute already provides the semantics and behavior you need, use it instead of repurposing a generic element and layering ARIA on top to fake those semantics back. Putting role="button" on a <div> tells the accessibility tree "this is a button" — but it does not make the div keyboard-focusable, it does not wire up Enter or Space to activate it, and it does not add any of the other behavior a real <button> gets automatically from the browser. All of that has to be built by hand, and most hand-built versions of it get something subtly wrong — a missing Space-key handler, a focus style that never shows up, a role that isn't actually reachable by keyboard at all.

ARIA earns its place in two situations, not as a general-purpose fix:

No native equivalent exists. A tab panel, a combobox with autocomplete, a live region that announces async updates — HTML has no native element for these, so ARIA roles and attributes are the only way to describe them to assistive technology.
Supplementing or overriding what's already there. aria-label when visible text alone isn't sufficient to identify a control, aria-hidden="true" to remove a purely decorative element (a background icon, a repeated visual flourish) from the accessibility tree even though it's visually present.

See it in a real thing: a div pretending to be a button

<!-- Wrong: ARIA promises behavior it doesn't deliver -->
<div role="button" aria-label="Submit">Submit</div>

<!-- Right: the native element already does all of this -->
<button>Submit</button>

The first version announces "Submit, button" to a screen reader — the accessibility tree now claims this is a button. But try tabbing to it: unless someone also added tabindex="0", it's not even reachable by keyboard. Add the tabindex and try pressing Enter or Space on it: nothing happens, unless someone also wrote a keydown handler for both keys (button activation responds to both, and it's easy to only wire up one). The second version gets focusability, both key handlers, and a visible focus outline from the browser, correctly, with zero lines of extra code.

What people usually miss

Watch out

ARIA adds accessibility-tree information; it never adds behavior. role, aria-expanded, aria-checked change what gets announced. None of them add keyboard handling, focus management, or any other actual browser behavior — that's still the developer's job whenever there's no native element doing it already.
"We added ARIA" is not the same claim as "this is now accessible." ARIA on a component that still can't be operated by keyboard, or whose state attributes don't update when the underlying state changes, is a false signal, not a fix — the accessibility tree now says something the component doesn't actually do.
The first rule of ARIA applies before reaching for ARIA at all, not as a cleanup pass after. The strongest fix for a div-based custom control is very often "use the native element instead," which eliminates the entire category of ARIA-role-and-keyboard-handling bugs rather than trying to patch them individually.
aria-hidden="true" hides something from the accessibility tree while leaving it fully visible and interactive on screen — a common, easy-to-get-backwards mistake is applying it to a control that's still meant to be operable, which silently removes it from screen reader users entirely while sighted users can still click it.

Why this matters in interviews

"When would you reach for ARIA, and when would you avoid it?" is a common filter question, and the strong answer leads with the first rule — native semantics over re-implemented ones — and names the concrete risk of incorrect ARIA (a false promise of behavior) rather than treating ARIA as an unconditional accessibility booster to sprinkle on everything.