¿Qué son los roles ARIA? Una guía práctica para desarrolladores

¿Qué son los roles ARIA? Los roles ARIA son el vocabulario de 87 valores definidos (a partir de WAI-ARIA 1.2) que le dicen a las tecnologías de asistencia qué es un elemento y cómo debe comportarse independientemente de su etiqueta HTML. Un rol como button, navigation o dialog asigna un <div> o <span> genérico a un tipo de widget conocido para que los lectores de pantalla lo anuncien correctamente y expongan las interacciones correctas del teclado.

Por qué existen los roles ARIA

Para comprender qué son los roles de aria, hay que ver que resuelven un problema estructural que HTML por sí solo no puede resolver. Los elementos HTML nativos tienen una semántica implícita: un <button> se anuncia como un botón, se puede enfocar, responde a Enter y a la barra espaciadora, y muestra un estado presionado cuando es necesario.

Cuando los desarrolladores crean widgets personalizados (un cuadro combinado, un panel de pestañas, una vista de árbol), a menudo usan <div> y <span>, que no contienen semántica. Los roles de ARIA cierran esta brecha al permitir a los autores indicar explícitamente el significado faltante.

La especificación WAI-ARIA es mantenida por el Grupo de Trabajo de Aplicaciones Ricas de Internet Accesibles del W3C. La primera versión, ARIA 1.0, se convirtió en Recomendación del W3C en 2014; ARIA 1.1 siguió en 2017 y ARIA 1.2 alcanzó el estado de Recomendación en 2023. Se agregaron funciones, estados y propiedades con cada revisión, y cada uno está vinculado a un documento de prácticas de creación que describe el comportamiento esperado del teclado.

Una distinción clave separa los roles de las otras dos categorías ARIA. Los roles responden: “¿Qué es esto?” Los estados y propiedades responden: “¿En qué condiciones se encuentra?” y “¿Con qué está relacionado?” Un role="checkbox" declara el tipo de widget; aria-checked="true" indica su estado actual. Confundir los dos es una de las causas más comunes de widgets personalizados rotos.

Las seis categorías de roles

Para comprender qué son los roles ARIA, es útil saber que la especificación ARIA agrupa los roles en seis familias. Comprender la familia le permite predecir qué estados y propiedades admite un rol y qué patrones de teclado se aplican.

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

Categoría	Propósito	Funciones representativas
Abstracto	Definiciones de superclase, nunca utilizadas en marcado	widget, entrada, sección
Widget	Controles interactivos	botón, casilla de verificación, control deslizante, pestaña
Estructura del documento	Puntos de referencia y regiones de la página	banner, principal, navegación, región
Punto de referencia	Regiones de páginas navegables (subconjunto de estructura)	banner, complementario, contentinfo, formulario
Región en vivo	Anunciar cambios de contenido dinámico	alerta, estado, registro, temporizador
Ventana	Ventanas del navegador o de la aplicación	diálogo, alertdialog

Los roles abstractos sólo se utilizan para organizar la taxonomía. Los autores nunca deben escribir role="widget" o role="input" en el marcado; esto da como resultado un comportamiento indefinido y la validación falla. Las cinco categorías restantes son las que realmente aplica.

Roles implícitos y la primera regla de ARIA

Cada elemento HTML tiene una función ARIA implícita (que explica qué son los roles aria) definida por la especificación HTML Accessibility API Mapping (AAM). Un elemento <nav> tiene un role="navigation" implícito. Un <ul> tiene un role="list" implícito. Un <h1> a <h6> tiene role="heading". Una <table> tiene role="table".

La primera regla del W3C sobre el uso de ARIA establece claramente: si un elemento o atributo HTML nativo ya transmite la semántica y el comportamiento requeridos, utilícelo en lugar de reutilizar un elemento con ARIA. No es necesario agregar role="button" a <button>. Peor aún, si agrega role="button" a un <div>, obtendrá el anuncio pero ningún comportamiento: sin enfoque, sin activación del teclado, sin envío de formulario.

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

