Cuándo usar ARIA: la primera regla es no usarlo

¿Qué hace ARIA en realidad?

ARIA es un sistema de etiquetado, no un sistema de estilo ni un sistema de comportamiento. Todo su trabajo es decirle a la tecnología de asistencia qué es un elemento — un botón, una casilla, un diálogo, una región de navegación — cuando la etiqueta HTML de fondo no lo dice ya (Greadme, 2026). De forma crucial, solo añade información al árbol de accesibilidad; no añade comportamiento, lo que significa que un rol ARIA no trae ni soporte de teclado, ni manejo de foco, ni actualizaciones de estado propias (WebAbility, 2026).

Esa distinción es la clave para usarlo bien. ARIA se entiende mejor como un mecanismo de reparación — arregla lo que HTML todavía no puede expresar, en vez de actuar como un atajo para marcado que no quisiste escribir (RatedWithAI, 2026). Los elementos HTML nativos, en cambio, cargan su semántica ARIA de forma implícita y gratis: un <button> ya está expuesto al árbol de accesibilidad como botón, ya es enfocable por teclado, ya se dispara con Enter y Espacio, y ya anuncia su etiqueta (Accsible, 2026). En el momento en que escribes <div role="button">, asumes la tarea de recrear todo eso tú mismo.

¿Por qué “no ARIA es mejor que ARIA malo”?

Porque los datos muestran que ARIA se usa mal más seguido de lo que se usa bien. En el análisis de WebAIM del millón de páginas de inicio más visitadas, las páginas con ARIA presente promediaron un 41% más de errores de accesibilidad detectados que las páginas sin ningún ARIA (MDN, 2026). Eso no es un argumento contra ARIA — es un argumento para usarlo bien, y una advertencia de lo fácil que es no hacerlo.

La razón por la que el ARIA malo es tan dañino es que un control mal etiquetado es peor que uno sin etiquetar. Usar mal ARIA produce una experiencia más inaccesible que no usar ninguno, porque a un usuario de lector de pantalla se le dice de forma activa algo equivocado sobre qué es o qué hace un elemento (Deque, 2025). Un botón sin etiquetar es un acertijo; un botón anunciado como algo que no es, es una trampa.

Las cinco reglas que se reducen a una

El W3C define cinco reglas de ARIA, y apuntan en una sola dirección. Primera: si puedes usar un elemento HTML nativo con la semántica que necesitas, hazlo — un <button> real le gana a <div role="button"> cada vez (Greadme, 2026). Segunda: no cambies la semántica nativa salvo que debas, porque poner role="button" en un <h1> borra el encabezado del árbol de accesibilidad (Greadme, 2026).

Las tres restantes vigilan los bordes. Todo ARIA interactivo debe ser accesible por teclado, así que un <div role="button"> requiere tabindex="0" más manejadores de Enter y Espacio, sin excepciones (Greadme, 2026). No pongas role="presentation" ni aria-hidden="true" en un elemento enfocable, o un usuario de teclado aterriza en algo que su lector de pantalla no puede ver (Greadme, 2026). Y todo elemento interactivo debe tener un nombre accesible (Deque, 2025). Leídas juntas, las cinco son en realidad un instinto: parte del elemento nativo.

El div clicable: el error canónico

El error de ARIA más citado es un <div> clicable, y vale la pena ver por qué falla tan por completo. Un <button> es accesible por teclado por defecto, soporta el atributo disabled, envía formularios, se dispara con Enter y Espacio, y recibe un anillo de foco por defecto — todo a la vez (Greadme, 2026). Un <div> estilizado para parecer botón no tiene nada de eso, y role="button" aporta solo la etiqueta, no el comportamiento.

Hacerlo bien sin un button nativo significa escribir role="button", luego tabindex="0", luego un manejador de keydown que revise Enter y Espacio y llame a la acción — cuatro líneas recreando lo que <button> da gratis, y cuatro líneas fáciles de arruinar sutilmente (Greadme, 2026). La lección de un desarrollador que lo aprendió por las malas es rotunda: la mayor mejora de accesibilidad no fue aprender más atributos, fue confiar en los que los navegadores ya entienden (CSS-Tricks, 2026).

¿Cuándo es ARIA de verdad necesario?

ARIA es esencial en un puñado de casos reales, y vale la pena nombrarlos para que la regla no se vuelva dogma. El más claro es un widget complejo que no tiene equivalente HTML nativo — una interfaz de pestañas, un combobox con autocompletado, una vista de árbol — donde debes usar ARIA para aportar el significado que falta (Accsible, 2026). Los demás se agrupan en torno a restricciones: remediar marcado heredado donde reestructurar el DOM saldría demasiado caro, construir un componente web que necesita semántica a medida, o sortear un elemento nativo cuyo soporte de navegador es tan poco fiable que ARIA se comporta mejor en la práctica (Accsible, 2026).

