ARIA Roles and Attributes: Best Picks Compared

Los ARIA roles and attributes disponibles en la especificación WAI-ARIA 1.2 de la W3C superan el centenar, pero en la práctica un puñado de ellos resuelve la mayoría de los problemas de accesibilidad en widgets construidos con XHTML y CSS. Esta guía compara los roles y atributos que de verdad se usan en producción, con criterios para elegir, errores frecuentes y herramientas de validación.

Qué son los roles y atributos ARIA (y qué no son)

Accessible Rich Internet Applications (ARIA) is a W3C specification that adds semantics to HTML elements that do not have them in a native form. A role describes what is an element (a button, a tab, a dialog), while an attribute describes its state or its relationships (aria-expanded, aria-controls, aria-labelledby). The first rule of ARIA, published by the W3C in Using ARIA, is blunt: if there is a native HTML element that already does the job, use it and do not add ARIA.

The reason is that ARIA does not modify browser behavior. A <div role="button"> does not receive focus with Tab, does not respond to the Enter key or space, and is not submitted with a form.

It only changes what the assistive technology announces. All interaction must be implemented with JavaScript and managed carefully. In XHTML/CSS projects where the HTML is static and the JS is minimal, this means that each of the aria roles and attributes that gets added is a promise that your code must fulfill.

The second rule of ARIA asks not to change the native semantics unless it is imprescindible. A <h2 role="tab"> breaks the structure of headings and confuses screen readers that navigate by regions. The third rule requires that all ARIA controls be operable with a keyboard. The fourth asks not to use aria-hidden="true" on elements that receive focus. The fifth, and the most forgotten, reminds us that any interactive element requires an accessible name: a role without a label is a mute button.

How to choose: criteria before the list

Choosing a role or attribute is not a matter of taste. These criteria, applied in order, avoid most errors regarding aria roles and attributes:

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

1. Is there a native HTML element? If so, use it. <button>, <details>, <dialog>, <input type="checkbox"> cover more cases than people think.
2. Does the widget need dynamic states? If it changes between open/closed, selected/not selected, or expanded/collapsed, you need state attributes (aria-expanded, aria-selected, aria-pressed).
3. Does it need relationships between elements? Relationship attributes (aria-controls, aria-labelledby, aria-describedby, aria-owns) connect pieces that the accessibility tree cannot infer from the DOM.
4. Does it need live announcements? Live regions (aria-live, role="status", role="alert") resolve updates without moving the focus.
5. Can I maintain it? A complex ARIA pattern without keyboard or screen reader tests is worse than having nothing.

The maintenance cost is the most ignored criterion. A well-made role="tablist" requires arrow key management, rotating tabindex, synchronization of aria-selected and aria-controls, and correct hiding of inactive panels. If the team cannot handle that, a set of links with anchors is more accessible and cheaper.

Comparativa de los roles ARIA más útiles

La tabla siguiente resume los roles que aparecen una y otra vez en auditorías reales, con su equivalente nativo cuando existe y la trampa más habitual.

Rol	Para qué sirve	Alternativa nativa	Trampa frecuente
button	Control que ejecuta una acción	<button>	No añadir manejo de Enter/Espacio ni tabindex="0"
link	Navegación a otra URL	<a href>	Usarlo para acciones que no navegan
dialog	Ventana modal o no modal	<dialog>	No atrapar el foco ni devolverlo al cerrar
tablist / tab / tabpanel	Interfaz de pestañas	Ninguna directa	No sincronizar aria-selected con el panel visible
menu / menuitem	Menú de aplicación	<select> o lista de enlaces	Usarlo para menús de navegación web
alert	Mensaje urgente e inmediato	role="status" para lo no urgente	Abusar de él y saturar al lector de pantalla
status	Actualización informativa	<output>	No insertarlo en el DOM antes de actualizar
progressbar	Progreso de una tarea	<progress>	No actualizar aria-valuenow
tooltip	Descripción emergente	title (limitado)	No asociarlo con aria-describedby
combobox	Campo con lista de sugerencias	<datalist> (limitado)	No anunciar el número de resultados

The choice between role="alert" and role="status" is a good example of a decision with nuances regarding aria roles and attributes. alert interrupts the current screen reader reading; status waits for the user to finish. For a form validation error, alert is appropriate. For “3 results found” while the user writes, status is correct and alert results in being intrusive.

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

Atributos ARIA imprescindibles y cómo se combinan

The attributes are associated with four families, and each one solves a distinct problem.

Etiquetado. aria-label provides a name when there is no visible text. aria-labelledby references the id of another element and is preferable when the text already exists on screen, because it maintains a single source of truth. aria-describedby adds a longer description, such as the help text of a field. The difference matters: the name is what the user hears upon focusing; the description is additional context that can be interrupted.

Estados. aria-expanded (true/false) for accordions and dropdown menus. aria-selected for tabs and options. aria-checked for custom checkboxes, with the value mixed for tri-state states. aria-pressed for toggle buttons. aria-disabled when the element is still focusable but not operable, as opposed to the native attribute disabled, which removes it from the tab order.

Relations. aria-controls indicates which element a button controls. aria-owns reorganizes the accessibility tree when the DOM does not reflect the visual relationship. aria-activedescendant allows you to maintain focus on a container while it announces the active element, a common pattern in comboboxes.

Live Regions. aria-live="polite" or "assertive" define urgency. aria-atomic="true" causes the entire block to be announced instead of just the modified part. aria-relevant filters which changes are announced.

A detail that is often overlooked: ARIA attributes only work on elements with a valid role. aria-expanded on a <div> without a role will not be announced. And ARIA boolean values are text strings ("true", "false"), not JavaScript boolean values; writing aria-expanded="false" as a boolean property will produce inconsistent results.

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

Errores que arruinan la accesibilidad de un widget

El error más costoso es usar ARIA para arreglar un HTML mal estructurado. Añadir role="navigation" a un <div> cuando ya había un <nav> disponible duplica regiones y confunde la navegación por landmarks.

The second error is the focus. A modal widget that does not move the focus when opened, does not trap it while it is open and does not return it to the trigger upon closing leaves the keyboard user navigating through invisible content. The native <dialog> element solves part of this, but not all: returning the focus is still the responsibility of the developer.

El tercer error es ocultar con aria-hidden elementos que siguen siendo enfocables. Un menú cerrado con aria-hidden="true" pero sin display: none o visibility: hidden mantiene sus enlaces en el orden de tabulación, y el usuario enfoca elementos que no puede ver. La combinación correcta es ocultar visualmente y del árbol de accesibilidad a la vez.

Worth a look: Deque axe DevTools Pro — El estándar de la industria para testear accesibilidad durante el desarrollo.

The fourth error is the absent accessible name. A <button> with a single SVG icon requires an aria-label or a <span class="visually-hidden"> with text. A decorative SVG requires aria-hidden="true" and focusable="false" so Internet Explorer and some older browsers do not include it in the tab order.

Herramientas para probar roles y atributos ARIA

There is no tool in place of testing with an actual screen reader, but the combination of various tools detects most failures in aria roles and attributes.

Static validation. The W3C ARIA validator (part of Nu HTML Checker) detects non-existent roles, poorly written attributes, and prohibited combinations. axe DevTools and Lighthouse point out roles without accessible names and missing mandatory attributes.

Accessibility tree inspection. Chrome and Firefox DevTools allow you to see the accessibility tree exactly as it is received by assistive technology. It is the fastest way to check if a role was actually applied and what accessible name the browser calculated.

Manual testing. Navigate the entire widget only with the keyboard (Tab, Shift+Tab, arrows, Enter, Space, Escape) and then with NVDA on Windows, JAWS if available, or VoiceOver on macOS and iOS. The combination of a desktop reader and a mobile one covers the majority of real cases.

Reference documentation. The W3C ARIA Authoring Practices Guide (APG) includes comprehensive patterns with keyboard and code examples. This is the source that should be consulted before inventing a new pattern.

Cómo decidir en un proyecto XHTML/CSS real

On XHTML sites with lightweight CSS and JavaScript, the most cost-effective strategy is to start with native HTML and add ARIA only where native does not reach. A form with correct <label>, <fieldset> and <legend> requires very little ARIA. A data table with <th scope> does not either. ARIA roles come in when patterns appear that HTML does not cover: tabs, accordions, comboboxes with filtering, modal dialogs and dynamic notifications.

It is advisable to document each use of ARIA roles and attributes in the code itself with a comment explaining why it is there. When someone refactors the component six months later, they will know if the aria-controls is still necessary or has become orphaned. Orphaned ARIA attributes—which point to ids that no longer exist—are a silent source of failures that no validator detects reliably.

Finally, treat accessibility as part of the component’s definition of “done”, not as a subsequent audit. A widget with ARIA roles tested with the keyboard and screen reader from the first commit costs much less than one repaired after the audit.

Key Takeaways

• ARIA roles and attributes do not add behavior: a role without keyboard and focus management is worse than having nothing.
• The first rule of ARIA is to use native HTML whenever it exists; <button>, <dialog>, and <details> cover more cases than one might think.
• Attributes are grouped into labeling, states, relationships, and live regions; each family solves a different problem.
• role="alert" interrupts and role="status" waits: choosing incorrectly saturates the screen reader user.
• ARIA boolean values are strings ("true"/"false"), and attributes only work on elements with a valid role.
• Testing with a keyboard and a real screen reader is mandatory; validators only detect a portion of the failures.

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

¿Cuál es la diferencia entre un rol y un atributo ARIA?

A role defines what an element is for assistive technology, such as role="tab" or role="dialog". An attribute describes its state or its relationships, such as aria-expanded or aria-labelledby. Roles are applied to the element that represents the component; attributes are usually applied to the same element or those that are related to it.

¿Cuándo debo usar ARIA en lugar de HTML nativo?

Only when there is no HTML element that covers the pattern. The first rule of W3C ARIA is explicit: if there is a native element, use it. ARIA roles are needed for tabs, accordions, comboboxes with filtering and modal dialogs, among other patterns that HTML cannot implement on its own.

¿Qué significa que un elemento tenga un nombre accesible?

An accessible name is the text that the screen reader announces when focusing the element. It is calculated from the content, from aria-label, from aria-labelledby or from an associated <label>, in an order of priority defined by the specification. An interactive role without an accessible name is a control that the user cannot identify.

¿Por qué mi role="button" no responde al teclado?

Because ARIA does not add behavior. A <div role="button"> needs tabindex="0" to receive focus and keydown handlers for Enter and Space. The simplest and most robust solution is to use the native <button> element, which already includes focus, keyboard activation and form submission.

¿Es malo usar aria-hidden="true"?

It is correct to hide decorative or duplicate content from the accessibility tree, but it should never be applied to elements that receive focus. If a focusable element is left with aria-hidden="true", the keyboard user may focus something that the screen reader does not announce. Always combine it with actual visual hiding.

¿Qué herramientas validan los roles y atributos ARIA?

The W3C Nu HTML Checker includes validation of ARIA roles and attributes and detects non-existent roles or forbidden combinations. axe DevTools and Lighthouse point out roles without an accessible name and missing mandatory attributes. To verify the final result, the accessibility tree inspector in the browser DevTools shows exactly what the assistive technology receives.

P.S. A few readers have asked which software de testing we actually reach for — it's Deque axe DevTools Pro; take a look here if you want the current details.