Qué es ARIA, las cinco reglas y «no ARIA es mejor que mal ARIA»

WAI-ARIA (se abre en una ventana nueva) (Accessible Rich Internet Applications) es una especificación del W3C que define un conjunto de atributos HTML (role y los que empiezan por aria-) para comunicar a las tecnologías de apoyo el significado, el estado y las relaciones de los elementos de una interfaz. La versión vigente es WAI-ARIA 1.2 (recomendación de junio de 2023), acompañada de la ARIA Authoring Practices Guide (se abre en una ventana nueva) (APG), que describe cómo implementar patrones concretos (pestañas, menús, diálogos…), y de la especificación del cálculo del nombre accesible. En esta lección fijamos qué hace ARIA, qué no hace y las reglas que evitan los desastres.

Qué hace ARIA y qué no

ARIA actúa exclusivamente sobre el árbol de accesibilidad. Cuando añades role="button" a un <div>, el lector de pantalla anunciará «botón», pero el <div> sigue sin recibir el foco, sin responder a Intro ni Espacio y sin participar en el formulario. ARIA es una promesa que le haces a la persona usuaria: «esto se comporta como un botón». Si no cumples la promesa con JavaScript y tabindex, el resultado es peor que si no hubieras dicho nada, porque la persona intentará usarlo y no funcionará.

En resumen, ARIA:

• Sí cambia o añade el rol, el nombre, la descripción, los estados y las propiedades que las tecnologías de apoyo perciben.
• Sí permite anunciar cambios dinámicos (regiones activas) y expresar relaciones (controla a, etiquetado por, descrito por).
• No añade comportamiento: ni foco, ni teclado, ni validación, ni envío.
• No cambia el aspecto visual ni afecta a los usuarios sin tecnología de apoyo.
• No arregla HTML mal estructurado; lo maquilla.

Las cinco reglas de uso de ARIA

El documento Using ARIA del W3C resume el uso correcto en cinco reglas que conviene saber de memoria.

Regla 1: si existe un elemento HTML nativo, úsalo

Si puedes usar <button>, <a href>, <input type="checkbox">, <nav>, <dialog> o <details>, no construyas el equivalente con <div> y ARIA. El elemento nativo trae el rol, el comportamiento y el soporte de todos los navegadores. Las excepciones legítimas son muy pocas: que la funcionalidad no exista en HTML (pestañas, árbol, rejilla editable), que el elemento nativo no se pueda estilizar como exige el diseño y se haya comprobado que no hay alternativa, o que el soporte de accesibilidad del elemento nativo sea deficiente en los navegadores objetivo.

Regla 2: no cambies la semántica nativa salvo que sea imprescindible

<h2 role="tab">Horarios</h2>
<a href="#" role="button">Enviar</a>
<ul role="navigation">…</ul>

Regla 3: todo control ARIA interactivo debe ser operable con teclado

Si pones role="button", role="tab", role="menuitem" o cualquier otro rol de widget, estás obligado a implementar el teclado que la APG describe para ese patrón: foco con tabindex, activación con Intro y Espacio, flechas si el patrón las usa. El rol sin el teclado es la peor combinación posible.

Regla 4: no uses role="presentation" ni aria-hidden="true" en elementos enfocables

Un elemento que puede recibir el foco pero está oculto al árbol de accesibilidad produce una parada «fantasma»: la persona pulsa Tab, el foco llega a algo y el lector no dice nada. Antes de ocultar un elemento con aria-hidden, asegúrate de que ni él ni sus descendientes son enfocables; si lo son, quítalos del orden con tabindex="-1", con inert o con display:none.

Regla 5: todo elemento interactivo debe tener un nombre accesible

Lo vimos en el curso de HTML: sin nombre, el lector anuncia «botón» o «enlace» a secas. Con ARIA esto afecta sobre todo a los iconos y a los roles de widget: role="button" en un <div> con un icono dentro necesita aria-label o aria-labelledby.

Cuándo sí usar ARIA

ARIA es imprescindible en estos casos:

• Patrones sin equivalente HTML: pestañas (tablist, tab, tabpanel), árboles, rejillas, menús de aplicación, combobox personalizados, deslizadores de dos valores.
• Estados que HTML no puede expresar: aria-expanded en un botón que despliega un panel, aria-pressed en un botón conmutador, aria-current="page" en el enlace de la página actual, aria-selected en una pestaña, aria-sort en una columna ordenable.
• Relaciones que HTML no cubre: aria-describedby, aria-controls, aria-labelledby entre elementos no asociables de otro modo.
• Anuncios de cambios dinámicos sin mover el foco: aria-live, role="status", role="alert".
• Nombrar landmarks repetidos y regiones genéricas.

<button type="button" aria-expanded="false" aria-controls="filtros">
  Filtrar resultados
</button>
<div id="filtros" hidden>…</div>

Soporte real

Que un atributo exista en la especificación no garantiza que todas las combinaciones de navegador y lector de pantalla lo anuncien igual. Antes de depender de un atributo poco común (aria-roledescription, aria-details, aria-errormessage), compruébalo en los pares más usados en España: NVDA y JAWS con Chrome o Firefox, VoiceOver con Safari, TalkBack con Chrome. La web a11ysupport.io y las notas de la propia APG documentan el soporte conocido. Cuando el soporte sea dudoso, ofrece una alternativa (texto visible, aria-describedby en lugar de aria-errormessage).

Resumen

• ARIA modifica solo el árbol de accesibilidad: aporta rol, nombre, estado y relaciones, pero ningún comportamiento.
• Regla 1: usa HTML nativo siempre que exista; regla 2: no destruyas la semántica nativa; regla 3: todo widget ARIA necesita teclado; regla 4: nada enfocable puede estar oculto al árbol; regla 5: todo interactivo necesita nombre.
• ARIA es imprescindible para patrones sin equivalente HTML, para estados como aria-expanded y para anunciar cambios dinámicos.
• Más ARIA no significa más accesibilidad; comprueba cada atributo con lectores de pantalla reales.