The First Rule of ARIA — No ARIA Is Better Than Bad ARIA

In this tutorial, you will learn about The First Rule of ARIA. We cover key concepts, practical examples, and best practices to help you master this topic.

The first rule of ARIA states that no ARIA is better than bad ARIA, meaning you should always prefer native HTML elements before reaching for ARIA attributes.

In this tutorial, you'll learn the most important rule in ARIA and how to apply it in your projects.

What You'll Learn

By the end of this lesson, you'll understand the first rule of ARIA, why native HTML is superior, when to use ARIA, and how to identify unnecessary or harmful ARIA usage.

Why It Matters

Bad ARIA is worse than no ARIA. Incorrect ARIA can override native semantics, confuse screen readers, and make your site less accessible than if you had done nothing.

Real-World Use

Doda Browser's Accessibility validator flags redundant or conflicting ARIA attributes during development, preventing bad ARIA from reaching production.

The First Rule Decision Tree

flowchart TD
  A[Need a semantic element] --> B{Native HTML exists?}
  B -->|Yes| C{Does it provide the semantics you need?}
  C -->|Yes| D[Use native HTML. No ARIA needed.]
  C -->|No| E[Use ARIA to supplement]
  B -->|No| F[Use ARIA role]
  F --> G[Add required states]
  G --> H[Add keyboard support]
  H --> I[Test with screen reader]
  D --> I
  E --> I

Why Native HTML Wins

Native HTML elements come with built-in accessibility features that ARIA alone cannot provide:

• Keyboard handling: <button> responds to Enter and Space automatically.
• Focus management: <a href> is focusable by default with proper tab order.
• Accessibility tree mapping: <nav> appears as a navigation landmark without any ARIA.
• Platform integration: Native elements work with browser settings, zoom, and custom themes.

<!-- Bad: ARIA on a div requires reimplementing everything -->
<div role="button" tabindex="0" onclick="submit()" onkeydown="if(event.key==='Enter'||event.key===' ')submit()">
  Submit
</div>

<!-- Good: native button does it all -->
<button onclick="submit()">Submit</button>

When ARIA Is Necessary

There are legitimate cases for ARIA:

• Custom widgets with no native equivalent (tab panels, tree views, sortable grids)
• Live region announcements for dynamic content
• Supplemental labeling when visible labels are insufficient
• Overriding role semantics in rare cases

<!-- ARIA is necessary here: no native tab panel element -->
<div role="tablist" aria-label="Scan settings">
  <button role="tab" aria-selected="true" aria-controls="quick-panel">Quick</button>
  <button role="tab" aria-selected="false" aria-controls="full-panel">Full</button>
</div>

The Second Rule of ARIA

Do not change native semantics unless you have a very good reason. Adding role="button" to a link removes its implicit link semantics, including the ability to open in a new tab or bookmark.

<!-- Bad: changes a link to a button, losing navigation features -->
<a href="/page" role="button">Continue</a>

<!-- Good: use a real button if it acts as a button -->
<button onclick="navigate('/page')">Continue</button>

Common Mistakes

• Adding role="button" to a link: Loses the implicit link semantics.
• Using role="navigation" on a <nav>: Redundant and unnecessary.
• Adding aria-label when a visible label exists: Creates confusion between visible and announced labels.
• Using ARIA to fix poor HTML structure: Fix the HTML first.
• Copy-pasting ARIA patterns without understanding: Every component has different requirements.

Practice and Challenge

1. What is the first rule of ARIA? No ARIA is better than bad ARIA.

2. Why is a native <button> better than a <div role="button">? Native buttons have built-in keyboard support, focus management, and correct accessibility tree mapping.

3. When should you use ARIA? When no native HTML element provides the semantics you need.

4. Should you add role="main" to a <main> element? No. It is redundant and may cause conflicts.

5. Challenge: Find five examples of unnecessary ARIA on a website you use and suggest native HTML replacements.

FAQ