¿Qué son los atributos ARIA? WAI-ARIA explicado de forma sencilla

ARIA significa Accessible Rich Internet Applications. Es un conjunto de atributos HTML, estandarizado por el W3C como WAI-ARIA (versión actual 1.2, publicada en junio de 2023), que aporta a las tecnologías de apoyo, como los lectores de pantalla, información adicional sobre los elementos de la interfaz. ARIA se vuelve necesario allí donde termina la semántica del HTML nativo: una interfaz de pestañas, un acordeón, un desplegable a medida o un mensaje de estado que aparece de forma dinámica. El vocabulario consta de tres piezas: los roles describen qué es un elemento, los estados describen su condición actual y las propiedades describen características y relaciones. ARIA es potente y peligroso a partes iguales. Bien usado, hace que los widgets complejos sean utilizables por quienes navegan con lector de pantalla; mal usado, rompe activamente la accesibilidad, y por eso la regla más importante de ARIA es preferir los elementos HTML nativos siempre que puedan hacer el trabajo.

¿Qué significa ARIA y por qué existe?

El HTML tiene una semántica integrada muy rica: un button se anuncia como botón, un nav es una navegación, una casilla marcada informa por sí sola de su estado. Los lectores de pantalla leen todo esto del árbol de accesibilidad que el navegador construye a partir de tu marcado. El problema empieza con todo aquello para lo que el HTML no tiene elemento. No existe un panel de pestañas nativo, ni un acordeón, ni una notificación emergente. Quienes desarrollan construyen esas cosas con divs y spans, y para una persona que usa lector de pantalla un acordeón hecho de divs es puro silencio: sin nombre, sin rol, sin estado.

WAI-ARIA llena exactamente ese hueco. Te permite decirle a la tecnología de apoyo qué es tu widget a medida y qué está haciendo, sin cambiar nada en el aspecto ni en el comportamiento de la página para el resto de las personas.

Roles, estados y propiedades: las tres piezas de ARIA

• Los roles definen qué es un elemento. role="dialog", role="tablist", role="alert". Un rol es una promesa hecha a la persona usuaria: esto se va a comportar como un diálogo.
• Los estados describen la condición actual y cambiante de un elemento. aria-expanded="true", aria-checked="false", aria-disabled="true". Los estados cambian mientras la persona interactúa, y tu JavaScript debe mantenerlos sincronizados.
• Las propiedades describen características y relaciones que rara vez cambian. aria-labelledby apunta al elemento que da nombre a este, aria-controls apunta al elemento que este maneja, aria-required marca un campo obligatorio.

La distinción entre estados y propiedades es académica en el día a día: ambos son simplemente atributos. El modelo mental que importa es este: el rol dice qué es, y todo lo demás dice cómo se llama, qué está haciendo y a qué pertenece.

La primera regla de ARIA: no uses ARIA

El documento del W3C Using ARIA abre con una regla que suena a broma pero va totalmente en serio: si ya existe un elemento HTML nativo con la semántica y el comportamiento que necesitas, úsalo en lugar de reconvertir otro elemento y añadirle ARIA. Compara estas dos formas de construir un botón:

<!-- Parece un botón para quien ve, es un div muerto para el resto -->
<div class="btn" onclick="save()">Save</div>

<!-- Todo incluido: rol, soporte de teclado, foco -->
<button type="button" onclick="save()">Save</button>

Para arreglar la versión con div necesitarías role="button", tabindex="0" y JavaScript adicional para Enter y Espacio. El elemento nativo hace todo eso gratis y seguirá haciéndolo en navegadores que nunca has probado. La misma lógica se aplica a enlaces, casillas, campos de formulario y encabezados.

Detrás de esta regla hay un dato que da que pensar. WebAIM analiza cada año el millón de páginas de inicio más visitadas, y sus informes encuentran de forma constante que las páginas que usan ARIA tienen de media más errores de accesibilidad detectados que las que no lo usan. No es porque ARIA sea malo, sino porque se aplica mal con muchísima frecuencia. Nada de ARIA es mejor que ARIA roto.

Los atributos ARIA más importantes explicados

• aria-label: da directamente a un elemento su nombre accesible. El caso de uso clásico es un botón que solo tiene icono: aria-label="Close" en la X de una ventana modal.
• aria-labelledby: apunta al ID de otro elemento cuyo texto visible se convierte en el nombre. Se prefiere a aria-label cuando existe una etiqueta visible, porque así los dos no pueden desincronizarse.
• aria-describedby: apunta a un texto descriptivo adicional, normalmente una indicación o un mensaje de error bajo un campo de formulario.
• aria-hidden="true": elimina un elemento y sus descendientes del árbol de accesibilidad. Correcto para iconos decorativos, peligroso sobre cualquier cosa enfocable.
• aria-expanded: indica en el disparador si el área controlada está abierta o cerrada. Es la columna vertebral de acordeones, menús desplegables y navegación móvil.
• aria-controls: conecta un disparador con el elemento que maneja.
• aria-live: convierte un elemento en una región en vivo cuyos cambios de contenido se anuncian automáticamente. polite espera a una pausa, assertive interrumpe de inmediato y debería reservarse para mensajes realmente urgentes.
• aria-current: marca el elemento actual dentro de un conjunto, por ejemplo aria-current="page" en el enlace de navegación activo.
• aria-required y aria-invalid: comunican los campos obligatorios y los fallos de validación en los formularios. Con la validación nativa de HTML, required por sí solo ya cubre la primera parte.

