ARIA Roles Cheat Sheet: Best Picks Compared
Un aria roles cheat sheet es una referencia que asigna cada rol ARIA a su elemento HTML nativo equivalente, su categoría (widget, landmark, estructura, live region o ventana) y las propiedades y estados que lo acompañan. WAI-ARIA 1.2 define 82 roles, y la mayoría de proyectos solo necesita entre 15 y 20 de forma recurrente. Esta comparativa reúne las mejores hojas de referencia disponibles en 2026 y explica cuál conviene según tu flujo de trabajo.
Por qué una cheat sheet de roles ARIA sigue siendo necesaria
Especificaciones como WAI-ARIA 1.2 y su sucesora WAI-ARIA 1.3 son documentos densos, pensados para implementadores de navegadores y tecnologías de asistencia, no para quien maqueta un formulario un martes por la tarde. La primera regla de ARIA —usar HTML nativo siempre que exista— resuelve la mayoría de casos, pero hay patrones que no tienen equivalente nativo: pestañas, árboles, grids interactivos, comboboxes con autocompletado, menús con submenús. Ahí es donde una hoja de referencia ahorra tiempo y, sobre todo, evita errores.
El error más común no es olvidar un rol, sino añadir uno innecesario. Un <button> con role="button" no aporta nada y puede romper el comportamiento nativo en algunos lectores de pantalla. Una cheat sheet bien hecha marca explícitamente qué roles son redundantes sobre elementos nativos, qué roles requieren gestión de foco por JavaScript y qué atributos son obligatorios frente a opcionales.
La segunda razón es la verificación. Los roles tienen relaciones de propiedad: aria-labelledby apunta a un id, aria-activedescendant exige que el elemento referenciado exista y sea visible, aria-owns solo se justifica cuando el orden del DOM no coincide con el orden visual. Una tabla que cruce rol, atributos requeridos y atributos prohibidos detecta fallos antes de que lleguen a una auditoría.
Qué debe incluir una buena cheat sheet de roles ARIA
Una hoja de referencia útil para desarrollo front-end cumple cinco criterios. Los listo porque son exactamente los que he usado para evaluar las opciones de esta comparativa.
- **Coverage of all five role categories. **WAI-ARIA groups roles in summaries, widgets, document structure, landmarks and live regions. Summaries (
roletype,widget,input) are not used in the framework; a good reference to visible shape data. - Native HTML equivalent for the role. Without this column, the reference prompts to use ARIA there without touching.
- Required, supported, and prohibited attributes.
role="checkbox"requiresaria-checked;role="heading"requiresaria-level;role="presentation"is not allowed. - Patrón de teclado asociado. A role without teclado management is a promise included.
role="tablist"implies different elements/derecha,HomeandEnd. - Searchable format. Buscador, filter by category, specification version and ability to copy the code fragment.
Comparativa: las mejores referencias de roles ARIA en 2026
La tabla siguiente resume las opciones más sólidas. Ninguna es de pago; todas se mantienen activas y citan la versión de la especificación que cubren.
Related: — con plan gratuito para empezar hoy mismo.
| Recurso | Enfoque | Categorías cubiertas | Equivalente nativo | Patrón de teclado | Ideal para |
|---|---|---|---|---|---|
| WAI-ARIA Authoring Practices Guide (APG), W3C | Patrones completos con ejemplos | Widgets, landmarks, estructura, live regions | Sí, en cada patrón | Sí, detallado | Implementar un widget concreto |
| MDN Web Docs, referencia de roles ARIA | Ficha por rol | Todas, incluidos abstractos | Sí | Parcial | Consultar un rol puntual |
| ARIA Authoring Practices, índice de roles | Tabla rol → atributos | Widgets y estructura | Parcial | No | Verificar atributos requeridos |
| Deque University, ARIA reference | Fichas con notas de soporte | Widgets y landmarks | Sí | Parcial | Conocer soporte real por lector |
| A11Y Project Checklist | Lista de verificación | Transversal | No aplica | No | Auditar antes de publicar |
| HTML-ARIA (W3C), tabla de equivalencias | Rol permitido por elemento | Todas | Sí, es su propósito | No | Decidir si ARIA es necesario |
WAI-ARIA Authoring Practices Guide (APG)
La APG del W3C es la referencia canónica para patrones. Cada patrón incluye estructura HTML, roles, estados, interacción de teclado y un ejemplo funcional. Su punto fuerte es que no se limita a listar roles: explica el comportamiento esperado. Su punto débil es que no es una tabla rápida; para consultar «qué atributos lleva role="slider"» hay que navegar hasta el patrón correspondiente.
APG groups the most common widget users: accordion, alert, breadcrumb, button, checkbox, combo box, dialog, disclosure, feed, grid, link, list box, menu, menu bar, radio group, slider, rotary knob, switch, table, tab list, toolbar, tooltip, grid tree, and tree view. If your project uses one of these, run it here.
MDN Web Docs: la referencia por rol
MDN maintains a page for each ARIA role, with the description, required attributes, allowed attributes, associated accessibility issues, and links to the specification. This is the quickest option when you know what you’re doing. Your coverage includes abstract roles and roles in use, although many reminders are omitted.
Worth a look: — Accesibilidad gestionada: automatización combinada con revisión humana.
Un detalle práctico: MDN marca qué roles están obsoletos o en riesgo de eliminación en futuras versiones de la especificación. Consultar esa marca evita adoptar un rol que desaparecerá.
HTML-ARIA: la tabla que evita ARIA innecesario
La especificación HTML-ARIA del W3C define, para cada elemento HTML, qué roles ARIA se le pueden aplicar y cuáles son redundantes. Es la herramienta decisiva cuando dudas entre usar un elemento nativo o un div con rol. Si el rol que quieres aplicar aparece como redundante para ese elemento, la respuesta es no añadirlo.
Deque University y A11Y Project
Deque University ofrece fichas de rol con notas sobre soporte real en lectores de pantalla, algo que la especificación no cubre porque no es su cometido. El A11Y Project Checklist no es una cheat sheet de roles, pero funciona como lista de verificación previa a publicación y complementa bien a las anteriores.
Cómo elegir según tu caso
La decisión depende de tres preguntas. Primero, ¿ya sabes qué rol necesitas? Si la respuesta es sí, MDN es la vía más corta. Segundo, ¿estás construyendo un widget con interacción compleja? Entonces necesitas la APG, porque el rol por sí solo no describe el comportamiento de teclado. Tercero, ¿dudas entre HTML nativo y ARIA? Consulta HTML-ARIA antes que cualquier otra fuente.
Para equipos que trabajan con XHTML y CSS sin frameworks, la combinación más eficiente suele ser: HTML-ARIA para decidir, APG para implementar y MDN para verificar atributos. Una cheat sheet de una sola página sirve como memoria a corto plazo, pero no sustituye a estas tres fuentes cuando aparece un caso límite.
Un criterio adicional que conviene aplicar: si el rol requiere JavaScript para funcionar correctamente (gestión de foco, actualización de aria-expanded, sincronización de aria-selected), trátalo como una decisión de arquitectura, no como un atributo decorativo. Los roles de widget sin la lógica asociada generan más barreras que la ausencia de rol.
Related: — La que acredita tu experiencia en accesibilidad.
Errores frecuentes que ninguna cheat sheet evita por sí sola
Los roles de landmark duplicados confunden la navegación por regiones. Un role="main" sobre un <main> es redundante; dos role="navigation" sin etiqueta distintiva son ambiguos. La solución es aria-label o aria-labelledby en cada landmark repetido.
Los roles de widget sobre elementos no enfocables rompen la interacción. role="button" sobre un <div> exige tabindex="0" y manejo de Enter y Espacio. Sin eso, el rol anuncia un botón que no se puede activar con teclado.
Discontinued states are the most common cause of audience declines. aria-expanded which does not change to open a chord, aria-selected which does not update when pestaña changes or aria-checked in a role="switch" which is fixed. Ninguna tabla lo detecta: hace falta probar con teclado y con una reader de la pantalla real.
Abstract roles in the market are a mistake in principle. role="widget", role="input" or role="section" must not appear in HTML; exist alone for the jerarquía of the specification.
Key Takeaways
- WAI-ARIA 1.2 define 82 roles, pero la mayoría de proyectos solo usa entre 15 y 20 de forma recurrente.
- La primera regla de ARIA —usar HTML nativo cuando exista— convierte la tabla HTML-ARIA del W3C en la referencia más importante antes de escribir cualquier rol.
- La APG del W3C es insuperable para patrones de widget porque incluye interacción de teclado; MDN es más rápida para consultar un rol concreto.
- Un rol sin gestión de foco y sin actualización de estados genera más barreras de accesibilidad que no usar ARIA.
- Ninguna cheat sheet sustituye la prueba con teclado y con lector de pantalla: los estados desincronizados solo se detectan en uso real.
Preguntas frecuentes
¿Cuántos roles ARIA existen?
WAI-ARIA 1.2 define 82 roles, repartidos en cinco categorías: abstractos, widgets, estructura de documento, landmarks y live regions. Los roles abstractos no se aplican nunca en el marcado; sirven para organizar la jerarquía de la especificación. En la práctica, un proyecto típico utiliza entre 15 y 20 roles distintos.
¿Cuál es la mejor cheat sheet de roles ARIA?
Depende del uso. Para implementar un widget con teclado, la WAI-ARIA Authoring Practices Guide del W3C es la referencia más completa. Para consultar los atributos de un rol concreto, MDN Web Docs es más rápida. Para decidir si un rol es necesario sobre un elemento HTML, la tabla HTML-ARIA del W3C es la fuente decisiva.
¿Debo usar ARIA si existe un elemento HTML nativo?
No. La primera regla de ARIA establece que si existe un elemento HTML con la semántica y el comportamiento que necesitas, se usa ese elemento en lugar de un div con rol. Añadir role="button" a un <button> es redundante y puede alterar el comportamiento nativo en algunos lectores de pantalla.
¿Qué diferencia hay entre un rol de widget y un rol de landmark?
Los roles de widget describen controles interactivos —button, checkbox, slider, tablist— y requieren gestión de foco y teclado. Los roles de landmark describen regiones de la página —main, navigation, banner, contentinfo— y sirven para la navegación por regiones. Un mismo elemento no debería cumplir ambas funciones.
¿Los roles ARIA cambian entre versiones de la especificación?
Sí. WAI-ARIA 1.2 añadió roles como blockquote, caption, code, deletion, emphasis, insertion, meter, paragraph, strong, subscript y superscript. Algunos roles han quedado obsoletos en versiones posteriores. Conviene comprobar en MDN o en la propia especificación si un rol sigue vigente antes de adoptarlo.
¿Una cheat sheet de roles ARIA basta para cumplir WCAG?
No. Los roles ARIA son una parte del criterio 4.1.2 Nombre, rol y valor, pero WCAG 2.2 incluye muchos otros requisitos: contraste, foco visible, tamaño de objetivo, texto alternativo, estructura de encabezados. Una cheat sheet ayuda a implementar roles correctamente, no a cumplir el conjunto de los criterios de conformidad.
Sources & Further Reading
- Cheat sheet — Wikipedia: A cheat sheet (also cheatsheet) or crib sheet or job aid is a concise set of notes used for quick reference. Cheat sheets were historically used by students without…
P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; if you want the current details.
¿Cumplir WCAG sin tocar el código?
Superposición de IA que promete cumplimiento WCAG en 48 horas