Goal
You’ll understand what ARIA actually does, the specific situations where it’s genuinely necessary, and the “first rule of ARIA” that prevents it from being misused.
Learn
ARIA (Accessible Rich Internet Applications) is a set of attributes that add accessibility information HTML alone can’t express — primarily needed for custom interactive components that don’t have a native HTML equivalent, like a custom dropdown menu, a tab interface, or a toggle switch built from styled divs.
<div role="button" tabindex="0" aria-pressed="false">Toggle</div>
Here, role="button" tells assistive technology to treat this div as a button, tabindex="0" makes it keyboard-focusable (divs aren’t focusable by default), and aria-pressed communicates its toggle state.
Here’s the genuinely important principle, often called the “first rule of ARIA”: if a native HTML element already provides the needed behavior and semantics, use it instead of recreating it with ARIA on a generic element. The example above, using a real <button> element, would automatically be focusable, automatically respond correctly to keyboard activation (both Enter and Space), and require zero ARIA attributes at all:
<button aria-pressed="false">Toggle</button>
This is strictly less code, and more robust, since the browser’s native button behavior is battle-tested across every assistive technology combination, while manually recreating that exact behavior with ARIA and JavaScript risks missing edge cases the native element handles automatically.
ARIA genuinely earns its place for things with no native equivalent at all — a tab panel interface, a live region that announces dynamic content changes, a custom autocomplete widget. For anything with a native element already covering the need, ARIA should be the exception, not the default approach.
Decision Task
A developer builds a custom dropdown menu using a styled <div>, adding role=”button”, tabindex=”0″, and JavaScript to handle Enter/Space key activation manually. Before reading on: is there a simpler, more robust alternative for at least part of this?
Show Answer
Yes — using a real <button> element instead of a div with role=”button” would provide focusability and keyboard activation (both Enter and Space) automatically, with zero custom JavaScript needed for that specific behavior, following the first rule of ARIA: use the native element when one already exists rather than recreating its behavior manually.
Common Mistake
Reaching for ARIA attributes on generic elements (like div or span) as a default habit, even when a native HTML element would provide the same behavior automatically and more reliably. This violates the first rule of ARIA, and typically results in more code that’s more fragile than simply using the correct native element from the start.
Practice Questions
1. According to the “first rule of ARIA,” when should you reach for ARIA attributes on a generic element like div?
Show Answer
Only when no native HTML element already provides the needed behavior and semantics — if one does, use that native element instead.
2. What does tabindex=”0″ do to a div that role=”button” alone doesn’t provide?
Show Answer
Makes the div keyboard-focusable, since generic divs aren’t focusable by default the way native interactive elements like button are.
3. Give one example of a genuine, appropriate use case for ARIA where no native HTML element provides an equivalent.
Show Answer
A custom tab panel interface, a live region announcing dynamic content updates, or a custom autocomplete widget — any interactive pattern with no direct native HTML equivalent.
4. True or False: using a real <button> element requires manually adding tabindex to make it keyboard-focusable.
Show Answer
False — button is natively focusable and keyboard-activatable by default, requiring no additional ARIA or tabindex for that basic behavior.
5. Why is native button behavior generally more robust than manually recreating equivalent behavior with ARIA and JavaScript on a div?
Show Answer
Native behavior is built into the browser and battle-tested across every assistive technology combination; manually recreating it risks missing edge cases the native element handles automatically and correctly by default.
Try It Yourself
Without looking back, rewrite this to follow the first rule of ARIA: <div role=”button” tabindex=”0″ onclick=”submitForm()”>Submit</div>
Show Answer
<button onclick="submitForm()">Submit</button> — using the native button element eliminates the need for role, tabindex, and manual keyboard-activation handling entirely, since button provides all of that automatically.
Quick Check
1. What does ARIA stand for?
Show Answer
Accessible Rich Internet Applications.
2. What is the “first rule of ARIA,” in plain terms?
Show Answer
If a native HTML element already provides the needed behavior/semantics, use it instead of recreating it with ARIA on a generic element.
3. What does role=”button” on a div tell assistive technology?
Show Answer
To treat that div as if it were a button, for the purposes of announcing its role to the user.
4. Why doesn’t a real <button> element need tabindex added manually?
Show Answer
It’s natively keyboard-focusable by default, unlike generic elements like div.
5. When does ARIA genuinely earn its place, according to this lesson?
Show Answer
For interactive patterns with no native HTML equivalent at all, like custom tab panels or live regions announcing dynamic updates.