What Are ARIA Roles? A Practical Guide for Devs

What are ARIA roles? ARIA roles are the vocabulary of 87 defined values (as of WAI-ARIA 1.2) that tell assistive technologies what an element is and how it should behave regardless of its HTML tag. A role like button, navigation, or dialog assigns a generic <div> or <span> to a known widget type so that screen readers will announce it correctly and expose the correct keyboard interactions.

Why ARIA Roles Exist at All

To understand what are aria roles, one must see that they solve a structural problem that HTML alone cannot solve. Native HTML elements have implicit semantics: a <button> announces itself as a button, can be focused, responds to Enter and spacebar, and displays a pressed state when necessary.

When developers create custom widgets (a combobox, a tab panel, a tree view), they often use <div> and <span>, which contain no semantics. ARIA roles close this gap by allowing authors to explicitly state missing meaning.

The WAI-ARIA specification is maintained by the W3C’s Accessible Rich Internet Applications Working Group. The first version, ARIA 1.0, became a W3C Recommendation in 2014; ARIA 1.1 followed in 2017, and ARIA 1.2 reached Recommendation status in 2023. Roles, states, and properties were added with each revision, and each is linked to an authoring practices document that describes the expected behavior of the keyboard.

A key distinction separates the roles from the other two ARIA categories. The roles answer: “What is this?” States and properties answer: “What condition is it in?” and “What is it related to?” A role="checkbox" declares the widget type; aria-checked="true" indicates its current state. Confusing the two is one of the most common causes of broken custom widgets.

The Six Role Categories

To understand what are ARIA roles, it helps to know that the ARIA specification groups roles into six families. Understanding the family allows you to predict what states and properties a role supports and what keyboard patterns apply.

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

Category	Purpose	Representative roles
Abstract	Superclass definitions, never used in markup	widget, input, section
Widget	Interactive controls	button, checkbox, slider, tab
Document structure	Page landmarks and regions	banner, main, navigation, region
Landmark	Navigable page regions (subset of structure)	banner, complementary, contentinfo, form
Live region	Announce dynamic content changes	alert, status, log, timer
Window	Browser or application windows	dialog, alertdialog

Abstract roles are only used to organize the taxonomy. Authors must never write role="widget" or role="input" in markup; this results in undefined behavior and validation fails. The remaining five categories are the ones that you actually apply.

Implicit Roles and the First Rule of ARIA

Each HTML element has an implicit ARIA function (which explains what are aria roles) defined by the HTML Accessibility API Mapping (AAM) specification. A <nav> element has an implicit role="navigation". A <ul> has an implicit role="list". A <h1> to <h6> has role="heading". A <table> has role="table".

The first W3C rule on using ARIA clearly states: If a native HTML element or attribute already conveys the required semantics and behavior, use it instead of reusing an element with ARIA. Adding role="button" to a <button> is not necessary. Even worse, if you add role="button" to a <div>, you’ll get the announcement but no behavior: no focus, no keyboard activation, no form submission.

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

Redundancy is not always harmless. Overriding an implicit role can lose the semantics that assistive technology depends on. Writing role="presentation" in a <table> completely eliminates table semantics, which is sometimes intentional with layout tables but disastrous with data tables.

How Roles Interact With States and Properties

Roles act as containers for the states and properties they support. The specification defines which attributes are valid for which roles, and browsers only expose supported combinations in the accessibility tree.

Understanding what are aria roles helps in knowing that a role="checkbox" supports aria-checked with the values true, false, or mixed. A role="slider" supports aria-valuenow, aria-valuemin, aria-valuemax, and optionally aria-valuetext. A role="combobox" supports aria-expanded, aria-controls, and aria-activedescendant. Applying aria-checked to a role="button" is meaningless and will be ignored or produce confusing results in some screen readers.

The required properties are also important. A role="checkbox" without aria-checked is invalid; the state is mandatory and not optional. A role="slider" without aria-valuenow leaves the user unable to determine the current value. The ARIA specification labels them as “required states and properties,” and conformance checkers such as axe-core and IBM Equal Access Accessibility Checker point out their absence.

Roles, the Accessibility Tree and Browser Support

Browsers translate ARIA functions into platform accessibility APIs (UIA on Windows, AXAPI on macOS, ATK/AT-SPI on Linux), and screen readers use these APIs. A role that no browser correctly assigns is practically invisible to users.

Support varies by feature and browser. Core functions such as “Button”, “Link”, “Header”, “List” and “Navigation” are universally supported. Newer or more specialized roles (“feed”, “math”, “doc-footnote” from Digital Publishing’s WAI-ARIA module) have more patchy support. The role=“switch” is supported in modern browsers, but was inconsistently announced a decade ago.

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

Testing across the actual combinations your audience uses remains essential. A widget that works in NVDA with Firefox may behave differently in VoiceOver with Safari, because the two screen readers consume different platform APIs and apply different heuristics.

Landmark Roles and Page Structure

Landmark roles allow screen reader users to jump directly to areas of a page. The eight landmark roles are banner, complementary, contentinfo, form, main, navigation, region, and search. Modern HTML has native equivalents for most: <header> becomes banner, <footer> becomes contentinfo, <main> becomes main, <nav> becomes navigation, <aside> becomes complementary, <form> with an accessible name becomes form, and <section> with an accessible name becomes region.

