Ejemplos de roles de ARIA: una guía completa

Los ejemplos de roles de ARIA muestran cómo los atributos de roles asignan elementos de la interfaz al árbol de accesibilidad, y la especificación WAI-ARIA 1.2 define 6 categorías de roles (widget, estructura de documento, punto de referencia, región activa, ventana y resumen) que cubren más de 80 roles concretos. Esta guía presenta ejemplos prácticos listos para copiar para cada categoría, así como las reglas que determinan cuándo un rol ayuda y cuándo perjudica activamente.

Conclusiones clave

• Los roles ARIA le dicen a la tecnología de asistencia qué es un elemento; nunca agregan comportamiento, enfoque o soporte de teclado por sí solos.
• La primera regla al usar ARIA es preferir elementos HTML nativos, que ya llevan implícitos roles, estados y administración del teclado.
• Las seis categorías de roles de WAI-ARIA 1.2 son widget, estructura de documento, punto de referencia, región activa, ventana y resumen; los roles abstractos nunca deben aparecer en su marcado.
• Los roles Landmark son los ARIA más rentables y de menor riesgo que puede agregar a un sitio XHTML/CSS existente.
• Las funciones de widget casi siempre requieren mapeo de JavaScript para la interacción del teclado y el manejo del estado, o crean una peor experiencia que HTML simple.
• Validar cada rol con un lector de pantalla y un verificador automatizado; es posible que un rol válido en la especificación aún sea incorrecta para su contenido.

Qué hacen realmente los roles de ARIA

Los roles ARIA son tokens que se colocan en el atributo “role” para reemplazar o proporcionar la identidad semántica de un elemento en el árbol de accesibilidad. Un <div role="button"> le dice a un lector de pantalla que anuncie “botón”, pero el navegador aún lo trata como un contenedor genérico: no se puede enfocar, no responde a Enter o Space y no tiene un estado deshabilitado.

Esta brecha entre la semántica anunciada y el comportamiento real es la fuente más común de falla de ARIA. Estos son ejemplos comunes de roles de aria de cómo la semántica puede divergir del comportamiento.

La especificación WAI-ARIA, mantenida por el Grupo de Trabajo de Aplicaciones Ricas de Internet Accesibles del W3C, define funciones, así como estados y propiedades. Los roles son la capa de “qué es”; estados y propiedades como “aria-expanded”, “aria-checked” y “aria-label” son la capa “en qué condición se encuentra”. Un rol sin sus estados requeridos está incompleto: role="checkbox" requiere aria-checked y role="combobox" requiere aria-expanded más un cuadro de lista controlado.

Los elementos HTML nativos tienen funciones implícitas. <button> corresponde a la rol de botón, <nav> a la navegación, <h1> hasta <h6> al encabezado y <input type="checkbox"> a la casilla de verificación. Debido a que el navegador proporciona automáticamente la función, el comportamiento del teclado y el estado, la primera regla para usar ARIA (documentada en la Guía de prácticas de creación de ARIA del W3C) es usar semántica nativa siempre que exista un elemento equivalente. Busque roles explícitos solo cuando ningún elemento nativo sea adecuado, como una vista de árbol personalizada o un panel con pestañas creado a partir de <div>.

Las seis categorías de roles WAI-ARIA

WAI-ARIA 1.2 organiza los roles en seis categorías, y saber a qué categoría pertenece un rol le indica cuánto JavaScript le debe. Aquí hay algunos ejemplos comunes de roles de aria:

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

Categoría	Propósito	Roles de ejemplo	¿Se requiere JavaScript?
Widget	Controles interactivos	“button, checkbox, tab, slider, combobox`	Sí — teclado + estado
Estructura del documento	Organización de contenidos	“heading, list, listitem, table, article`	No
Punto de referencia	Regiones de página para navegación	“banner, main, navigation, complementary`	No
Región en vivo	Anunciar actualizaciones dinámicas	“alert, status, log, timer`	Generalmente: para activar actualizaciones
Ventana	Subventanas y cuadros de diálogo	“dialog, alertdialog`	Sí, gestión del enfoque
Abstracta	Roles de superclase, nunca escritos	widget, “widget, input, section, landmark`	N/A — no usar

Los roles abstractos sólo existen para organizar la taxonomía. Escribir role="input" o role="section" en su HTML es un error de validación y produce anuncios impredecibles porque estos roles no tienen un comportamiento definido para la tecnología de asistencia.

Ejemplos de roles emblemáticos

Los roles Landmark son los ejemplos de roles ARIA más seguros e impactantes que puede agregar a un sitio XHTML/CSS antiguo porque no requieren JavaScript y se asignan directamente a las regiones que ya tiene. Un esqueleto de página típico:

<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>

Cada función de marcador corresponde a un elemento nativo: banner a <header> en el nivel superior, main a <main>, navigation a <nav>, complementary a <aside>, contentinfo a <footer>. Cuando utilizas el elemento nativo, el rol está implícito y no debes repetirlo. El atributo explícito role gana su lugar sólo cuando estás atascado con el marcado <div> que no puedes modificar, lo cual es común en plantillas y resultados de CMS más antiguos.

