WAI-ARIA: Desde los Fundamentos Hasta un Uso Avanzado

WAI-ARIA: Desde los Fundamentos Hasta un Uso Avanzado

Introducción

Las páginas Web nos ofrecen experiencias cada vez más ricas e interactivas. Sin embargo, esta evolución ha generado barreras para personas que utilizan tecnologías de asistencia. Es aquí donde entra WAI-ARIA (Accessible Rich Internet Applications), una especificación del W3C creada para mejorar la accesibilidad de contenidos dinámicos y componentes de interfaz desarrollados con HTML, JavaScript y tecnologías similares.

Con este artículo pretendo explorar WAI-ARIA desde su propósito más fundamental hasta su aplicación avanzada, desmitificando su uso e ilustrando cómo puede marcar la diferencia en la inclusión digital.

¿Qué es WAI-ARIA?

WAI-ARIA es parte del trabajo de la Web Accessibility Initiative (WAI) del W3C. Fue diseñada para abordar las limitaciones de HTML en la descripción de roles, estados y propiedades de elementos de interfaz complejos como menús, pestañas, sliders, acordeones o aplicaciones tipo SPA (Single Page Application).

Objetivo principal

El principal objetivo de WAI-ARIA es permitir que usuarios de tecnologías de asistencia (como lectores de pantalla) comprendan la función, el estado y las interacciones posibles de los componentes de la interfaz, aunque estos no estén construidos con elementos semánticos nativos de HTML.

Principios básicos de WAI-ARIA

WAI-ARIA se basa en tres tipos de atributos principales:

• Roles: Describen qué es un elemento (botón, pestaña, alerta).
• States (Estados): Indican condiciones que cambian con el tiempo (como aria-expanded o aria-checked).
• Properties (Propiedades): Proveen información sobre características del elemento (como aria-labelledby, aria-describedby).

Ejemplo básico:

<div role="button" tabindex="0" aria-pressed="false">
  Activar modo oscuro
</div>

Buenas prácticas: la regla de oro de ARIA

«No uses ARIA si puedes hacerlo con HTML nativo.»
– W3C WAI-ARIA Authoring Practices

HTML5 ya incluye muchos elementos semánticos (<button>, <nav>, <header>, etc.) que proporcionan accesibilidad «de fábrica». Usar WAI-ARIA innecesariamente puede complicar la accesibilidad o incluso romperla.

Ejemplo correcto (sin ARIA):

<button onclick="activarModo()">Activar modo oscuro</button>

Ejemplo incorrecto (innecesario uso de ARIA):

<div role="button" onclick="activarModo()" tabindex="0">
  Activar modo oscuro
</div>

Problema: Aunque este div se comporta visualmente como un botón, los usuarios de lectores de pantalla no obtendrán la misma experiencia que con un botón real, ya que no se activa con Enter o Espacio automáticamente, y no tiene la semántica de botón incorporada. Se requiere programación adicional para hacerlo accesible.

Roles comunes en WAI-ARIA

Rol	Propósito
button	Elemento clicable
dialog	Ventana modal
alert	Mensaje importante que interrumpe
tablist	Contenedor de pestañas
tabpanel	Panel asociado a una pestaña
navigation	Zona de navegación

Estados y propiedades clave

Atributo	Descripción
aria-disabled	Indica que un elemento está inactivo
aria-hidden	Oculta el elemento de las tecnologías asistivas
aria-expanded	Muestra si un elemento está expandido o colapsado
aria-checked	Estado de un checkbox o radio
aria-label	Etiqueta textual para un elemento
aria-labelledby	Referencia a otro ID como etiqueta
aria-describedby	Referencia a contenido que describe el elemento

Ejemplo combinado:

<div role="switch" aria-checked="false" tabindex="0" aria-labelledby="etiqueta">
  <span id="etiqueta">Activar notificaciones</span>
</div>

Ejemplos prácticos: uso correcto e incorrecto

Acordeón accesible (Correcto)

<button aria-expanded="false" aria-controls="contenido1" id="encabezado1">
  Mostrar detalles
</button>
<div id="contenido1" role="region" aria-labelledby="encabezado1" hidden>
  Detalles del producto...
</div>

Acordeón inaccesible (Incorrecto)

<div onclick="toggle()" class="acordeon">Mostrar detalles</div>
<div class="contenido">Detalles del producto...</div>

Problema: Este acordeón no tiene un control de foco accesible (no se puede acceder con teclado), no comunica su estado (expandido o colapsado), y no hay relación semántica entre el control y el contenido. Los usuarios con lectores de pantalla o sin ratón no podrán usarlo correctamente.

