ARIA (Accessible Rich Internet Applications) sirve para tapar los agujeros de accesibilidad que deja el JavaScript cuando construye interfaces que HTML no cubre por sí solo: pestañas, modales, autocompletados, menús desplegables. El problema es que muchos equipos lo usan al revés, añadiendo atributos ARIA a elementos que ya eran accesibles de fábrica, y el resultado es justo lo contrario de lo que buscaban: una interfaz más confusa para quien navega con lector de pantalla.
Qué es ARIA y cuándo entra en juego
ARIA es una especificación del W3C pensada para aplicaciones web interactivas que HTML por sí solo no puede describir del todo. Piensa en un desplegable construido a base de div y JavaScript, o en un modal que aparece sobre el contenido: el navegador no sabe, por defecto, qué papel juega cada pieza ni cuándo cambia su estado. Ahí es donde ARIA aporta la información que falta.
Bien aplicado, describe el comportamiento y el estado de la interfaz para quien usa un lector de pantalla. Mal aplicado, pisa la semántica nativa del HTML y deja al usuario con información contradictoria: un botón que el navegador anuncia como botón, pero que un role mal puesto hace pasar por otra cosa.
El HTML semántico ya hace la mitad del trabajo
Antes de tocar un solo atributo ARIA conviene recordar que HTML trae accesibilidad de serie. Etiquetas como <header>, <nav>, <main>, <section> o <footer> ya organizan la página para las tecnologías de asistencia, y elementos de formulario como <button>, <input>, <a> o <select> nacen accesibles sin que tengas que añadir nada.
La primera regla de ARIA, la que suele saltarse todo el mundo, es no usarlo donde no hace falta. Un <button> ya se percibe como botón en cualquier lector de pantalla, así que ponerle role="button" no aporta nada y solo añade ruido al código.
Los atributos que sí merecen la pena
ARIA gana sentido cuando el HTML nativo no llega, casos típicos de interfaces dinámicas construidas con JavaScript. Estos son los que más juego dan:
- role: define qué es un elemento cuando el HTML no lo deja claro, como
role="dialog"para marcar un cuadro de diálogo. - aria-label: da una etiqueta accesible cuando no hay texto visible, típico en botones o enlaces que solo llevan un icono.
- aria-hidden: oculta a las tecnologías de asistencia elementos puramente decorativos, sin que desaparezcan de la vista.
- aria-live: avisa al lector de pantalla cuando cambia contenido dinámico, como una notificación que aparece sin recargar la página.
Cuándo dejarlo tal cual está
Si un elemento ya es semánticamente correcto, no le añadas nada. Un enlace <a> bien usado no necesita role="link", porque el navegador ya lo anuncia como enlace sin ayuda extra. Meter ARIA encima de HTML que ya funciona no mejora nada, solo suma código que mantener y, en el peor caso, contradice lo que el navegador ya está comunicando por su cuenta.
Cómo integrarlo sin romper nada
Empieza siempre por un HTML bien estructurado. Con esa base, ARIA entra solo donde el HTML no llega, nunca como sustituto de una etiqueta que ya hace su trabajo. Si necesitas anunciar un cambio generado por JavaScript, usa aria-live, pero no cambies un botón nativo por un div con role="button" solo porque te resulta más cómodo de estilizar.
Una vez implementados los atributos, tócalos con herramientas reales antes de dar el trabajo por cerrado: lectores de pantalla como NVDA, JAWS o VoiceOver, y auditorías automáticas con Lighthouse. Navega también solo con el teclado, sin ratón, porque muchos fallos de ARIA solo se notan cuando intentas moverte por la página así.
Los errores que más se repiten
El más común es meter ARIA por todas partes sin necesidad, lo que complica la interfaz en vez de aclararla. También pasa que se añaden atributos sin pensar en cómo los interpreta cada lector de pantalla, y el resultado varía según la tecnología del usuario. Y hay un tercero, más silencioso: declarar un estado con ARIA y olvidarse de actualizarlo cuando cambia, de forma que el atributo queda diciendo una cosa mientras la pantalla muestra otra.
ARIA es una herramienta potente, pero solo cuando se usa donde hace falta. La regla que de verdad importa es sencilla: apóyate en el HTML semántico primero y recurre a ARIA solo para tapar lo que el HTML no puede resolver por sí mismo. Con esa base y unas pruebas serias con tecnologías de asistencia reales, ARIA deja de ser un riesgo y se convierte en la pieza que faltaba para que tu web funcione igual de bien con lector de pantalla que sin él.
Si quieres profundizar en accesibilidad más allá de ARIA, en accesibilidad web en la era de los asistentes conversacionales y navegación por voz tratamos cómo afecta la navegación por voz al diseño de interfaces. Y si lo que te interesa es cómo estructurar el HTML pensando también en los rastreadores de IA, échale un vistazo a cómo estructurar el contenido de tu sitio para que los rastreadores de IA lo entiendan.
Preguntas frecuentes
¿ARIA sustituye al HTML semántico?
No, y ese es precisamente el error más frecuente. ARIA complementa al HTML cuando este no basta, pero nunca debe reemplazar una etiqueta nativa que ya cumple su función.
¿Puedo usar ARIA en un botón normal?
No hace falta. Un <button> ya se anuncia como botón en cualquier lector de pantalla sin necesidad de role="button" ni ningún otro atributo adicional.
¿Qué pasa si abuso de los atributos ARIA?
La interfaz se vuelve más difícil de interpretar para las tecnologías de asistencia, justo lo contrario de lo que se busca. El exceso de ARIA es tan problemático como su ausencia.
¿Cómo compruebo que mi implementación de ARIA funciona bien?
Prueba con lectores de pantalla reales como NVDA, JAWS o VoiceOver, audita con Lighthouse y navega toda la página solo con teclado para detectar fallos que a simple vista pasan desapercibidos.
