Más vale ARIA que fuerza

Cada febrero, WebAIM, un centro de investigación en accesibilidad de la Universidad Estatal de Utah, analiza el millón de páginas de inicio más visitadas de internet y publica cuántas fallan. Desde hace 8 años, es el censo más grande que tenemos para saber cómo está la accesibilidad en el mundo real. El informe de 2026 trae dos datos que conviene leer juntos.

El primero: el 95,9% de las páginas tiene fallos de accesibilidad detectables de forma automática, casi un punto más que el año anterior. Los errores por página pasaron de 51 a 56,1, es decir, un 10% más. Después de seis años de mejoras pequeñas pero constantes, la tendencia se ha invertido.

El segundo explica bastante mejor lo que está pasando. WebAIM contó 133 millones de atributos ARIA, unos 133 por página. ARIA (siglas de Accessible Rich Internet Applications) es un conjunto de atributos que se añaden al HTML para explicarle a un lector de pantalla lo que un elemento es cuando el propio HTML no lo dice: que ese div es un botón, que ese panel es un diálogo o que ese texto es una alerta. Creció un 27% en un solo año y hoy hay seis veces más que en 2019.

O sea que en el mismo año hemos escrito más código para reforzar la accesibilidad que nunca, y hemos publicado una web menos accesible que el año pasado.

El dato incómodo

Se puede afinar aún más. Las páginas que llevan ARIA tienen de media 59,1 errores, frente a las 42 de las que no lo llevan. Y la relación es progresiva: cuantos más atributos ARIA tiene una página, más errores se le detectan.

Esto no significa que el atributo ARIA esté mal, significa que se está usando sin el criterio que necesita para funcionar. Por ejemplo, un aria-label en un elemento que ya tenía un nombre correcto: ahora el lector de pantalla anuncia el texto del atributo y no el que se ve en la interfaz, así que quien escucha oye una cosa distinta de la que hay en la pantalla. O un role="button" en un div, que anuncia un botón aunque el elemento siga sin poder activarse con el teclado, que es incumplir el criterio 2.1.1 sobre teclado con aspecto de haberlo arreglado. O un aria-hidden="true" puesto para ocultar un icono decorativo que acaba aplicándose al contenedor entero, con lo que el mensaje de error que hay dentro deja de existir para quien no lo ve. Cada uno de esos atributos es una promesa incumplida que se le hace al lector de pantalla.

La primera regla de ARIA, escrita por quienes lo diseñaron, es no usar ARIA. Si existe un elemento HTML que ya hace lo que necesitas, ese elemento es la respuesta. Bueno, pues esa regla se está incumpliendo 133 millones de veces.

Nada de esto es un descubrimiento reciente. Andy Carter ya lo explicaba en 2024, con el informe WebAIM de aquel año en la mano: las páginas con ARIA tenían un 34,2% más de errores detectados que las que no lo llevaban, y repasaba una por una las formas en que un aria-label mal puesto rompe cosas que funcionaban. Dos años después esa brecha no se ha cerrado, se ha ensanchado.

De dónde ha salido todo ese ARIA

WebAIM apunta a dos causas y no se corta al nombrarlas: las páginas son cada vez más complejas (un 22,5% más de elementos en un año) y hay más dependencia de frameworks de terceros y de «prácticas de programación asistida por IA, o vibe coding».

Sobre esto último merece la pena pararse, porque el mecanismo es interesante y no es lo que podemos suponer en primera instancia.

Un modelo de lenguaje aprende a predecir el código más probable dado un contexto. El material del que aprendió es esa web: la del 95% de páginas con fallos, la de los seis años de div con onclick, la del ARIA mal puesto. Cuando genera un componente inaccesible no está fallando, está reproduciendo con bastante fidelidad lo que hay ahí fuera. Es decir, fue muy bien entrenado en sitios muy mal diseñados.

Y hay algo peor. Un modelo sabe que la accesibilidad importa, porque también aprendió de la documentación, de los artículos y de las charlas donde se explica. Así que añade ARIA, mucha ARIA, sin el criterio para saber cuándo sobra, cuándo contradice al HTML y cuándo está tapando un problema en lugar de resolverlo. El resultado es exactamente el que mide WebAIM: más atributos, más errores.

A esto se suma que el fallo es invisible donde solemos mirar. Un lector de pantalla no lee la pantalla, lee el árbol de accesibilidad, una estructura que el navegador calcula a partir del HTML, el CSS y esos atributos ARIA. Dos botones pueden verse idénticos y ser completamente distintos ahí debajo. Una captura de pantalla no lo muestra, y una revisión visual tampoco. Cuando un modelo multimodal revisa su propio trabajo mirando una imagen, está mirando el artefacto equivocado.