La redundancia no siempre es inofensiva. Anular un rol implícito puede perder la semántica de la que depende la tecnología de asistencia. Escribir role="presentación" en una <tabla> elimina por completo la semántica de las tablas, que a veces es intencional con las tablas de diseño pero desastrosa con las tablas de datos.

Cómo interactúan los roles con los estados y las propiedades

Los roles actúan como contenedores de los estados y propiedades que admiten. La especificación define qué atributos son válidos para qué roles y los navegadores solo exponen combinaciones admitidas en el árbol de accesibilidad.

Comprender qué son los roles de aria ayuda a saber que un role="checkbox" admite aria-checked con los valores true, false o mixed. Un role="slider" admite aria-valuenow, aria-valuemin, aria-valuemax y, opcionalmente, aria-valuetext. Un role="combobox" admite aria-expanded, aria-controls y aria-activedescendant. Aplicar aria-checked a un role="button" no tiene sentido y será ignorado o producirá resultados confusos en algunos lectores de pantalla.

Las propiedades requeridas también son importantes. Un role="checkbox" sin aria-checked no es válido; el estado es obligatorio y no opcional. Un role="slider" sin aria-valuenow deja al usuario incapaz de determinar el valor actual. La especificación ARIA los etiqueta como “estados y propiedades requeridos”, y los verificadores de conformidad como axe-core e IBM Equal Access Accessibility Checker señalan su ausencia.

Roles, árbol de accesibilidad y soporte del navegador

Los navegadores traducen las funciones de ARIA en API de accesibilidad de plataforma (UIA en Windows, AXAPI en macOS, ATK/AT-SPI en Linux) y los lectores de pantalla utilizan estas API. Un rol que ningún navegador asigna correctamente es prácticamente invisible para los usuarios.

El soporte varía según la función y el navegador. Las funciones principales como “Botón”, “Enlace”, “Encabezado”, “Lista” y “Navegación” son universalmente compatibles. Los roles más nuevos o más especializados (“feed”, “matemáticas”, “doc-footnote” del módulo WAI-ARIA de Digital Publishing) tienen un soporte más irregular. El rol=“switch” es compatible con los navegadores modernos, pero se anunció de manera inconsistente hace una década.

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

Sigue siendo esencial realizar pruebas con las combinaciones reales que utiliza su audiencia. Un widget que funciona en NVDA con Firefox puede comportarse de manera diferente en VoiceOver con Safari, porque los dos lectores de pantalla consumen API de plataforma diferentes y aplican heurísticas diferentes.

Roles de punto de referencia y estructura de la página

Los roles de referencia permiten a los usuarios de lectores de pantalla saltar directamente a áreas de una página. Los ocho roles emblemáticos son “banner”, “complementario”, “información de contenido”, “formulario”, “principal”, “navegación”, “región” y “búsqueda”. El HTML moderno tiene equivalentes nativos para la mayoría: <header> se convierte en banner, <footer> se convierte en contentinfo, <main> se convierte en main, <nav> se convierte en navigation, <aside> se convierte en complementary, <form> con un nombre accesible se convierte en form y <section> con un nombre accesible se convierte en region.

Es preferible utilizar elementos nativos porque funcionan incluso si CSS o JavaScript fallan y porque reducen el riesgo de conflictos de roles/atributos. El punto de referencia search no tiene equivalente HTML nativo, por lo que role="search" sigue siendo la opción correcta para la región de búsqueda.

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

Un error común es aplicar role="banner" a un <div> que está dentro de <main> o <article>. Los roles de puntos de referencia solo crean puntos de referencia si no están anidados dentro de otros roles determinados; un “banner” dentro de “principal” no se mostrará como un punto de referencia en absoluto. La ubicación en el DOM es tan importante como el valor del rol. Para aquellos que se preguntan cuáles son los roles de aria, estos puntos de referencia son una parte clave de la especificación.