Vale la pena echarle un vistazo: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Aquí conviene hacer dos advertencias. Primero, banner, main y contentinfo deben aparecer una vez por página; varios puntos de referencia “principales” interrumpen la navegación. En segundo lugar, cuando existen varios puntos de referencia del mismo tipo (por ejemplo, tres elementos <nav>), asigne a cada uno una etiqueta-aria separada para que los usuarios del lector de pantalla puedan distinguirlos en la lista de puntos de referencia. Un “nav” sin etiqueta se anuncia de la misma manera que sus hermanos, lo que va en contra del propósito.

Ejemplos de funciones de widgets

Las funciones de los widgets son donde ARIA se vuelve poderosa y peligrosa a partes iguales. Cada función de widget tiene un contrato implícito: teclas de teclado específicas, estados específicos y comportamiento de enfoque específico. La Guía de prácticas de creación de ARIA publica el patrón completo para cada uno. Estos ejemplos de roles de aria ilustran la complejidad involucrada.

Un botón de alternancia, por ejemplo, necesita “aria-pressed” para comunicar su estado activado/desactivado:

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

El elemento <button> proporciona el rol, el foco y el manejo de Enter/Space; JavaScript solo cambia “aria-pressed” entre “falso” y “verdadero”. Esta es la forma ideal de uso de ARIA: elemento nativo, ARIA mínima, escritura pequeña.

Una interfaz de pestaña personalizada creada a partir de <div> es el caso opuesto. Necesita role="tablist" en el contenedor, role="tab" en cada pestaña, role="tabpanel" en cada panel, aria-selected en la pestaña activa, aria-controls que vincula la pestaña al panel y navegación con teclas de flecha entre pestañas.

Si omite alguno de estos, el widget se anuncia como pestañas pero se comporta como texto estático. Lo mismo se aplica a role="slider" (requiere aria-valuenow, aria-valuemin, aria-valuemax y teclas de flecha), role="combobox" (requiere aria-expanded y un cuadro de lista controlado) y role="tree" (requiere aria-expanded y un recorrido completo de las teclas de flecha).

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

Una regla de decisión útil: si hay un elemento nativo que hace el trabajo (<button>, <input type="checkbox">, <select>, <details>), úsalo e ignora la función del widget por completo. Reserve funciones de widget personalizadas para controles verdaderamente novedosos y presupuesta el JavaScript para implementar el patrón de teclado completo antes del envío.

Ejemplos de estructura de documento y región activa

Los roles de estructura de documentos describen relaciones de contenido cuando los elementos nativos no están disponibles. Estos ejemplos de roles de aria incluyen role="heading" con aria-level, que es el rescate clásico para un <div> con estilo que actúa como encabezado:

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

El atributo “aria-level” es obligatorio aquí: un rol de encabezado sin nivel se anuncia sin rango, rompiendo el esquema del documento. De manera similar, role="list" y role="listitem" restauran la semántica de la lista cuando CSS como list-style: none o un contenedor flexible los eliminan en algunos navegadores, y role="table", role="row", role="columnheader" y role="cell" reconstruyen una tabla de datos a partir del marcado <div>. En la práctica, la reestructuración en elementos reales <ul>, <ol> y <table> casi siempre requiere menos trabajo que mantener un conjunto completo de roles estructurales.

Vale la pena echarle un vistazo: Deque axe DevTools Pro — El estándar de la industria para probar la accesibilidad durante el desarrollo..

Los roles de región en vivo anuncian cambios de contenido sin recargar la página. role="alert" interrumpe inmediatamente el lector de pantalla y acomoda mensajes de error y notificaciones urgentes; role="status" espera cortésmente y acepta confirmaciones como “Guardado”; role="log" se adapta a las fuentes de chat y actividad; role="timer" corresponde a cuentas regresivas. El detalle crítico es que el contenedor de la región en vivo debe existir en el DOM antes de que cambie el contenido: inyectar un nuevo elemento con role="alert" y su texto al mismo tiempo a menudo no produce ningún anuncio, porque la región no estaba presente para ser monitoreada. Cree un <div role="status"> vacío al cargar la página y actualice su texto más tarde.

Errores comunes en el rol de ARIA

Los roles redundantes encabezan la lista. Estos ejemplos de roles de aria, como <button role="button"> y <nav role="navigation">, no agregan nada y saturan el marcado; el papel implícito ya existe. La misma redundancia aparece cuando los desarrolladores agregan role="heading" a un <h2>.

Los estados requeridos que faltan ocupan el segundo lugar. role="checkbox" sin aria-checked, role="slider" sin aria-valuenow y role="combobox" sin aria-expanded producen anuncios incompletos que engañan a los usuarios. La especificación enumera los estados y propiedades requeridos para cada función, y los verificadores automáticos señalan su ausencia.

