Skip to content

Introduction to ARIA — What Is Accessible Rich Internet Applications

DodaTech Updated 2026-06-28 4 min read

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

ARIA is a W3C specification that supplements HTML with roles, states, and properties making dynamic content accessible to assistive technologies when native HTML is not enough.

In this tutorial, you'll learn what ARIA is, why it exists, and how it fits into the broader Accessibility ecosystem.

What You'll Learn

By the end of this lesson, you'll understand the purpose of WAI-ARIA, its relationship to WCAG, when to use ARIA versus native HTML, and the core concepts of roles, states, and properties.

Why It Matters

Over 15 percent of the world's population experiences some form of disability. ARIA bridges the gap when HTML cannot convey the semantics needed by assistive technologies like screen readers.

Real-World Use

ARIA powers every major component library and design system, from Doda Browser's tabbed interface to Durga Antivirus Pro's scan progress indicators.

How ARIA Fits In

flowchart LR
  A[HTML Semantics] --> B{Need more?}
  B -->|Yes| C[ARIA Roles]
  B -->|No| D[Native HTML]
  C --> E[ARIA States & Properties]
  E --> F[Accessibility Tree]
  F --> G[Screen Readers]
  D --> F

Understanding the Basics

ARIA stands for Accessible Rich Internet Applications. It was created by the W3C's Web Accessibility Initiative (WAI) to address a gap: as web applications became more dynamic and complex, native HTML could not describe custom widgets, live updates, or complex interactions to assistive technologies.

Think of ARIA as a translation layer. When you build a custom component that looks and behaves like a tab panel but uses divs and CSS, ARIA tells the screen reader: "This div is a tab" and "This content panel belongs to that tab."

The Three Pillars of ARIA

ARIA is organized into three categories:

Roles define what an element is or does. A div with role="tab" is announced as a tab by screen readers. There are widget roles, Composite roles, document structure roles, landmark roles, and live region roles.

States describe current conditions that change over time. aria-expanded tells the screen reader whether a disclosure widget is open or closed. aria-selected indicates which tab in a tablist is active.

Properties describe characteristics that are typically more stable. aria-label provides an accessible name. aria-describedby points to a description element.

<div role="tab" aria-selected="true" aria-controls="panel-1">
  Security Settings
</div>

The screen reader announces "Security Settings tab selected" when this element receives focus.

First Rule of ARIA

No ARIA is better than bad ARIA.

If a native HTML element exists that provides the semantics you need, use it. A <button> has built-in keyboard handling, focus management, and correct screen reader announcements. A <div role="button"> requires all of that to be reimplemented.

<button>Scan Now</button>

This single line does more than fifty lines of ARIA on a div.

ARIA and the Accessibility Tree

Browsers take the DOM and create an accessibility tree that assistive technologies consume. ARIA attributes modify how nodes appear in this tree without changing the visual presentation.

<div role="button" tabindex="0" aria-pressed="false">
  Toggle Scan
</div>

In the accessibility tree, this div appears as a button with a pressed state. Visually, it looks however you style it with CSS.

Common Mistakes

  • Using ARIA when native HTML exists: A <nav> is better than <div role="navigation">.
  • Using ARIA that conflicts with native semantics: Adding role="heading" to an <h1> is redundant.
  • Omitting keyboard support: ARIA roles do not add keyboard behavior; you must implement it.
  • Using incorrect role hierarchy: A menuitem must be inside a menu role.
  • Forgetting to test with screen readers: ARIA in code does not guarantee correct announcements.

Practice and Challenge

1. What does ARIA stand for? Accessible Rich Internet Applications.

2. What are the three categories of ARIA? Roles, states, and properties.

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

4. What does role="button" tell a screen reader? That the element behaves as a button.

5. Challenge: Find three places on any website where ARIA is used and identify whether native HTML could replace it.

FAQ

Do I need ARIA on every element?

No. Use native HTML whenever possible. ARIA is only needed when native semantics are insufficient.

Does ARIA add keyboard support?

No. ARIA only changes how elements appear in the accessibility tree. You must implement keyboard handling separately.

Can ARIA make my site less accessible?

Yes. Incorrect ARIA can override native semantics and confuse screen reader users. Test every ARIA attribute.

Does ARIA work in all browsers?

ARIA support is consistent across modern browsers. Test with specific browser and screen reader combinations.

Is ARIA the same as WCAG?

No. WCAG defines accessibility requirements. ARIA is a technical specification for meeting some of those requirements.

Mini Project

Audit a web page's use of ARIA. List every ARIA attribute you find, note whether it is necessary, and recommend replacements with native HTML where possible.

What's Next

Continue to What Is ARIA for a deeper look at the WAI-ARIA specification.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro