List of ARIA Roles: Best References Compared

La lista de roles ARIA completa consta de 82 valores definidos en la especificación WAI-ARIA 1.2 del W3C, organizados en seis categorías funcionales: roles de documento, de landmark, de widget, de estructura, de ventana y de estado abstracto. Elegir la referencia adecuada para consultarlos depende de si necesitas una tabla rápida, documentación con ejemplos de código o una guía de decisión sobre cuándo aplicar cada rol.

Key Takeaways

• La especificación WAI-ARIA 1.2 define 82 roles, pero solo un subconjunto reducido se usa en la práctica diaria de un sitio XHTML/CSS accesible.
• La primera regla de ARIA sigue vigente: si existe un elemento HTML nativo con la semántica que necesitas, úsalo en lugar de añadir un rol.
• Los roles abstractos (como role="widget" o role="input") nunca deben escribirse en el marcado; solo sirven como base taxonómica.
• Una referencia útil para front-end debe incluir el rol, sus atributos ARIA obligatorios, los estados permitidos y un ejemplo de marcado real.
• Los roles de landmark y de widget concentran la mayoría de los errores detectados por auditores automáticos como axe-core o Lighthouse.

Qué es un rol ARIA y por qué necesitas una lista fiable

Un rol ARIA es un valor que se asigna a un elemento mediante el atributo role para comunicar a las tecnologías de asistencia qué tipo de componente representa. El navegador expone ese rol a través del árbol de accesibilidad, y un lector de pantalla como NVDA, JAWS o VoiceOver lo traduce en un anuncio concreto: “botón”, “pestaña”, “región”, “cuadro de diálogo”.

La especificación WAI-ARIA, mantenida por el W3C dentro del grupo de trabajo ARIA, define cada rol junto a sus atributos de estado y propiedad permitidos. La versión 1.2 es la recomendación estable actual, y ARIA 1.3 se encuentra en desarrollo. Para un desarrollador que trabaja con XHTML y CSS, la lista de roles no es un catálogo decorativo: cada valor mal aplicado genera un conflicto entre la semántica nativa del elemento y la declarada, y los lectores de pantalla resuelven ese conflicto de formas distintas según el navegador.

La documentación oficial de roles de ARIA en MDN (Mozilla Developer Network) es la referencia técnica más consultada en español e inglés, pero no es la única. Existen hojas de referencia, guías de patrones y herramientas de validación que cubren necesidades distintas. Compararlas ayuda a elegir la que encaja con tu flujo de trabajo.

Las seis categorías de roles ARIA

La taxonomía oficial agrupa los roles según su función. Conocer las categorías evita buscar en la lista equivocada.

Roles de documento. Describen la estructura de una página o sección: article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Muchos duplican elementos HTML nativos, por lo que rara vez se escriben a mano.

Related: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Landmark roles. Define navigable regions of the page: banner, complementary, contentinfo, form, main, navigation, region, search. This is what is most used on sites with incomplete HTML semantics.

Widget roles. Represents interactive controls: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem. Requires focus and keyboard management.

Structure roles. Organization widgets include: application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

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

Window roles. Superimposed or modal content management: alertdialog, dialog.

Abstract roles. No elements are written in the markup: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Sirven for the specification to inherit properties between roles.

Comparativa: las mejores referencias de roles ARIA

La siguiente tabla compara las referencias más usadas por desarrolladores hispanohablantes según criterios prácticos.

Referencia	Tipo	Idiomas	Ejemplos de código	Ideal para
MDN Web Docs (Roles ARIA)	Documentación oficial	Multilingüe (incluye español)	Sí, por rol	Consulta técnica profunda
WAI-ARIA 1.2 (W3C)	Especificación normativa	Inglés	No	Verificar comportamiento exacto
WAI-ARIA Authoring Practices Guide	Guía de patrones	Inglés	Sí, patrones completos	Implementar widgets con teclado
Hoja de referencia tipo cheat sheet	Tabla resumen	Inglés	Mínimos	Repaso rápido en el editor
accessibility.build (referencia ARIA)	Referencia práctica	Inglés	Sí	Aprender con ejemplos comentados
Auditores (axe-core, Lighthouse)	Herramienta	Multilingüe	No	Detectar roles inválidos

La elección depende del momento. Durante la escritura de marcado, una hoja de referencia compacta gana en velocidad. Al depurar un widget que no anuncia bien su estado, la especificación del W3C y la guía de patrones de WAI son las fuentes que resuelven la duda.

Cómo decidir qué rol aplicar: criterios prácticos

La decisión correcta casi siempre empieza por descartar ARIA. Estos criterios, ordenados, evitan la mayoría de los errores.

1. ¿Is there a native HTML element? A <button> already has the implicit role of a button. Adding role="button" is redundant and may introduce conflicts.
2. ¿Role requires mandatory attributes? role="checkbox" requires aria-checked. role="slider" requires aria-valuenow, aria-valuemin and aria-valuemax. If you can’t maintain these states, the role harms more than it helps.
3. ¿Role involves keyboard management? Widget roles require navigation with arrows, Home, End and Esc depending on the pattern. A role="tablist" without arrow handling is worse than not having it.
4. ¿El rol es abstracto? If it is in the list of abstract roles, it should not be written.
5. ¿Is the role obsolete or in disuse? Some values were changed between ARIA 1.0 and 1.2. Always consult the current version.

The first rule for using ARIA, recognized in the W3C techniques guide, is the principle: use native HTML whenever possible. ARIA is a patch for when HTML is not enough, not a substitute.

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

Errores frecuentes al consultar y aplicar la lista de roles

Un error habitual consiste en copiar un rol de una hoja de referencia sin comprobar sus atributos requeridos. role="combobox" en ARIA 1.2 cambió respecto a 1.0 y ahora espera aria-expanded y una relación con un listbox mediante aria-controls. Aplicar la versión antigua rompe el anuncio en lectores actualizados.

It’s also common to use role="presentation" or role="none" to “clean up” the semantics without understanding that it eliminates the element from the accessibility tree, including its children in some cases. This also appears with the role="application" frequency, which transfers all keyboard control to the widget and disables screen reader shortcuts; it is reserved for complex web applications, not for forms.

Los roles de landmark duplicados generan confusión: dos role="main" en la misma página, o un role="banner" dentro de un <article>, producen una navegación por regiones incoherente. La validación con axe-core o con las herramientas de accesibilidad del navegador detecta varios de estos casos, aunque ninguna herramienta automática sustituye la prueba con lector de pantalla real.

If you are shopping: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Herramientas para validar roles en tu marcado

La comprobación de roles combina inspección manual y automatización. Las DevTools de Chrome y Firefox incluyen un panel de accesibilidad que muestra el árbol tal como lo recibe el sistema operativo, con el rol calculado de cada nodo. Es la forma más directa de ver si un rol declarado sobrevive o es sobrescrito por la semántica nativa.

axe-core, integrado en Lighthouse y disponible como extensión, marca roles inválidos, atributos obligatorios ausentes y combinaciones contradictorias. La extensión Accessibility Insights for Web, basada en las reglas de axe, añade comprobaciones guiadas. Para pruebas con usuarios reales, NVDA en Windows y VoiceOver en macOS ofrecen la verificación definitiva: ningún validador detecta si el anuncio resulta comprensible en contexto.

La documentación de accesibilidad de MDN y la guía de patrones de WAI-ARIA del W3C son las dos fuentes que conviene tener abiertas durante el desarrollo. La primera explica cada rol; la segunda muestra cómo se combinan en componentes completos.

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ántos roles ARIA existen?

The W3C WAI-ARIA 1.2 specification defines 82 roles in total, divided between document, landmark, widget, structure, window, and abstract roles. In this context, only a fraction is used in usual development: abstract roles are never written and many document roles duplicate native HTML elements.

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

Un rol ARIA describe qué es un elemento, mientras que los atributos ARIA describen su estado o propiedades. Por ejemplo, role="checkbox" identifica the component and aria-checked="true" communicates if it is checked. Los roles se asignan con el atributo role; los estados y propiedades usan el prefijo aria-.

¿Debo usar ARIA si ya uso HTML semántico?

In the majority of cases, no. Semantic HTML already exposes implicit roles: <nav> is equivalent to role="navigation" and <main> is equivalent to role="main". Adding the role explicitly is redundant and can create conflicts. ARIA is reserved for components that HTML does not cover, such as tabs, trees or complex menus.

¿Qué roles ARIA nunca debo escribir en el marcado?

Abstract roles should never appear: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget and window. They exist only for the specification to define inheritance of properties between roles. Writing them produces an invalid role that validators flag.

¿Cómo verifico que un rol ARIA funciona correctamente?

The verification combines three steps: inspecting the accessibility tree in the browser’s DevTools to confirm the calculated role, passing a validator like axe-core to detect missing mandatory attributes, and testing with a real screen reader like NVDA or VoiceOver. Only the last step confirms that the announcement is understandable to a person.

¿Los roles ARIA cambian entre versiones de la especificación?

Sí. ARIA 1.1 añadió roles como feed y switch, y ARIA 1.2 modificó el comportamiento de combobox y consolidó otros valores. ARIA 1.3 está en desarrollo. Consultar siempre la versión vigente de la especificación evita aplicar patrones obsoletos que los lectores de pantalla modernos interpretan de forma distinta.

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; take a look here if you want the current details.