ARIA Live Regions

Las live regions permiten anunciar cambios de contenido automáticamente, como mensajes de error o actualizaciones dinámicas.

<div aria-live="polite">
  ¡Producto agregado al carrito!
</div>

Tipos:

• aria-live="off": no anunciar.
• aria-live="polite": anunciar cuando haya tiempo.
• aria-live="assertive": anunciar de inmediato (interrumpe al lector).

Pautas para implementar ARIA correctamente

• Validar con herramientas: como el WAVE tool, axe-core o el validador del W3C.
• Testear con tecnologías de asistencia: como NVDA, JAWS, VoiceOver.
• Evitar el uso excesivo de ARIA: si un elemento nativo ya cubre la necesidad. (esta debería estar toda en negrita, jajaja)
• Mantener sincronía visual-auditiva: que lo que se ve también se anuncie.
• Combinar con buenas prácticas de desarrollo accesible: foco, contraste, tamaño de fuente, etc.

Patrones ARIA recomendados por el W3C

El W3C proporciona una guía llamada ARIA Authoring Practices Guide (APG) con patrones accesibles listos para usar: menús, tabs, acordeones, sliders, tooltips, etc. Y si nos lo ofrece alguien que sabe más que yo, prefiero enviaros a la fuente: Patrones ARIA recomendados por el W3C

Avanzando: WAI-ARIA y JavaScript

ARIA muestra su mayor potencia en combinación con JavaScript, donde el comportamiento dinámico de la interfaz no puede lograrse con HTML puro.

Ejemplo: cuando una acción con JavaScript cambia el contenido de una tarjeta, puedes usar aria-live, aria-expanded, aria-hidden y otros atributos para notificar el cambio.

Relación entre WAI-ARIA y las pautas WCAG

WAI-ARIA tiene una relación directa con los principios de las Pautas de Accesibilidad para el Contenido Web (WCAG), las «wachas» para los amigos, creo que además, este punto es uno de los que nos puede resultar más útil a la hora de tener claro para que sirve la cosa esta del WAI-ARIA.

Estas pautas se agrupan en torno a cuatro principios fundamentales:

1. Perceptible: la información y los componentes deben presentarse de manera que los usuarios puedan percibirlos. ARIA contribuye aquí con atributos como aria-label, aria-describedby, y aria-hidden, que permiten que la información sea anunciada correctamente por tecnologías de asistencia.
2. Operable: los componentes de la interfaz deben ser utilizables por todos. WAI-ARIA permite crear componentes interactivos personalizados (como menús, pestañas, acordeones) que sean completamente accesibles por teclado y lectores de pantalla mediante role, aria-expanded, aria-pressed, entre otros.
3. Comprensible: la información debe ser clara, y la interfaz debe comportarse de manera predecible. A través de atributos como aria-invalid, aria-required, o aria-live, se pueden comunicar estados de error y validación de forma que sean comprensibles para todos los usuarios.
4. Robusto: el contenido debe ser lo suficientemente robusto como para ser interpretado de forma fiable por una amplia variedad de tecnologías de asistencia. WAI-ARIA permite agregar semántica que puede ser interpretada incluso en entornos donde los elementos HTML nativos no son suficientes.

En definitiva, aplicar correctamente WAI-ARIA es una de las formas más efectivas de cumplir con WCAG 2.1 en entornos dinámicos y complejos.

Conclusión

WAI-ARIA es una herramienta poderosa (y valiente…. ) para hacer la Web verdaderamente universal, pero debe usarse con cuidado. Empezar con lo básico y progresar hacia patrones avanzados, siempre priorizando la semántica nativa de HTML, es el camino correcto.

El futuro de la accesibilidad no depende sólo de la tecnología, sino de decisiones conscientes durante el diseño y desarrollo. WAI-ARIA, bien aplicado, es una de esas decisiones.

Lo digo siempre, escribo sobre lo que leo, lo que aprendo o sobre lo que me gustaría saber más y una de esas cosas de las que me gustaría saber mucho más es sobre el tema WAI-ARIA , así que espero que este post que a lo mejor tienen un título un poco clickbait, (aunque os aseguro que no ha sido la intención) os resulte interesante y que no me «haya colao» y metido la pata en alguna de mis afirmaciones, pero para eso están los comentarios, para que me dejéis comentarios.

Por cierto, lo de empezar directamente con el contenido y la parte de reflexión y justificación al final ha sido porque he leído un libro que decía que a la gente le interesa más que primero vaya al turrón y luego ya si eso divago, así que ahí va mi primera prueba así.