Skip to content
ARIA Roles Guide for Beginners: When and How to Use Them

ARIA Roles Guide for Beginners: When and How to Use Them

4 min read

What Are ARIA Roles?

ARIA (Accessible Rich Internet Applications) is a set of attributes you add to HTML elements to improve how assistive technologies like screen readers interpret your content. ARIA roles specifically define what an element is or does, giving screen readers the context they need to announce elements correctly.

For example, a <div> that functions as a navigation menu is meaningless to a screen reader without context. Adding role="navigation" tells assistive technology that this container is a navigation landmark, allowing users to jump directly to it.

The WAI-ARIA specification, maintained by the W3C, defines dozens of roles organized into categories. This ARIA roles guide covers the ones you will encounter most often and the mistakes beginners commonly make.

The First Rule of ARIA: Don’t Use ARIA

This sounds counterintuitive in an ARIA roles guide, but it is the most important principle. Native HTML elements already have built-in accessibility semantics. A <button> element is already announced as a button. A <nav> element already has the navigation role. A <header> already serves as a banner landmark.

Use ARIA only when there is no native HTML element that provides the semantics you need. A <div> with role="button" is always inferior to a real <button> because the native element comes with built-in keyboard handling, focus management, and form submission behavior that you would have to manually recreate.

Categories of ARIA Roles

Landmark Roles

Landmark roles define major sections of a page. Screen reader users can navigate between landmarks to quickly orient themselves.

  • banner — The site header. Equivalent to <header> when it is a direct child of <body>.
  • navigation — A navigation section. Equivalent to <nav>.
  • main — The primary content area. Equivalent to <main>.
  • complementary — Supporting content related to the main content. Equivalent to <aside>.
  • contentinfo — Footer information like copyright and contact links. Equivalent to <footer> when it is a direct child of <body>.
  • search — A search facility. Equivalent to <search> in HTML.
  • form — A form region. Equivalent to <form> when it has an accessible name.
  • region — A generic landmark that should have an accessible name via aria-label or aria-labelledby.

Widget Roles

Widget roles describe interactive UI components that do not have native HTML equivalents or require enhanced semantics.

  • tablist, tab, tabpanel — Tab interfaces where users switch between panels.
  • dialog — A modal or non-modal dialog window.
  • alertdialog — A dialog that requires immediate attention, like a confirmation prompt.
  • tooltip — A contextual popup with descriptive text.
  • menu, menuitem — Application-style menus (not navigation menus).
  • tree, treeitem — Hierarchical list structures like file explorers.
  • slider — A user-adjustable value selector.

Document Structure Roles

These roles describe the organization of content:

  • heading — Identifies a heading (prefer <h1>-<h6> instead).
  • list, listitem — Identifies lists (prefer <ul>/<ol> and <li>).
  • img — Identifies an image, useful for CSS background images or SVG groups that function as a single image.
  • table, row, cell — Describes tabular data (prefer native <table> elements).

Live Region Roles

Live region roles tell screen readers to announce dynamic content changes:

  • alert — An important message that demands attention. Screen readers announce it immediately.
  • status — A non-urgent update, like a “Saved” confirmation. Announced at the next convenient pause.
  • log — Sequential updates like a chat history.
  • timer — A countdown or elapsed time display.

Practical Examples

Building an Accessible Tab Interface

<div role="tablist" aria-label="Product details">
  <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">Description</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">Reviews</button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  <!-- Description content -->
</div>
<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  <!-- Reviews content -->
</div>

Each tab uses role="tab", the container uses role="tablist", and panels use role="tabpanel". The aria-selected, aria-controls, and aria-labelledby attributes connect the pieces together.

Announcing Dynamic Updates

<div role="status" aria-live="polite">
  Your file has been uploaded successfully.
</div>

When the text content of this element changes, screen readers announce the new text without interrupting the user’s current activity.

Labeling Multiple Navigation Regions

When a page has more than one <nav>, each needs a unique label so screen reader users can distinguish them:

<nav aria-label="Main menu">...</nav>
<nav aria-label="Footer links">...</nav>

Common ARIA Mistakes Beginners Make

Using ARIA Instead of Native HTML

Adding role="button" to a <div> instead of using a <button> is the most common mistake. You lose built-in keyboard support, focus management, and form behavior. Always start with semantic HTML.

Adding Roles Without Required Attributes

Many ARIA roles require specific companion attributes. A role="slider" needs aria-valuenow, aria-valuemin, and aria-valuemax. Omitting these creates a broken experience for assistive technology users.

Overusing role="presentation" or role="none"

These roles strip an element of its native semantics. Applying role="presentation" to a <table> used for actual tabular data removes the table semantics that screen reader users depend on to navigate rows and columns.

Conflicting Roles and Semantics

Adding role="heading" to a <button> creates a confusing conflict. An element should have a single clear purpose. If you need a clickable heading, wrap the heading text in a <button> inside the heading element.

Forgetting Keyboard Interaction

ARIA roles set expectations. When a screen reader announces something as a “tab,” users expect arrow keys to switch tabs. If you add widget roles without implementing the expected keyboard patterns, you create a frustrating experience.

Testing ARIA Implementation

After adding ARIA roles, test them thoroughly:

  1. Use the wcagkit ARIA validator — Run the ARIA validator against your pages to catch missing required attributes, invalid role values, and conflicting semantics.
  2. Test with a screen reader — Listen to how your components are announced. VoiceOver on macOS, NVDA on Windows, and TalkBack on Android each handle ARIA slightly differently.
  3. Check the accessibility tree — Open browser DevTools, go to the Accessibility panel, and inspect the computed role and properties of each element.
  4. Validate keyboard navigation — Ensure every interactive element with an ARIA widget role is reachable and operable via keyboard alone.

Conclusion

ARIA roles are a powerful tool for making complex web applications accessible, but they are not a substitute for semantic HTML. Start with the right HTML elements, add ARIA only when native semantics fall short, and always test with real assistive technology.

Use the wcagkit ARIA validator to scan your pages for ARIA issues, and pair it with the link checker and heading analyzer for a comprehensive accessibility audit.