El mal uso del rol en el elemento equivocado es el tercero. Poner role="button" en un <a href> anula la semántica del enlace y rompe el comportamiento esperado, como abrir en una nueva pestaña. Poner role="presentation" o role="none" en un elemento enfocable elimina su semántica y lo deja en el orden de tabulación, creando un elemento enfocable sin identidad anunciada. Y usar roles abstractos como role="widget" o role="input" siempre es un error.

Finalmente, los roles ARIA no pueden arreglar un DOM roto. Un role="tabpanel" anidado dentro de su propio role="tab" produce un árbol sin sentido sin importar cuántos atributos agregue. Primero arregle la estructura, luego coloque ARIA encima.

Cómo probar los roles ARIA

Probar los roles de ARIA requiere múltiples métodos, ya que las herramientas automatizadas detectan errores de validez pero no discrepancias semánticas. Comience con un verificador de accesibilidad (ax DevTools, WAVE o Lighthouse) para detectar roles no válidos, atributos requeridos faltantes y roles abstractos en su marcado. Estas herramientas son rápidas y detectan errores mecánicos.

Siga con un pase de lector de pantalla. NVDA con Firefox en Windows, JAWS con Chrome y VoiceOver con Safari en macOS exponen el árbol de accesibilidad de manera diferente, y una función que se anuncia correctamente en uno puede no hacerlo en otro. Navegue por punto de referencia y por encabezado para confirmar que los roles de su estructura produzcan el esquema esperado, luego navegue por cada widget para verificar la coincidencia de rol, estado y comportamiento del teclado anunciados.

Inspeccione el árbol de Accesibilidad directamente en Chrome o Firefox DevTools, donde el panel “Accesibilidad” muestra la función calculada y el nombre de cualquier elemento. Esto revela la brecha entre el rol que usted escribió y el rol que el navegador realmente expone: la forma más rápida de detectar un rol que es anulado por un padre o ignorado por completo.

Fuentes y lecturas adicionales

• WAI-ARIA — Wikipedia: Iniciativa de Accesibilidad Web – Aplicaciones Ricas de Internet Accesibles (WAI-ARIA) es una especificación técnica publicada por el Consorcio World Wide Web (W3C) que…

Preguntas frecuentes

¿Qué son los roles ARIA y cómo funcionan?

Los roles ARIA son valores en el atributo role que definen la identidad de un elemento en el árbol de accesibilidad, para que los lectores de pantalla lo anuncien correctamente. Sólo cambian la semántica, no la apariencia, el enfoque o el comportamiento del teclado. La especificación WAI-ARIA 1.2 define seis categorías de roles y más de 80 roles concretos, cada uno con estados y propiedades requeridos.

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

Utilice roles ARIA solo cuando ningún elemento HTML nativo proporcione la semántica que necesita. Los elementos nativos como <button>, <nav> y <input type="checkbox"> tienen funciones implícitas además de soporte de teclado integrado y administración de estado. La primera regla del uso de ARIA es preferir la semántica nativa y agregar roles explícitos solo para widgets personalizados o marcas heredadas que no se pueden reestructurar.

¿Cuál es la diferencia entre los roles ARIA y los atributos ARIA?

Los roles ARIA responden “¿qué es este elemento?”, mientras que los atributos ARIA como “aria-expanded”, “aria-checked” y “aria-label” responden “en qué estado se encuentra” o “cómo se llama”. Los roles y sus atributos requeridos trabajan juntos: como ejemplos de roles aria, role="checkbox" está incompleto sin aria-checked, y role="combobox" necesita aria-expanded más un cuadro de lista controlado.

¿Puedo usar roles ARIA en cualquier elemento HTML?

Los roles ARIA se pueden aplicar a la mayoría de los elementos, pero algunas combinaciones no son válidas o son dañinas. Nunca se deben crear funciones abstractas como “widget” y “entrada”. Cambiar la función de un enlace a role="button" rompe el comportamiento esperado del enlace, y role="presentation" en un elemento enfocable elimina su semántica y lo deja en orden de tabulación.

¿Los roles ARIA funcionan sin JavaScript?

La estructura del documento y los roles de punto de referencia funcionan sin JavaScript porque solo modifican la semántica. Los roles de widget como tab, slider y combobox requieren JavaScript para implementar la interacción del teclado y los actualizar los estados; sin él, el elemento se anuncia como un control pero no se comporta como tal, lo cual es peor que HTML simple.

¿Cómo verifico si mis roles ARIA son correctos?

Combine pruebas automatizadas y manuales. Ejecute axe DevTools, WAVE o Lighthouse para detectar roles no válidos y atributos requeridos faltantes, luego pruebe con NVDA, JAWS y VoiceOver para confirmar los anuncios y el comportamiento del teclado. El panel Accesibilidad en Chrome y Firefox DevTools muestra el rol calculado, revelando cualquier rol que el navegador anule o ignore.