Roles de región en vivo

Al considerar qué son los roles de aria, los roles regionales en vivo anuncian cambios de contenido sin cambiar el enfoque. Las cuatro funciones de la región en vivo son “alerta”, “estado”, “registro” y “temporizador”, así como la “marquesina” más general. Cada uno lleva implícito un valor “aria-live”: “alerta” y “registro” en la práctica implican “asertivo” y “educado”, respectivamente, mientras que “estado” implica “educado”.

Elegir entre “alerta” y “estado” es una decisión de diseño con consecuencias reales. Una “alerta” detiene lo que esté leyendo el lector de pantalla, lo cual es apropiado para errores y notificaciones urgentes, pero dañino si se usa en exceso. Un status espera una pausa, que coincide con mensajes de progreso y textos de confirmación.

Las regiones activas deben existir en el DOM antes de que cambie el contenido. Insertar un elemento role="alert" y su texto al mismo tiempo a menudo no genera ningún anuncio porque la región no existía en el momento del cambio. El patrón confiable es representar una región activa vacía al cargar la página y actualizar su contenido de texto más tarde.

Cuándo NO utilizar roles ARIA

La segunda regla del uso de ARIA es que los autores no deben cambiar la semántica nativa a menos que realmente lo necesiten. La quinta regla establece que cada elemento interactivo, independientemente de su función, debe ser accesible y enfocable a través del teclado.

Agregar un rol no agrega comportamiento. role="button" en un <div> hace que no se enfoque, no responda a la entrada o la barra espaciadora y no envíe el formulario. Debe agregar tabindex="0", un controlador de pulsaciones de teclas para entrada y espacio y, a menudo, administración de estado “apropiada para el rol”. En este punto, usar un <button> real requiere menos código y menos errores.

Algunos roles son activamente dañinos cuando se aplican mal. role="presentation" y role="none" eliminan la semántica de un elemento y, en algunas implementaciones, de sus descendientes requeridos. La aplicación de role="application" cambia los lectores de pantalla a un modo en el que dejan de interceptar las pulsaciones de teclas, lo que puede atrapar a los usuarios si el manejo personalizado del teclado es incompleto.

Un marco de decisión para elegir roles

Trabajar con una secuencia corta evita la mayoría de los errores de rol de ARIA. Para comprender qué son los roles ARIA y cómo usarlos, siga estos pasos:

1. Identifique el widget o la región. Nombra lo que realmente es el elemento en lenguaje sencillo.
2. Busque un equivalente HTML nativo. Consulte la asignación HTML-AAM. Si <button>, <select>, <details> o <dialog> encajan, úselo.
3. Si ningún elemento nativo encaja, seleccione la función ARIA más cercana. Verifique que exista en la especificación actual y que no sea abstracta.
4. Agregue estados y propiedades requeridos. Verifique la definición del rol para conocer los atributos obligatorios.
5. Implemente el patrón de interacción del teclado. Siga la Guía de prácticas de creación de WAI-ARIA para el tipo de widget.
6. Pruebe con al menos dos combinaciones de lector de pantalla y navegador. Verifique los anuncios, los estados y el flujo del teclado.

En los pasos del tres al seis es donde ocurren la mayoría de los errores de widgets personalizados. Saltarse el patrón del teclado en el paso cinco crea un widget que se anuncia correctamente pero no funciona, lo que podría decirse que es peor que no tener ningún ARIA.

Herramientas de prueba y validación

Las herramientas automatizadas detectan errores estructurales: valores de roles no válidos, propiedades requeridas faltantes y roles aplicados a elementos que no los admiten. axe-core, el motor detrás de muchas extensiones de navegador, verifica un subconjunto definido de reglas ARIA. El Comprobador de accesibilidad de IBM Equal Access y el propio Nu HTML Checker del W3C también muestran abuso de roles.

