ARIA Roles Examples: A Complete Guide

The ARIA role examples show how role attributes map interface elements to the accessibility tree, and the WAI-ARIA 1.2 specification defines 6 role categories—widget, document structure, landmark, live region, window, and abstract—covering more than 80 concrete roles. This guide presents ready-to-copy practical examples for each category, as well as the rules that determine when a role helps and when it actively harms.

Key Takeaways

• ARIA roles tell the assistive technology what an item is; they never add behavior, focus, or keyboard support on their own.
• The first rule of using ARIA is to prefer native HTML elements, which already carry implicit roles, states and keyboard management.
• The six WAI-ARIA 1.2 role categories are widget, document structure, landmark, active region, window, and summary — abstract roles should never appear in your markup.
• Landmark roles are the most cost-effective and lowest-risk ARIAs you can add to an existing XHTML/CSS site.
• Widget roles almost always require JavaScript mapping for keyboard interaction and state handling, or they create a worse experience than plain HTML.
• Validate each role with a screen reader and automated checker; a valid role in the specification may still be wrong for your content.

What ARIA Roles Actually Do

ARIA roles are tokens that you place in the role attribute to replace or provide the semantic identity of an element in the accessibility tree. A <div role="button"> tells a screen reader to announce “button”, but the browser still treats it as a generic container: it is not focusable, it does not respond to Enter or Space, and it does not have a disabled state.

This gap between advertised semantics and actual behavior is the most common source of ARIA failure. These are common aria roles examples of how semantics can diverge from behavior.

The WAI-ARIA specification, maintained by the W3C’s Accessible Rich Internet Applications Working Group, defines roles as well as states and properties. Roles are the “what is it” layer; states and properties like aria-expanded, aria-checked, and aria-label are the “what condition is it in” layer. A role without its required states is incomplete — role="checkbox" requires aria-checked, and role="combobox" requires aria-expanded plus a controlled listbox.

Native HTML elements carry implicit roles. <button> corresponds to the button role, <nav> to navigation, <h1> through <h6> to heading, and <input type="checkbox"> to checkbox. Because the browser automatically provides the role, keyboard behavior, and state, the first rule of using ARIA—documented in the W3C’s ARIA Authoring Practices Guide—is to use native semantics whenever an equivalent element exists. Look for explicit roles only when no native element is suitable, such as a custom tree view or a tabbed panel built from <div>s.

The Six WAI-ARIA Role Categories

WAI-ARIA 1.2 organizes roles into six categories, and knowing which category a role belongs to tells you how much JavaScript you owe it. Here are some common aria roles examples:

Related: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Category	Purpose	Example roles	JavaScript required?
Widget	Interactive controls	button, checkbox, tab, slider, combobox	Yes — keyboard + state
Document structure	Content organization	heading, list, listitem, table, article	No
Landmark	Page regions for navigation	banner, main, navigation, complementary	No
Live region	Announce dynamic updates	alert, status, log, timer	Usually — to trigger updates
Window	Sub-windows and dialogs	dialog, alertdialog	Yes — focus management
Abstract	Superclass roles, never authored	widget, input, section, landmark	N/A — do not use

Abstract roles only exist to organize the taxonomy. Writing role="input" or role="section" in your HTML is a validation error and produces unpredictable announcements because these roles have no defined behavior for assistive technology.

Landmark Role Examples

Landmark roles are the safest and most impactful ARIA roles examples you can add to an older XHTML/CSS site because they require no JavaScript and map directly to regions you already have. A typical page skeleton:

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

Each marker role corresponds to a native element — banner to <header> at the top level, main to <main>, navigation to <nav>, complementary to <aside>, contentinfo to <footer>. When you use the native element, the role is implied and you should not repeat it. The explicit role attribute earns its place only when you’re stuck with <div> markup that you can’t modify, which is common in older templates and CMS output.

Worth a look: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Two caveats are in order here. First, banner, main and contentinfo must appear once per page; several main landmarks disrupt navigation. Second, when multiple landmarks of the same type exist – say three <nav> elements – give each a separate aria-label so that screen reader users can distinguish them in the landmark list. An unlabeled nav is advertised the same way as its siblings, which defeats the purpose.

Widget Role Examples

Widget roles are where ARIA becomes both powerful and dangerous in equal measure. Each widget role has an implicit contract: specific keyboard keys, specific states, and specific focus behavior. The ARIA Authoring Practices Guide publishes the full pattern for each. These aria roles examples illustrate the complexity involved.

A toggle button, for example, needs aria-pressed to communicate its on/off state:

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

The <button> element supplies the role, focus, and Enter/Space handling; JavaScript only flips aria-pressed between "false" and "true". This is the ideal shape of ARIA usage — native element, minimal ARIA, small script.

A custom tab interface built from <div>s is the opposite case. It needs role="tablist" on the container, role="tab" on each tab, role="tabpanel" on each panel, aria-selected on the active tab, aria-controls linking the tab to the panel, and arrow key navigation between tabs.

If you miss any of these, the widget announces itself as tabs but behaves like static text. The same applies to role="slider" (requires aria-valuenow, aria-valuemin, aria-valuemax and arrow keys), role="combobox" (requires aria-expanded and a controlled listbox), and role="tree" (requires aria-expanded and full arrow key traversal).

Related: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

A useful decision rule: If there is a native element that does the job — <button>, <input type="checkbox">, <select>, <details> — use it and ignore the widget role altogether. Reserve custom widget roles for truly novel controls and budget the JavaScript to implement the full keyboard pattern before shipping.