La trampa es que usar un rol de widget es un compromiso, no una etiqueta. Cuando adoptas un rol como tablist o dialog, aceptas la responsabilidad total de su interacción por teclado, y la Guía de Prácticas de Autoría de ARIA define los patrones exactos que se esperan — flechas entre pestañas, Escape para cerrar un diálogo, Inicio y Fin para saltar dentro de una lista (Accsible, 2026). Sáltatelo, y tu widget queda técnicamente etiquetado pero funcionalmente inusable para usuarios de solo teclado — el mismo contrato de teclado que nuestra guía sobre accesibilidad por teclado y foco cubre por completo.

Dónde ayuda ARIA de forma legítima: estado, no semántica

El ARIA más seguro y más valioso no reemplaza a los elementos nativos — les añade estado y relaciones. Un <button> nativo con aria-expanded es la forma correcta de construir un acordeón o un disparador de despliegue, porque el botón aporta el comportamiento y ARIA aporta solo el estado abierto-o-cerrado (RatedWithAI, 2026). En el mismo espíritu, aria-describedby liga un campo de formulario a su texto de ayuda o mensaje de error, aria-invalid marca un campo que falló la validación, y una región aria-live anuncia un cambio dinámico — usada de forma amable, no con las interrupciones constantes que causa assertive (RatedWithAI, 2026).

El nombrado es la única área que hay que manejar con cuidado. aria-label y aria-labelledby son apropiados para widgets a medida que carecen de una etiqueta visible, pero añadirlos a un elemento que ya tiene un <label> propio crea un doble anuncio confuso (Easy A11y Guide, 2025). Esta es la misma disciplina de etiquetado que hace o rompe un formulario, que nuestra guía sobre formularios web accesibles recorre campo por campo.

Los usos indebidos que empeoran las cosas

La mayor parte del daño de ARIA viene de una lista corta de errores predecibles. El ARIA redundante es el más leve — role="button" en un <button> solo añade ruido — pero los dañinos son peores que ruido. Un nombre accesible oculto, donde aria-label="Enviar" está en un botón que visualmente dice “Haz clic aquí”, le dice una cosa a un usuario de lector de pantalla mientras un usuario vidente ve otra (WebAbility, 2026).

Dos más son especialmente costosos porque las herramientas automáticas muchas veces no los detectan. Poner aria-expanded pero olvidar alternarlo cuando el desplegable se abre hace que el lector de pantalla anuncie el estado equivocado en cada uso — peor que no usar ARIA (WebAbility, 2026). Y aplicar aria-hidden="true" a un elemento enfocable, o a su ancestro, le dice a la tecnología de asistencia que ignore algo en lo que un usuario de teclado aún puede aterrizar (W3C, 2026). El patrón en todos los casos es el mismo: ARIA que describe una realidad que la página no entrega de verdad.

La señal de que te equivocaste: el esfuerzo

Hay una señal fiable de que fuiste por ARIA demasiado pronto, y es cuánto está trabajando. Si ARIA se siente como que hace trabajo pesado, eso suele ser señal de que el marcado está peleando con el navegador en vez de trabajar con él (CSS-Tricks, 2026). Una versión común de este error es tratar ARIA como un gancho de estilo — ir por un rol para colgarle CSS — cuando el arreglo era un elemento nativo más una simple clase todo el tiempo (CSS-Tricks, 2026).

El reencuadre que lo resuelve es dejar de ver el HTML semántico como la base que dejas atrás. Es el cimiento del que todo lo demás depende, y los elementos nativos están mejor soportados y necesitan mucho menos mantenimiento que cualquier cosa que reconstruyas con ARIA y JavaScript (Accsible, 2026). Cuando una página necesita mucho ARIA para ser accesible, la pregunta honesta no es “qué atributo me faltó” sino “por qué esto no está hecho de los elementos que ya funcionan”.

Por qué nuestros sitios son casi sin ARIA por construcción

Todo lo de arriba explica por qué nuestras propias páginas cargan casi nada de ARIA, y por qué eso es una virtud y no una omisión. Cuando un sitio se construye desde HTML estático y semántico con casi nada de JavaScript, los elementos nativos ya están haciendo justo el trabajo que ARIA existe para parchar — los botones son botones, la navegación es un <nav>, los encabezados son encabezados, y cada uno llega con su rol, su teclado y su nombre intactos. Simplemente queda poco que ARIA tenga que reparar.

Esta es la misma convergencia que seguimos encontrando: la opción accesible y la opción ligera resultan ser una sola opción. Un sitio cargado de ARIA suele ser un sitio cargado de los widgets de JavaScript a medida que volvieron necesario el ARIA en primer lugar, que es el costo de rendimiento que mide nuestra guía sobre JavaScript y rendimiento web. Ve por el elemento nativo, y obtienes accesibilidad, velocidad y menos código que mantener en una sola decisión — que es todo el argumento práctico de nuestro pilar sobre si la accesibilidad web es obligatoria: la forma más fiable de cumplir es construir de modo que el cumplimiento sea lo predeterminado, no el parche.