Por qué esto va de diseño y no solo de código

Aquí es donde esto deja de ser un problema de accesibilidad, y empieza a parecerse a algo que, seguro que vosotros también habéis notado en vuestro flujo de trabajo.

Las partes que a priori parecían más difíciles salen rápido con IA. En cambio, las que llevamos décadas dando por sabidas se atascan: decidir si una pantalla debería existir, qué pasa cuando no hay datos, si este caso es una excepción real o un patrón que ya resolvimos en otro sitio, qué significa exactamente ese estado para el usuario. Decisiones de producto que costaría defender en una revisión.

Durante un tiempo pensé que el problema era el modelo, que no estaba entrenado lo suficiente. Así que cuando me senté a escribir los criterios para que un LLM pudiera seguirlos, descubrí que no estaban lo suficientemente documentados.

Prueba a hacerlo. Coge una decisión que tomes en piloto automático, cuándo algo merece una pantalla propia y cuándo es un paso dentro de otra, y escribe la regla exacta que sigues. No la teoría, la regla. A las tres o cuatro líneas acabas escribiendo «depende del contexto», y ahí se termina el documento, porque el contexto, la información sobre el producto y sobre quién lo usa, es justo lo que tú aportas sin darte cuenta y la máquina no tiene.

Nadie nos pidió nunca que escribiéramos o verbalizáramos estas reglas. Las aprendimos mirando, corrigiendo y acumulando decisiones hasta que las interiorizamos. Solo funciona mientras el ejecutor seas tú o alguien que ha estado en las mismas reuniones. Los sistemas de diseño fueron nuestro intento de arreglarlo, y sabemos cómo acaba: documentan bien los componentes y mal los criterios cuando viven en la zona gris.

El ARIA mal puesto es la versión visible de eso mismo. Es criterio a medio escribir, aplicado sin la parte que no se escribió. Y como en el caso de la accesibilidad las reglas sí están publicadas y son comprobables, el desastre se puede medir. Con el resto de las decisiones de producto pasa lo mismo, pero no hay nadie contando páginas.

Antes cada variación costaba tiempo y dinero, así que en algún momento se acababa el presupuesto y salías con lo que tenías. La concesión era impuesta por el calendario.

Ahora el coste de pedir otra versión se ha reducido mucho, así que puedes seguir puliendo indefinidamente, y como cada iteración mejora un poco, nunca hay un momento evidente para parar. Así que la decisión difícil ha cambiado de sitio. Ya no es cómo conseguir el resultado que quiero, sino cuándo acepto que este trozo se queda por debajo de mi estándar y me ocupo de otra cosa.

Lo que sí se traslada

Con la accesibilidad esta conversación no ocurre, y por eso es un buen sitio para aprender.

Las reglas llevan escritas desde las WCAG 1.0 de 1999, numeradas, con criterios de aceptación y con una forma clara de comprobar si se cumplen. No tengo que justificar qué significa un contraste suficiente, ya que alguien ya hizo ese trabajo hace años, y no fue un equipo concreto de producto, sino personas que necesitaban que estuviera bien hecho.

Cuando el criterio está escrito así, se traslada. Puedes pasarle a un modelo el criterio 1.4.3 sobre contraste mínimo antes de que escriba una línea, y lo que sale lo cumple, porque no hay nada que interpretar: el umbral de contraste es un número. Es la razón por la que empecé por aquí cuando construí Jeikin, ya que Las reglas ya estaban escritas.

Con el alcance conviene ser honesto. Las herramientas automáticas detectan una parte de los criterios, no todos, y en julio el W3C dejó por escrito en la WCAG-EM 2.0 que ninguna metodología por sí sola permite declarar que algo cumple. Pero fíjate en lo que dicen los números de WebAIM: el 96% de todos los errores detectados se concentra en seis tipos, y son los seis más mecánicos que existen. Contraste, texto alternativo, etiquetas de formulario, enlaces vacíos, botones vacíos. Nada de eso necesita criterio de diseño. Todo eso debería estar resuelto antes de que el código llegue a una revisión.

Que en 2026 sigan siendo el 96% de los fallos, con más herramientas que nunca disponibles, dice algo sobre dónde estamos poniendo el esfuerzo. Nos hemos pasado los últimos dos años preguntándonos si esto nos va a sustituir, a mí me ha resultado más útil preguntarme cuánto de lo que sé hacer y no me aporta valor soy capaz de explicar y documentar, para poder poner el foco en lo que realmente importa.

 

Más entradas de Diseño