El código generado con IA (inteligencia artificial) a menudo no cumple las WCAG (Web Content Accessibility Guidelines, pautas de accesibilidad para el contenido web). Esa parte no sorprende. La mayoría de sitios web tampoco las cumplen, así que los datos de entrenamiento están llenos de código inaccesible.
Lo que sí sorprende ocurre durante la remediación de accesibilidad: el trabajo de arreglar código que incumple un criterio de conformidad de las WCAG. La IA tiene problemas con los patrones ARIA (Accessible Rich Internet Applications, aplicaciones de internet enriquecidas y accesibles) incluso cuando le doy instrucciones concretas.
Encuentro el problema en el código existente. Explico exactamente cómo se arregla. La IA sigue haciéndolo mal.
El problema
Aquí tienes 2 ejemplos de trabajo reciente.
Ejemplo 1: pestañas verticales
Le pedí a una IA que aplicara el patrón ARIA de pestañas (Tabs) a un código existente. Generó el patrón para pestañas horizontales en lugar de verticales.
Esta no es una decisión sutil. La orientación de las pestañas se ve leyendo el código. Le señalé el error y la IA reescribió el patrón solo para pestañas verticales. No escribió una implementación que funcionara con las dos orientaciones.
Ejemplo 2: una tabla compleja
Le pedí a una IA que hiciera accesible una tabla. La tabla tenía varias celdas de encabezado de fila y de columna, más una fila final de totales. Enumeré exactamente lo que quería:
- un título de tabla (
caption) - grupos de filas: encabezado, cuerpo y pie de tabla
- un atributo
idúnico en cada celda de encabezado - un atributo
headersen cada celda de datos, con todas sus celdas de encabezado
La IA vinculó celdas de datos con celdas de encabezado equivocadas y se dejó algunas de las correctas. La regla es sencilla: una celda de datos pertenece a las celdas de encabezado de su propia fila y de su propia columna. ¿Por qué no sabe aplicarla la IA?
Buscando una respuesta
Mi primera hipótesis fue que el problema principal son los datos de entrenamiento. La mayoría de sitios web implementan mal las WCAG, así que el modelo ve pocos ejemplos correctos y muchos defectuosos.
Esa hipótesis es demasiado simple. La mayoría de personas cometen errores gramaticales y de mecanografía al escribir, y eso no impide que la IA escriba correctamente.
Vamos a ver la investigación.
Comparar el código de la IA con el código humano
El artículo «Human or LLM? A Comparative Study on Accessible Code Generation Capability» es el más cercano a mi problema. LLM significa gran modelo de lenguaje (Large Language Model). El estudio compara código escrito por IA con código escrito por personas. También compara la generación de código ingenua, en la que el prompt no menciona nunca la accesibilidad, con código mejorado a base de prompts repetidos.
La primera conclusión coincide con mi experiencia:
«LLMs excel at addressing basic accessibility requirements but struggle with complex accessibility requirements, particularly ARIA-related attributes, performing worse than human developers.»
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek e Iftekhar Ahmed, University of California, marzo de 2025
Dicho de forma sencilla: la IA resuelve bien los requisitos fáciles y queda por debajo de las personas desarrolladoras en los difíciles. ARIA es el punto más débil.
La segunda conclusión es más interesante:
«Advanced prompting techniques consistently generate code with lower accessibility issues than human-written code, yet they fail to consistently surpass Naive Code Generation, indicating inherent limitations in addressing accessibility through prompting alone.»
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek e Iftekhar Ahmed, University of California, marzo de 2025
Dicho de forma sencilla: los prompts mejores superan al código escrito por personas, pero no superan de forma fiable el primer intento de la propia IA. El prompt, por sí solo, tiene techo. Los autores probaron las técnicas Zero-Shot, Few-Shot y Self-Criticism (3 maneras estándar de plantear una petición) y no encontraron ninguna mejora significativa.
Después propusieron y probaron un método llamado FeedA11y. Tiene 3 pasos:
- Generar el código sin ninguna instrucción sobre accesibilidad.
- Elaborar un informe de los problemas de accesibilidad, con las reglas de las herramientas de evaluación que ya existen.
- Arreglar solo los problemas del informe. No añadir nada más.
El resultado:
«FeedA11y consistently outperforms human-written code and all prompting techniques in accessibility, especially when leveraging Qwen2.5-Coder.»
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek e Iftekhar Ahmed, University of California, marzo de 2025
Esto encaja con lo que ya sabemos sobre trabajar con IA:
- Pedir muchas cosas a la vez da resultados inconsistentes.
- Separar el contexto que escribe el código del contexto que lo revisa da mejores resultados.
- Definir cómo se medirá el éxito suele funcionar mejor que enumerar los pasos para llegar. La excepción es cuando los pasos en sí importan.
Qué dice el resto de la literatura
«Large Language Models for Web Accessibility: A Systematic Literature Review» (Wajdi Aljedaan, Saudi Data & AI Authority, y Rubel Hassan Mollik, University of North Texas, mayo de 2026) es un metaanálisis, un estudio que combina los resultados de otros estudios. Recoge 38 artículos sobre LLM y accesibilidad, así que ofrece una visión más amplia que cualquier experimento individual.
Destacan 3 conclusiones:
- Todos los estudios toman las WCAG como referencia. Ninguno usa material complementario como las orientaciones COGA (Cognitive Accessibility, accesibilidad cognitiva).
- La mayoría de estudios prueban LLM comerciales habituales y técnicas de prompt. Pocos exploran otros modelos o arquitecturas.
- La investigación se concentra en la semántica y la perceptibilidad. Pocas veces trata la carga cognitiva, la coherencia de la navegación o la complejidad de las tareas.
El artículo es directo sobre lo que queda fuera. Las personas con discapacidad participan poco en los estudios y, cuando participan, los grupos son pequeños o heterogéneos. Por tanto, la evidencia muestra viabilidad técnica y rendimiento comparado, no «real-world usability or lived experience» (usabilidad real ni experiencia vivida).
De ahí sale la conclusión más valiosa de la revisión: la accesibilidad depende del comportamiento humano, y las mejoras técnicas no van a cambiar eso.
Conclusiones
La situación se divide en dos partes.
- Todo lo que un ordenador puede detectar y medir se puede mejorar. La mayor parte de esa mejora viene de cómo diseñas el pipeline (el flujo de revisión y pruebas), no de cómo redactas el prompt.
- Todo lo demás sigue necesitando personas, incluidas personas con discapacidad, probando tareas reales.
Sobre la primera parte puedes actuar hoy. Trata el cumplimiento de las WCAG como un estándar técnico dentro de tu pipeline de revisión y pruebas. La IA te puede ayudar: da mejores resultados cuando el requisito es comprobable y quita incertidumbre a las reglas fáciles de implementar.
La segunda parte es donde están las ganancias de verdad. La accesibilidad cognitiva es la dirección hacia la que van las WCAG, y es el ámbito que la investigación en IA apenas ha tocado.
Tenemos trabajo por delante.