La EAA lleva un año en vigor. La mayoría de los equipos aún no pueden demostrar su cumplimiento.

On 28 de junio de 2025La Ley Europea de Accesibilidad pasó de tener fecha límite a entrar en vigor. Eso fue hace ya más de un año. 

Si ya no parece urgente, es normal. Los plazos se desvanecen rápidamente cuando no hay ningún problema visible. Pero la accesibilidad no falla como una caída del servidor. Las consecuencias se manifiestan más tarde, en forma de demanda, auditoría fallida, acuerdo estancado en la fase de contratación, y para entonces, la causa principal casi siempre es la misma: alguien no pudo usar lo que creaste y nadie lo detectó a tiempo. 

Pero no perdamos de vista el verdadero propósito de todo esto. No se trata solo de satisfacer a un auditor, sino de comprobar si una persona real puede utilizar el producto. 

El mejor amigo de mi padre es ciego de nacimiento. Al observarlo en su cocina, se mueve con mayor rapidez y precisión en la preparación y cocción de los alimentos que la mayoría de las personas videntes, porque puede "sentir" cada superficie y cada utensilio.  

Si le dieras un iPhone para pagar una factura a través de una aplicación bancaria, no conservaría su destreza. Un cuchillo tiene peso y textura que le proporcionan información táctil. Una pantalla táctil no le permite sentir si su pulgar tocó "Transferir" o "Cancelar". Que pueda completar el pago no depende de su habilidad. Todo se reduce a si el equipo que desarrolló la aplicación la probó correctamente. 

La aplicación de la ley es la forma que tiene la sociedad de forzar que se plantee esa pregunta. Pero la pregunta en sí nunca trató realmente de la aplicación de la ley. Trata sobre él y sobre todos los que son como él. 

Sin embargo, siempre se ha interpretado erróneamente el significado de la aplicación de la ley. La aplicación de la ley no es una fecha puntual, sino una postura continua. 

La aplicación de la ley no pregunta si aprobaste una vez. Pregunta si puedes demostrar que sigues aprobando. 

La EAA exige que los productos digitales, incluidas las aplicaciones móviles, cumplan con los estándares de accesibilidad para usuarios con discapacidades, tomando como referencia técnica la WCAG 2.2. Sin embargo, el cumplimiento normativo nunca se limitó a que una aplicación superara una verificación el día de su lanzamiento. Se trata de que una organización pueda demostrar, de forma consistente y a lo largo del tiempo, que la validación de la accesibilidad forma parte de su proceso de distribución de software. 

Se trata de un criterio fundamentalmente distinto al de «realizamos un análisis antes de la fecha límite». Es la misma distinción que existe en todos los demás ámbitos de pruebas orientadas al cumplimiento normativo: ningún auditor acepta «lo superó una vez» como prueba de un control continuo. La accesibilidad no es una excepción, y un año de aplicación de la normativa lo ha dejado claro a las organizaciones que ahora se enfrentan a auditorías, cuestionarios de contratación y, en un número creciente de casos, a litigios. 

Las demandas por accesibilidad web en EE. UU. acaban de alcanzar un máximo histórico. La primera mitad de 2026 produjo el mayor volumen jamás registrado, lo que sitúa al año en camino de superar las 6,000 demandas, aproximadamente un 20 % por encima de 2025, que ya había aumentado un 27 % con respecto a 2024.UsableNet, Informe de mitad de año de 2026).  

Entre la aplicación de la EAA en la UE y los litigios de la ADA en EE. UU., la frase "ya llegaremos a la accesibilidad tarde o temprano" se ha convertido en una de las posturas más costosas que puede adoptar un líder de ingeniería o cumplimiento normativo. 

La IA ha agravado el problema, no lo ha reducido. 

El momento en que esto ocurre es crucial. La aplicación de la ley llegó justo cuando se aceleró la entrega de software. En muchas empresas, el código generado por IA ahora representa entre el 40 y el 50 % de la producción, y esa proporción está aumentando (Digital.ai, La cuarta ola: la IA está escribiendo el código. ¿Quién lo está probando?)Las tareas de codificación que antes llevaban días ahora se realizan en horas. 

Más código, entregado más rápido, significa más aspectos de accesibilidad que validar en cada sprint, y el código generado por IA no se libra de los problemas de accesibilidad solo porque se haya producido rápidamente. La falta de texto alternativo, el orden de enfoque incorrecto, los campos de formulario sin etiquetar y los elementos interactivos que fallan con la navegación por teclado o interruptor son precisamente el tipo de regresiones que se propagan rápidamente en un flujo de trabajo de alta velocidad cuando no se realizan comprobaciones sistemáticas. 

Las organizaciones que no han integrado la validación de accesibilidad en su flujo de trabajo de lanzamiento estándar no están logrando mantenerse estables. Acumulan deuda de cumplimiento con cada lanzamiento, y esta deuda se agrava más rápido que hace un año. 

Por qué la mayoría de los equipos todavía no alcanzan el nivel esperado. 

He aquí la brecha que se repite una y otra vez: ejecutar un análisis no es lo mismo que poder demostrar que se ejecutó. Cuando los resultados de accesibilidad se encuentran en un panel de control independiente, desconectado de la compilación, el dispositivo y la ejecución de la prueba que los generó, los equipos terminan con documentos en lugar de registros. La pregunta de un auditor —qué análisis se ejecutó, contra qué compilación, en qué dispositivo, como parte de qué prueba— requiere una respuesta directa, no un proyecto de reconstrucción. 

Un año después, el margen para resolverlo es menor que antes. 

La EAA se aplica rigurosamente. Los litigios relacionados con la ADA están activos y en aumento. La WCAG 2.2 ha elevado el estándar de referencia para todos. Nada de esto es información nueva a estas alturas, pero un año de convivencia ha dejado algo claro: las organizaciones que tienen dificultades no son las que desconocen el requisito, sino aquellas cuyo flujo de trabajo de pruebas no se diseñó para generar evidencia continua y auditable, fácil de revisar y compartir. 

Cerrar esa brecha no requiere un programa de accesibilidad completamente nuevo. Requiere tratar la validación de la accesibilidad de la misma manera que las organizaciones maduras ya tratan las pruebas funcionales: como una parte estándar y documentada de cada lanzamiento, no como una iniciativa aparte que se ejecuta paralelamente. 

Aquí es donde Digital.ai llega en: escaneo WCAG automatizado impulsado por Deque —el motor de accesibilidad más utilizado en la industria— donde cada resultado está vinculado a la compilación, el dispositivo y la prueba que lo produjo, lo que reduce la brecha de evidencia. 

En algún lugar, hay una versión del amigo de mi padre intentando usar lo que sea que tu equipo acaba de lanzar. El cumplimiento normativo es el rastro del papeleo. Él es la razón por la que vale la pena construir todo esto.