Document Structure and Live Region Examples

Document structure roles describe content relationships when native elements are not available. These aria roles examples include role="heading" with aria-level, which is the classic rescue for a styled <div> acting as a heading:

<div role="heading" aria-level="2">Novedades del mes</div>

The aria-level attribute is mandatory here — a heading role without a level is announced without a rank, breaking the document outline. Similarly, role="list" and role="listitem" restore list semantics when CSS such as list-style: none or a flex container remove them in some browsers, and role="table", role="row", role="columnheader" and role="cell" rebuild a data table from the <div> markup. In practice, restructuring into actual <ul>, <ol> and <table> elements almost always requires less work than maintaining a full set of structure roles.

Worth a look: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Live region roles announce changing content without a page reload. role="alert" immediately interrupts the screen reader and accommodates error messages and urgent notifications; role="status" waits politely and is fine with confirmations like “Guardado”; role="log" fits chat and activity feeds; role="timer" corresponds to countdowns. The critical detail is that the live region container must exist in the DOM before the content changes — injecting a new element with role="alert" and its text at the same time often produces no announcement, because the region was not present to be monitored. Create an empty <div role="status"> on page load and update its text later.

Common ARIA Role Mistakes

Redundant roles top the list. These aria roles examples, such as <button role="button"> and <nav role="navigation">, add nothing and clutter the markup; the implicit role already exists. The same redundancy appears when developers add role="heading" to an <h2>.

Missing required states come second. role="checkbox" without aria-checked, role="slider" without aria-valuenow, and role="combobox" without aria-expanded all produce incomplete announcements that mislead users. The specification lists required states and properties for each role, and automated checkers flag their absence.

Role misuse on the wrong element is third. Putting role="button" on an <a href> overrides the link semantics and breaks expected behavior like opening in a new tab. Putting role="presentation" or role="none" on a focusable element removes its semantics while leaving it in the tab order, creating a focusable element with no announced identity. And using abstract roles such as role="widget" or role="input" is always an error.

Finally, ARIA roles cannot fix a broken DOM. A role="tabpanel" nested within its own role="tab" produces a nonsense tree no matter how many attributes you add. Fix the structure first, then layer ARIA on top.

How to Test ARIA Roles

Testing ARIA roles requires multiple methods, as automated tools detect validity errors but not semantic mismatches. Start with an accessibility checker - axe DevTools, WAVE, or Lighthouse - to detect invalid roles, missing required attributes, and abstract roles in your markup. These tools are fast and detect mechanical errors.

Follow with a screen reader pass. NVDA with Firefox on Windows, JAWS with Chrome, and VoiceOver with Safari on macOS each expose the accessibility tree differently, and a role that announces correctly in one may not in another. Navigate by landmark and by heading to confirm your structure roles produce the expected outline, then tab through every widget to verify the announced role, state, and keyboard behavior match.

Inspect the Accessibility tree directly in Chrome or Firefox DevTools, where the “Accessibility” panel displays the calculated role and name of any element. This reveals the gap between the role you wrote and the role the browser actually exposes - the quickest way to detect a role that is overridden by a parent or ignored entirely.

Sources & Further Reading

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the World Wide Web Consortium (W3C) that…

Frequently Asked Questions

What are ARIA roles and how do they work?

ARIA roles are values ​​in the role attribute that define the identity of an element in the accessibility tree, so that screen readers announce it correctly. They only change semantics, not appearance, focus, or keyboard behavior. The WAI-ARIA 1.2 specification defines six role categories and more than 80 concrete roles, each with required states and properties.

When should I use ARIA roles instead of native HTML?

Use ARIA roles only when no native HTML element provides the semantics you need. Native elements like <button>, <nav>, and <input type="checkbox"> carry implicit roles plus built-in keyboard support and state management. The first rule of ARIA use is to prefer native semantics, and to add explicit roles only for custom widgets or legacy markup you cannot restructure.

What is the difference between ARIA roles and ARIA attributes?

ARIA roles answer “what is this item”, while ARIA attributes such as aria-expanded, aria-checked, and aria-label answer “what state is it in” or “what is it called”. The roles and their required attributes work together: as aria roles examples, role="checkbox" is incomplete without aria-checked, and role="combobox" needs aria-expanded plus a controlled listbox.

Can I use ARIA roles on any HTML element?

ARIA roles can be applied to most elements, but some combinations are invalid or harmful. Abstract roles such as widget and input should never be authored. Changing a link’s role to role="button" breaks the expected behavior of the link, and role="presentation" on a focusable element removes its semantics while leaving it in tab order.

Do ARIA roles work without JavaScript?

Document structure and landmark roles work without JavaScript because they only modify semantics. Widget roles like tab, slider, and combobox require JavaScript to implement keyboard interaction and update states — without it, the element announces itself as a control but doesn’t behave like one, which is worse than plain HTML.

How do I check whether my ARIA roles are correct?

Combine automated and manual testing. Run axe DevTools, WAVE, or Lighthouse to detect invalid roles and missing required attributes, then test with NVDA, JAWS, and VoiceOver to confirm announcements and keyboard behavior. The Accessibility panel in Chrome and Firefox DevTools displays the computed role, revealing any roles that the browser overrides or ignores.

P.S. A few readers have asked which widget de accesibilidad we actually reach for — it's UserWay; take a look here if you want the current details.