Las herramientas automatizadas no pueden verificar si una función produce el anuncio correcto o si la interacción del teclado funciona. Aún se requieren pruebas manuales con NVDA y Firefox, JAWS y Chrome, o VoiceOver y Safari. La extensión Accessibility Insights for Web combina comprobaciones automatizadas con una evaluación manual guiada que incluye verificación con teclado y lector de pantalla.

La especificación ARIA en sí, la Guía de prácticas de creación de WAI-ARIA y el documento de mapeo HTML-AAM son las referencias autorizadas para lo que son los roles de aria. La referencia ARIA de MDN Web Docs es una fuente secundaria conveniente y bien seleccionada que hace referencia a la especificación de cada función.

Conclusiones clave

• Los roles ARIA declaran qué es un elemento; WAI-ARIA 1.2 define 87 roles en seis categorías y es posible que los roles abstractos nunca aparezcan en el marcado.
• Los elementos HTML nativos tienen roles implícitos y comportamientos integrados, por lo que la primera regla al usar ARIA es preferirlos a div más role.
• Los roles requieren sus estados y propiedades admitidos: un role="checkbox" sin aria-checked no es válido y no se puede utilizar.
• Agregar un rol nunca agrega comportamiento del teclado ni capacidad de enfoque; estos deben implementarse y probarse por separado.
• Los roles de punto de referencia y de región en vivo tienen reglas de ubicación y tiempo que determinan si funcionan o no.
• Los inspectores automatizados sólo detectan errores estructurales; aún es necesario probar los lectores de pantalla para diferentes combinaciones de navegadores.

Para comprender cuáles son los roles ARIA, recuerde que definen el propósito de un elemento de tecnología de asistencia.

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 en términos simples?

Los roles ARIA son etiquetas que se adjuntan a elementos HTML para indicarle a la tecnología de asistencia qué representa el elemento. Un <div role="button"> se anuncia como un botón en lugar de como un texto genérico. Los roles proporcionan un significado que la etiqueta subyacente no proporciona, pero no añaden ningún comportamiento, manejo de enfoque o soporte de teclado por sí solos.

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

Los roles describen el tipo de un elemento, mientras que los atributos describen su estado, valor o relaciones. role="slider" identifica un control deslizante; aria-valuenow="50" informa su posición actual y aria-labelledby apunta a su etiqueta. Los roles y atributos se utilizan juntos y cada rol define qué atributos admite.

¿Cuántos roles ARIA hay?

WAI-ARIA 1.2 define 87 roles agrupados en seis categorías: abstractos, widget, estructura de documento, landmark, región activa y ventana. Los roles abstractos como “widget” y “entrada” existen solo para la taxonomía interna de la especificación y nunca deben escribirse en HTML. El número crece con cada revisión de especificaciones.

¿Debería utilizar roles ARIA en lugar de HTML semántico?

No. La primera regla del uso de ARIA dice que se prefiera un elemento HTML nativo siempre que exista uno con la semántica y el comportamiento requeridos. Utilice <button> en lugar de <div role="button">, y <nav> en lugar de <div role="navigation">. Los roles ARIA son una alternativa para los casos en los que no existe un elemento nativo adecuado.

¿Los roles ARIA funcionan en todos los navegadores y lectores de pantalla?

Los roles principales como button, link, heading y navigation son compatibles de manera confiable con los navegadores y lectores de pantalla modernos. Los roles más nuevos o más especializados, incluidos los del módulo de Publicación digital, brindan un soporte más variable. Sólo probando con las combinaciones específicas de navegador y lector de pantalla que utiliza su audiencia podrá estar seguro.

¿Agregar un rol ARIA puede romper la accesibilidad?

Sí. Anular un rol implícito puede perder semántica útil, como cuando se aplica role="presentation" a una tabla de datos. La aplicación de role="application" puede bloquear a los usuarios si el manejo del teclado personalizado está incompleto. Los roles redundantes en elementos nativos crean ruido innecesario y, en ocasiones, dan lugar a anuncios contradictorios.