Using native elements is preferable because they work even if CSS or JavaScript fails and because they reduce the risk of role/attribute conflicts. The search landmark has no native HTML equivalent, so role="search" is still the correct choice for the search region.

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

A common mistake is to apply role="banner" to a <div> that is inside a <main> or <article>. Landmark roles only create landmarks if they are not nested within certain other roles; a banner inside main will not be displayed as a landmark at all. Location in the DOM is as important as the role value. For those wondering what are aria roles, these landmarks are a key part of the specification.

Live Region Roles

When considering what are aria roles, live regional roles announce content changes without changing focus. The four live region functions are alert, status, log and timer, as well as the more general marquee. Each carries an aria-live value implicitly: alert and log in practice imply assertive and polite, respectively, while status implies polite.

Choosing between alert and status is a design decision with real consequences. An alert stops whatever the screen reader is reading, which is appropriate for errors and urgent notifications, but harmful if used excessively. A status waits for a pause, which coincides with progress messages and confirmation texts.

Live regions must exist in the DOM before the content changes. Inserting a role="alert" element and its text at the same time often results in no announcement because the region did not exist at the time of the change. The reliable pattern is to render an empty live region on page load and update its text content later.

When NOT to Use ARIA Roles

The second rule of using ARIA is that authors should not change the native semantics unless they really need to. The fifth rule states that every interactive element, regardless of its function, must be accessible and focusable via the keyboard.

Adding a role does not add behavior. role="button" on a <div> causes it to fail to focus, not respond to input or spacebar, and not submit the form. You need to add tabindex="0", a keystroke handler for input and space, and often “role-appropriate” state management. At this point, using a real “” requires less code and fewer errors.

Some roles are actively harmful when misapplied. role="presentation" and role="none" remove semantics from an element and, in some implementations, from its required descendants. Applying role="application" switches screen readers into a mode where they stop intercepting keystrokes, which can trap users if the custom keyboard handling is incomplete.

A Decision Framework for Choosing Roles

Working through a short sequence prevents most ARIA role errors. To understand what are ARIA roles and how to use them, follow these steps:

1. Identify the widget or region. Name what the element actually is in plain language.
2. Check for a native HTML equivalent. Consult the HTML-AAM mapping. If <button>, <select>, <details> or <dialog> fits, use it.
3. If no native element fits, select the closest ARIA role. Verify it exists in the current specification and is not abstract.
4. Add required states and properties. Check the role’s definition for mandatory attributes.
5. Implement the keyboard interaction pattern. Follow the WAI-ARIA Authoring Practices Guide for the widget type.
6. Test with at least two screen reader and browser combinations. Verify announcements, states and keyboard flow.

Steps three through six are where most custom widget errors occur. Skipping the keyboard pattern in step five creates a widget that advertises correctly but is inoperable, which is arguably worse than having no ARIA at all.

Testing and Validation Tools

Automated tools detect structural errors: invalid role values, missing required properties, and roles applied to elements that do not support them. axe-core, the engine behind many browser extensions, checks a defined subset of ARIA rules. The IBM Equal Access Accessibility Checker and the W3C’s own Nu HTML Checker also show role abuse.

Automated tools cannot verify whether a role produces the correct announcement or whether keyboard interaction works. Manual testing with NVDA and Firefox, JAWS and Chrome, or VoiceOver and Safari is still required. The Accessibility Insights for Web extension combines automated checks with a guided manual assessment that includes keyboard and screen reader verification.

The ARIA specification itself, the WAI-ARIA Authoring Practices Guide, and the HTML-AAM mapping document are the authoritative references for what are aria roles. The MDN Web Docs ARIA Reference is a convenient and well-selected secondary source that references the specification for each role.

Key Takeaways

• ARIA roles declare what an element is; WAI-ARIA 1.2 defines 87 roles in six categories and abstract roles may never appear in the markup.
• Native HTML elements have implicit roles and built-in behaviors, so the first rule when using ARIA is to prefer them to div plus role.
• Roles require their supported states and properties: a role="checkbox" without aria-checked is invalid and cannot be used.
• Adding a role never adds keyboard behavior or focusability; these must be implemented and tested separately.
• Landmark and Live Region roles have location and timing rules that determine whether they work or not.
• Automated inspectors only detect structural errors; testing of screen readers for different browser combinations is still required.

To understand what are ARIA roles, remember they define the purpose of an element for assistive technology.

Frequently Asked Questions

What are ARIA roles in simple terms?

ARIA roles are labels you attach to HTML elements to tell assistive technology what the element represents. A <div role="button"> is announced as a button rather than as generic text. Roles supply meaning that the underlying tag does not provide, but they do not add any behaviour, focus handling or keyboard support on their own.

What is the difference between ARIA roles and ARIA attributes?

Roles describe the type of an element, while attributes describe its state, value, or relationships. role="slider" identifies a slider; aria-valuenow="50" reports its current position and aria-labelledby points to its label. Roles and attributes are used together and each role defines which attributes it supports.

How many ARIA roles are there?

WAI-ARIA 1.2 defines 87 roles grouped into six

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.