How to Use ARIA Roles Correctly: Complete Guide (2026)

The Five Rules of ARIA (W3C)

Every ARIA decision should pass through these five rules from the W3C ARIA Authoring Practices.

• 1. If you can use native HTML, do. A real <button> is always better than <div role="button">. The native element brings role, name semantics, focus, and keyboard for free.
• 2. Don't change native semantics unless you really must. Putting role="button" on an <h1> erases the heading from the accessibility tree. Wrap or restructure instead.
• 3. All interactive ARIA must be keyboard-accessible. Adding role="button" to a <div> requires tabindex="0" plus Enter/Space handlers. No exceptions.
• 4. Don't use role="presentation" or aria-hidden="true" on focusable elements. The element stays in the tab order but disappears from the accessibility tree — keyboard users land on something invisible to their screen reader.
• 5. All interactive elements must have an accessible name.Role + name is the minimum. A button announced as just "button" is broken.

The Five Categories of ARIA Roles

Every role belongs to one of five buckets. Knowing the bucket tells you what the role is FOR, which native HTML element is its preferred replacement, and which states/properties it accepts.

How to Check Your Roles

• Greadme deep scan — flags abstract roles used directly, missing required keyboard handling on widget roles, duplicate landmarks (e.g. two role="main"), and roles that override important native semantics.
• Greadme crawler scan — checks roles across every indexable page so a broken modal pattern or tab strip surfaces site-wide instead of one page at a time.
• Greadme AI visibility analyzer — surfaces how clean role markup affects how AI answer engines parse and cite your pages.
• Chrome DevTools → Accessibility tab — view the computed accessibility tree for any element. If the role you expect is not there, the role attribute is wrong or being overridden.
• axe-core (the open-source rules engine) — integrates into Jest, Playwright, Cypress, and Storybook for build-time role validation.
• Manual screen-reader test — load the page in NVDA, JAWS, VoiceOver, or TalkBack and tab through. If a custom button is announced as "clickable" instead of "button," the role is missing.

Bad vs Good: The Custom Button Problem

The single most-cited ARIA mistake is a clickable <div>. Three correct ways to ship the same UI:

<!-- BAD: looks like a button, broken for keyboards and screen readers -->
<div onclick="save()" class="btn">Save</div>


<!-- GOOD #1: just use a real button (always preferred) -->
<button type="button" onclick="save()" class="btn">Save</button>


<!-- GOOD #2: link styled as a button (when navigation is the action) -->
<a href="/saved" class="btn">View Saved</a>


<!-- GOOD #3: div + role=button done right (only if 1 and 2 are impossible) -->
<div
  role="button"
  tabindex="0"
  onclick="save()"
  onkeydown="if (event.key === 'Enter' || event.key === ' ') { event.preventDefault(); save(); }"
  class="btn"
>
  Save
</div>

Pattern #3 is correct, but it's also four lines of code that <button> gives you for free — including disabled state, focus styles, and form submission. Reach for native HTML first.

8 Rules to Use ARIA Roles Correctly

<div role="dialog" aria-modal="true" aria-labelledby="dlg-title">
  <h2 id="dlg-title">Confirm Delete</h2>
  <p>This cannot be undone.</p>
  <button>Cancel</button>
  <button>Delete</button>
</div>

Common Role Mistakes and Fixes

Native HTML Element vs ARIA Role: Which to Pick

Almost every common ARIA role has a native HTML equivalent that does more, with less code. This table covers the substitutions you will reach for most often.

FAQ

What is an ARIA role, in one sentence?

An ARIA role is an attribute that tells assistive technology what category of UI element this is — button, checkbox, dialog, navigation, main content — when the underlying HTML tag does not already say so.

What are the Five Rules of ARIA?

(1) Use native HTML if you can; (2) don't change native semantics unless you must; (3) all interactive ARIA must be keyboard-accessible; (4) don't use role="presentation" or aria-hidden="true" on focusable elements; (5) every interactive element needs an accessible name. They come from the W3C ARIA Authoring Practices.

Is <button> really better than <div role="button">?

Yes — by a large margin. <button> is keyboard-accessible by default, supports the disabled attribute, submits forms, fires click on Enter and Space, and gets a default focus ring. The div equivalent requires tabindex, an onkeydown handler, manual disabled styling, and explicit form-submit logic — every one of which is a chance to ship a bug.

What does role="application" do, and when should I use it?

It tells screen readers to disable browse-mode shortcuts inside the region and pass keys directly to the page. Use it only when you are building a fully keyboard-driven, app-like surface (a web-based code editor, a complex graphing tool). On regular content pages it breaks normal screen-reader navigation.

Can I have more than one <nav> on a page?

Yes, but each one needs a distinct accessible name via aria-label (or aria-labelledby) so screen-reader users can tell them apart in the landmarks list. Common labels: "Primary," "Footer," "Breadcrumb."

Do ARIA roles affect AI search engines like ChatGPT and Perplexity?

Indirectly. AI answer engines parse semantic HTML and the accessibility tree to understand what each region of a page is. Clean roles produce a clean accessibility tree, better traditional search rankings, and stronger structured signals. AI engines preferentially cite pages that already rank well, so accessibility quality and AI visibility move together.

What's the difference between a role and an ARIA attribute?

The role says what the element is (button, tab, dialog). ARIA attributes (also called states and properties) describe its current condition or relationships — aria-expanded="true", aria-checked="mixed", aria-controls="menu-1". Each role has a fixed list of which states and properties it supports.