In web accessibility, the "first rule of ARIA use" is quoted constantly in interviews. What does the rule say, and what does following it look like in real markup?
answer
- precedence, not prohibition
- the tree, not the behaviour
- promises the browser cannot keep
- native element first, ARIA for gaps
basics
~20 sThe first rule of ARIA is to not use ARIA when a native HTML element already provides the semantics and behaviour you need. Reach for button, a with href, input and label first; add ARIA only to fill real gaps.
solid answer
~50 sThe rule says: if a native HTML element or attribute already has the semantics and behaviour you need built in, use it instead of repurposing a generic element and bolting on an ARIA role, state or property. The reason is that ARIA only writes to the accessibility tree — it changes what assistive technology *reports*, never what the element *does*. `role="button"` on a `<div>` adds no focusability, no Enter/Space activation, no form participation, no disabled handling; a real `<button>` ships all of that plus the correct role. So in practice: `<button>` for actions, `<a href>` for navigation, `<input type="checkbox">` over `role="checkbox"`, `<label for>` over `aria-label` when visible text exists. ARIA is for the gaps HTML genuinely does not cover — widget patterns with no element, extra relationships, and dynamic state — not for making a div pretend.
go deeper
Be able to state the rule in one sentence and give one example: use <button> instead of a div with a role. Say plainly that ARIA changes what a screen reader announces, not what the element does.
Explain the mechanism — ARIA feeds the accessibility tree, while focusability, keyboard activation and form participation come from the element itself. Be ready to list what <button> provides that you would otherwise hand-write.
Show judgment about where ARIA is genuinely required versus where it is covering for a styling decision, and be able to argue a team out of a custom widget by pricing the behaviour they would have to own and retest.
Own the tradeoff at library scale: which primitives the organisation guarantees natively, how exceptions get approved and reviewed, and how you keep ARIA usage from growing as a proxy metric for accessibility effort.
## What the rule says The W3C's *Using ARIA* note opens with five rules of ARIA use. The first one is the one interviewers quote: if you can use a native HTML element or attribute that already has the semantics and behaviour you require built in, rather than repurposing an element and adding an ARIA role, state or property to make it accessible, then do so. It is often compressed to the slogan "the first rule of ARIA is don't use ARIA", which is a memorable but slightly misleading summary — the rule is about *precedence*, not prohibition. ## Why it exists: ARIA describes, it does not implement A browser builds two things from your markup: the DOM, and an **accessibility tree** — a parallel structure exposed to screen readers, voice control and other assistive technology, where each node carries a role (what kind of thing this is), a name (what it is called), and states and properties (checked, expanded, disabled, and so on). ARIA attributes are *inputs to that tree only*. They do not attach event handlers, do not put an element in the tab order, do not give it keyboard behaviour, and do not make it part of a form. So this markup is a lie the browser will faithfully repeat: ```html <div role="button">Save</div> ``` A screen reader announces "Save, button", the user presses Enter, and nothing happens — the div was never focusable and never had activation behaviour. The ARIA made the situation *worse* than an unannotated div, because it promised an interaction that does not exist. ## What a native element bundles The reason native-first is a rule rather than a preference is how much a real element carries at once. `<button>` alone gives you: - an implicit `button` role in the accessibility tree; - membership in the sequential focus order with no `tabindex` needed; - activation on both Enter and Space, which dispatch a real click event; - `type="submit"` by default inside a form, so it submits without script; - a working `disabled` attribute that blocks activation *and* removes it from the tab order; - default focus indication the UA draws, which `:focus-visible` styling hooks into; - correct behaviour in platform modes such as Windows High Contrast, and correct exposure to touch-screen-reader gestures. The same pattern repeats elsewhere: `<a href>` is a real link with navigation, keyboard activation, and browser affordances such as "open in new tab"; `<input type="checkbox">` carries a checked state the platform manages; `<select>` gets the operating system's own picker on mobile; `<label for>` makes clicking the text focus and toggle the control. Every one of those behaviours is something a re-implementation has to write, test on every platform, and keep working forever. ## What ARIA is legitimately for The rule is not "never write `aria-*`". ARIA earns its place where HTML has no equivalent: - **Widget patterns with no element** — tabs, tree views, comboboxes, grids. - **Dynamic state on things HTML cannot express** — a control that reports whether the section it owns is currently open. - **Relationships** — pointing a control at its hint or error text, or naming a region that has no visible heading. - **Announcements** — telling assistive technology that a region updates asynchronously. Even then, the native element is the *host* for the ARIA where possible: a disclosure trigger is a `<button>` with an ARIA state on it, not a div with a role plus a state. ## The failure mode it prevents Teams reach for ARIA because a custom design "can't use a native element" — usually a styling belief rather than a fact. The result is a widget whose accessibility is a hand-written specification that only its author understands, that no automated tool can verify for truthfulness, and that quietly rots as the component is refactored. Large-scale surveys of production home pages have repeatedly found that pages using more ARIA average *more* detected accessibility errors, not fewer — because ARIA is overwhelmingly deployed to paper over non-native markup rather than to extend it. ## In an interview Say the rule, then immediately ground it: ARIA changes the accessibility tree, not behaviour, so a `<div role="button">` still has no focus and no keyboard activation. That single sentence is what the question is actually checking.
- If ARIA only writes to the accessibility tree, why does it exist at all?Because HTML's vocabulary is finite. There is no `<tabs>`, no `<combobox>`, no `<treeview>`, and no native way to say "this control expands that panel" or "this region updates on its own". ARIA lets you describe those things to assistive technology while you supply the behaviour in script. It extends the vocabulary; it was never meant to substitute for elements that already exist.
- Is there ever a reason to put an ARIA role on an element that already has that role natively?Almost never — a redundant `role="button"` on a `<button>` is noise that future readers must decide about, and it risks silencing the element if someone typos the value. The narrow legitimate case is patching a known browser or assistive-technology mapping bug for a specific element. Treat it as a workaround: comment it with the bug it fixes and remove it when the bug is gone.
- A designer says the native control cannot be styled to match the mockup, so the team must build a custom one. How do you respond?Test the claim before accepting it. Most "unstylable" controls — buttons, checkboxes, radios, links — are fully stylable today; only a few, such as a `<select>` drop-down list, historically resisted. If a native element covers 90 percent of the design, ship it and negotiate the remaining 10 percent, because the alternative is owning a keyboard and screen-reader implementation forever.
saying these in an interview costs you the question
- Thinks adding role="button" makes an element clickable by keyboard
- Says ARIA is required on every interactive element
- Reads the slogan as "ARIA is bad, never use it"
- Believes native elements cannot be styled, so custom is unavoidable
- Assumes assistive technology infers behaviour from the CSS or the handler