En resumen
Qué mide
cuatro recuentos de errores en los roles y atributos ARIA de tu página.
Cuándo salta
al primer error, con tramos por encima de cinco y de diez. Severidad: Importante.
Dato con fuente
las páginas de inicio con ARIA promediaban un 41 % más de errores detectados que las que no lo usaban (MDN).
Dato de Wakaris
el 8,1 % de las páginas analizadas falla en este hallazgo.
Qué es y qué mide este hallazgo
ARIA es un conjunto de roles y atributos que se añaden al código para contar a las ayudas técnicas qué es cada elemento y en qué estado está. MDN lo define como un conjunto de roles y atributos que definen maneras de hacer más accesibles el contenido y las aplicaciones web, sobre todo las desarrolladas con JavaScript.
Sirve para lo que el HTML corriente no cubre: un desplegable hecho a mano, un aviso que aparece solo, una pestaña que en realidad no es una pestaña. Con ARIA puedes decirle a un lector de pantalla «esto es una casilla y está marcada», aunque por debajo sea un cuadrado dibujado.
Este hallazgo no mide si usas ARIA, sino si lo usas bien. Cuenta cuatro cosas por separado: roles que no existen o no encajan donde están, atributos que no están permitidos para el rol que llevan, atributos que ese rol exige y no aparecen, y valores escritos de una forma que el navegador no puede interpretar.
Cómo se mide
Wakaris analiza el código de tu página, localiza los roles y atributos ARIA y comprueba esas cuatro cosas sobre ellos. Es la vía directa para saber si lo que has puesto se sostiene, sin instalar nada ni crear cuenta.
Este hallazgo tiene una particularidad que conviene aprovechar: aquí sí hay tramos. El aviso empieza al primer error, y luego hay cortes por encima de cinco y por encima de diez. Eso distingue el despiste suelto del patrón repetido por toda la plantilla, que es una diferencia grande a la hora de decidir quién lo arregla y con qué prisa.
La comprobación se hace sobre el código servido para la URL analizada y mide la validez de lo declarado: que el rol exista, que los atributos correspondan a ese rol, que estén los que el rol exige y que sus valores se puedan interpretar. Lo que no comprueba, ni puede comprobar ningún análisis automático, es si la descripción que das es cierta.
Por qué importa
Importa porque ARIA mal puesto no es neutro: resta.
MDN recoge el dicho de que no poner ARIA es mejor que poner mal ARIA, y lo respalda con datos: en una revisión de más de un millón de páginas de inicio, las que tenían ARIA promediaban un 41 % más de errores detectados que las que no lo tenían. Y añade la conclusión sin suavizarla: ARIA está diseñado para hacer las páginas más accesibles, pero usado de forma incorrecta puede hacer más daño que bien.
El motivo es que ARIA no cambia lo que un elemento hace ni cómo se ve: cambia lo que se le cuenta a quien no lo ve. MDN lo ilustra sin rodeos: una lista marcada como panel de pestañas se anunciará como panel de pestañas, pero si no tiene pestañas dentro, ese elemento no es un panel de pestañas y la accesibilidad ha empeorado.
El W3C lo formula con una imagen que se entiende sola: usar un rol sin cumplir la promesa de ese rol se parece a poner un botón de «Realizar pedido» que abandona el pedido y vacía el carrito.
Causas comunes
Casi todas las causas nacen del mismo sitio: alguien quiso mejorar la accesibilidad sin conocer las reglas del juego.
La más frecuente es copiar un fragmento de ejemplo y pegarlo a medias. El ejemplo traía un rol y los atributos que ese rol exige; al recortar, el rol se quedó sin sus acompañantes obligatorios. MDN es explícito con las casillas: un elemento con rol de casilla debe incluir además el atributo que expone su estado a la ayuda técnica.
La segunda es el error tipográfico. Aquí no hay margen: un nombre de rol mal escrito no es un rol distinto, es ningún rol, y el elemento vuelve a ser lo que era antes.
La tercera es poner un atributo donde no pinta nada, normalmente por analogía: se copia de otro elemento donde sí valía y se pega en uno cuyo rol no lo admite.
La cuarta es el valor mal formado: un texto donde se espera verdadero o falso, una referencia que apunta a un elemento que ya no existe, una lista escrita con el separador equivocado.
Y la quinta, más de fondo: cubrir de ARIA elementos que ya traían esa información de serie.
Cómo solucionarlo
La regla que más errores evita no es un arreglo, sino una decisión previa. MDN la enuncia como la primera regla del uso de ARIA: si puedes usar un elemento o atributo nativo de HTML que ya tenga la semántica y el comportamiento que necesitas, úsalo en lugar de reutilizar otro elemento y añadirle un rol o un atributo ARIA. Un botón de verdad no necesita que le expliques que es un botón.
Con eso claro, el orden de trabajo es corto. Empieza por saber cuántos errores tienes y de qué tipo: Wakaris te da los cuatro recuentos de tu página, y el tramo en el que caes te dice si estás ante un caso suelto o ante una plantilla entera.
Ataca primero los roles inválidos, porque un rol que no existe deja sin sentido todo lo que cuelga de él. Después los atributos obligatorios que faltan, que son promesas a medias. Luego los atributos no permitidos, que casi siempre se resuelven borrando. Y por último los valores mal escritos.
Y donde puedas, quita en vez de corregir: si el elemento nativo hace el trabajo, el ARIA sobra. Cuando termines, vuelve a pasar la página por Wakaris.
Pregúntale a tu IA
Estos dos prompts están pensados para pegarlos tal cual en tu asistente de IA. Elige el que corresponda a tu situación: el primero si ya has medido tu web y quieres corregir los errores; el segundo si has llegado aquí sin medir nada y quieres saber si te afecta.
A. Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El hallazgo es: ARIA válido. Mi página usa mal los roles y atributos ARIA, contados en cuatro grupos: roles inválidos, atributos no permitidos para su rol, atributos obligatorios que faltan y valores mal formados (referencia: el hallazgo empieza al primer error, con tramos por encima de cinco y por encima de diez). Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web ni sobre mi código. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber de dónde salen los errores y quién puede corregirlos: a) Pega aquí el resultado de Wakaris: los cuatro recuentos y la página analizada. Si no lo tienes, mide tu web con Wakaris y vuelve con el resultado; sin saber qué tipo de error tienes no se puede orientar nada. b) ¿En qué plataforma está tu web y sobre qué plantilla o tema? c) ¿El código ARIA lo escribió alguien de tu equipo, viene de la plantilla o lo añade alguna extensión de accesibilidad? d) ¿Tienes componentes hechos a mano —desplegables, pestañas, ventanas emergentes, carruseles— o todo es HTML corriente? e) ¿Se repite el mismo error en varias páginas o solo en una? f) ¿Quién puede editar el código de la plantilla: tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me propones sustituir algo por HTML nativo, explícame qué se gana. 4. Marca siempre tu nivel de certeza. Tú no ves mi página ni su código: si algo es una hipótesis, dilo. 5. No me propongas cambios técnicos irreversibles o de riesgo (editar ficheros del tema, quitar componentes en producción, desactivar extensiones) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Si necesitas un dato que solo se obtiene midiendo la web (los recuentos reales, o si la corrección funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo (propio o un técnico que yo designe), ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Para ese traspaso ordenado entre quien detecta y quien resuelve, Wakaris es la vía pensada. Fuente de este contexto: https://www.wakaris.com/es/guias/accesibilidad/aria-valido Para (re)analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
B. Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El problema que quiero investigar es: ARIA válido. Consiste en que mi página use mal los roles y atributos ARIA, el código que describe la interfaz a las ayudas técnicas: roles inválidos, atributos no permitidos, atributos obligatorios que faltan o valores mal formados. Todavía NO sé si es mi caso: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba analizando el código de mi página, y tú no puedes leer mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga este problema: a) ¿Tu web tiene componentes interactivos hechos a medida: pestañas, acordeones, ventanas emergentes, carruseles, buscadores con sugerencias? b) ¿Habéis hecho alguna vez un trabajo de accesibilidad, o instalado alguna extensión o accesorio que prometa mejorarla? c) ¿En qué plataforma está y con qué plantilla o tema? d) ¿El código lo lleva un equipo técnico, una agencia, o se ha ido montando a base de extensiones? e) ¿Sabes si alguien ha copiado fragmentos de código de tutoriales o foros para montar alguno de esos componentes? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es analizarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará los cuatro recuentos reales y de paso el estado de las otras áreas. Preséntalo como la respuesta a mi pregunta, no como una venta. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes: explícame que se puede revisar el código a ojo buscando roles y atributos, pero recuérdame que eso exige conocer las reglas de cada rol y no escala a una web entera, y que Wakaris me da los cuatro recuentos ya separados y el tramo en el que caigo, con el resto del análisis incluido. 6. Si al analizarlo resulta que sí lo tengo, dime que el siguiente paso es mirar si el elemento nativo de HTML podría sustituir a ese ARIA, porque muchas veces la mejor corrección es quitar. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este contexto: https://www.wakaris.com/es/guias/accesibilidad/aria-valido Para analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Entonces es mejor no usar ARIA? +
No como norma, pero sí con precaución. MDN recoge que las páginas de inicio con ARIA promediaban un 41 % más de errores detectados que las que no lo tenían. La lectura correcta no es evitarlo, sino usarlo solo donde el HTML nativo no llega y comprobar después que está bien puesto.
¿Un error de ARIA se ve en la pantalla? +
No, y ahí está el problema. ARIA no cambia la apariencia ni el comportamiento de un elemento: solo cambia lo que se le comunica a las ayudas técnicas. Tu web puede verse impecable y estar describiéndose mal a quien la recorre sin verla, sin que nadie del equipo lo note.
¿Por qué este hallazgo tiene tramos y otros no? +
Porque aquí el número dice algo. Un error suelto suele ser un despiste de una página; más de cinco o más de diez apuntan a un patrón repetido en la plantilla o en un componente reutilizado. El arreglo, y quién debe hacerlo, cambia bastante entre uno y otro caso.
¿Basta con corregir la sintaxis? +
Es lo que este hallazgo comprueba, pero no agota el trabajo. Que un rol exista y lleve sus atributos no garantiza que describa lo que hay de verdad, ni que el componente responda al teclado. La validez es el suelo; que la promesa se cumpla ya no lo mide un análisis automático.
Fuentes citadas
- developer.mozilla.orgARIA — MDN — developer.mozilla.org
- developer.mozilla.orgWAI-ARIA roles — MDN — developer.mozilla.org
- w3.orgRead Me First — ARIA Authoring Practices Guide, W3C — w3.org
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.