¿Qué son los roles de landmark de ARIA?

Los landmarks dividen una página en regiones con nombre entre las que quienes usan lector de pantalla pueden saltar directamente, igual que quien ve recorre visualmente un diseño. La buena noticia: los elementos HTML modernos crean la mayoría de los landmarks de forma implícita, así que en un documento bien estructurado rara vez escribirás estos roles a mano.

• header se corresponde con el landmark banner
• nav se corresponde con navigation
• main se corresponde con main, y debería haber exactamente uno por página
• aside se corresponde con complementary
• footer se corresponde con contentinfo
• form y section se convierten en los landmarks form y region cuando tienen un nombre accesible

Una costumbre que merece la pena adoptar: si una página tiene dos navegaciones, distínguelas con aria-label="Main menu" y aria-label="Footer menu". Oír navegación dos veces sin ninguna distinción no ayuda a nadie.

Ejemplos prácticos de ARIA: acordeón y región en vivo

La cabecera mínima de un acordeón accesible muestra cómo encajan las piezas. El botón lleva el estado, el panel se referencia por ID y JavaScript cambia ambos al hacer clic:

<h3>
  <button aria-expanded="false" aria-controls="panel-shipping">
    Shipping and returns
  </button>
</h3>
<div id="panel-shipping" hidden>
  <p>We ship within 2 to 4 business days...</p>
</div>

Y una región en vivo para el feedback que aparece sin recargar la página, por ejemplo tras añadir un producto al carrito o tras una búsqueda filtrada:

<div aria-live="polite" class="visually-hidden" id="status"></div>

<script>
  document.getElementById('status').textContent = '12 products found'
</script>

Sin la región en vivo, alguien que usa lector de pantalla filtra una lista de productos y no oye absolutamente nada. Con ella, el número de resultados se anuncia en el momento en que cambia. Atributo pequeño, gran diferencia.

Errores habituales con ARIA que conviene evitar

• aria-hidden="true" en elementos enfocables: el elemento desaparece del árbol de accesibilidad pero permanece en el orden de tabulación. Quien navega con teclado aterriza en un fantasma. Es uno de los errores de ARIA más frecuentes que se ven por ahí.
• Roles redundantes: role="button" en un button o role="navigation" en un nav añade ruido y demuestra que no se entendió el marcado.
• Roles sin comportamiento: role="tab" promete navegación con las teclas de flecha. Si tu JavaScript no la ofrece, el rol empeora las cosas respecto a no ponerlo, porque genera expectativas que el widget no puede cumplir.
• Estados desactualizados: un aria-expanded que se queda en false para siempre porque nadie lo actualiza en el manejador del clic. Quien usa lector de pantalla oye contraído mientras mira un panel abierto.
• aria-label en elementos de texto plano: en un div o un span sin rol, la mayoría de las tecnologías de apoyo ignoran aria-label. No es un tooltip de propósito general.
• Abusar de las regiones en vivo assertive: si cada actualización del carrito, cada aviso de cookies y cada caja de newsletter interrumpen a la persona usuaria, los anuncios verdaderamente importantes se ahogan.

ARIA en temas y plugins de WordPress

El núcleo de WordPress está en un estado decente: el bloque de navegación gestiona aria-expanded en los conmutadores de submenú, la clase CSS screen-reader-text para etiquetas ocultas visualmente es una convención de toda la vida y los componentes de formulario del núcleo vienen con atributos sensatos. El problema suele llegar con lo que se instala encima. Los constructores de páginas, los plugins de carrusel, los megamenús y las herramientas de ventanas emergentes son los sitios donde se acumula la sopa de divs con ARIA ausente o roto. Cuando evalúes un tema, la etiqueta accessibility-ready del directorio de temas de WordPress es una señal genuina, ya que esos temas pasan por una revisión frente a criterios definidos. Para todo lo demás, la ARIA Authoring Practices Guide documenta patrones probados para casi cualquier widget que vayas a construir, con el comportamiento de teclado ya resuelto.

¿Cómo comprueba InspectWP el uso de ARIA?

InspectWP examina tus páginas renderizadas como parte de su análisis de accesibilidad y señala los problemas relacionados con ARIA que las herramientas automáticas pueden detectar de forma fiable: nombres de rol no válidos, atributos ARIA que no están permitidos en el elemento donde se encuentran, referencias a ID que no existen, elementos enfocables ocultos con aria-hidden y elementos interactivos sin nombre accesible. Los hallazgos se agrupan por gravedad, de modo que un nombre roto en tu navegación principal pesa más que un rol redundante en el pie de página. Como al final es el comportamiento del lector de pantalla lo que decide qué funciona, trata el informe como tu primera pasada rápida y repetible, y verifica después los flujos críticos con un lector de pantalla real.