← Blog de Guindo Design, Disseny Estratègic de Producte Digital
L'accessibilitat (i les seves eines) han de ser invisibles
Hace poco, al presentar Jeikin a un desarrollador, me soltó una frase que me esperaba tarde o temprano: “¿Para qué quiero otra herramienta si puedo añadir reglas de accesibilidad a mi CLAUDE.md?”.
En parte tenía razón: puedes escribir «sigue las WCAG AA» en tus instrucciones de IA y el agente lo intentará. Pondrá algún alt de vez en cuando, usará HTML semántico si se acuerda y sugerirá atributos ARIA que haya visto en otros sitios.
Pero pídele a esa misma IA que revise el código mañana y no recordará qué encontró ayer. Pregúntale si el bug fix que aplicó la semana pasada pasó las reglas de corte, o intenta demostrar a un auditor que cada componente ha sido revisado. No hay rastro de nada.
Las instrucciones sin control son solo sugerencias, y las sugerencias mueren ante una fecha límite, un cambio de equipo o un inspector exigiendo evidencias.
La brecha de cumplimiento
Desde junio de 2025, el Acta Europea de Accesibilidad (EAA) ya no es una recomendación, es una obligación. Francia ya ha dado toques a grandes retailers y las multas pueden llegar a los 3 millones de euros o al 4% de la facturación.
Para los equipos de producto, la pregunta ya no es «¿nos importa la accesibilidad?», sino «¿podemos demostrar que la cumplimos?». Y aquí es donde falla el modelo actual: una IA puede escribir código accesible, pero no puede auditar lo que ha hecho, verificar que los fixes superan los controles de calidad o generar un histórico para una auditoría. Eso es capacidad de sistema, no de instrucciones.
«Le pedimos a la IA que cumpliera las WCAG» no es una prueba. «Aquí está el dashboard con 86 criterios evaluados y 12 errores corregidos» sí lo es.
Lo que la IA ve (y lo que ignora)
Las WCAG 2.2 tienen 86 criterios. La IA es buena detectando problemas estructurales (jerarquía de encabezados, etiquetas faltantes), pero hay una parte crítica que se le escapa:
- El orden del foco solo se ve en ejecución.
- El contraste depende de estilos calculados, no solo del código.
- Los atajos o la navegación mediante teclado requieren simulación real.
- La visión cromática (deuteranopia, protanopia) necesita verificación visual, no solo lógica.
Hoy en día, creemos que el enfoque ganador es por capas: el análisis estático (ESLint) captura el 30% de los errores y el escaneo en runtime (axe-core) otro 30%. Para el 40% restante sigue siendo indispensable la revisión humana guiada: carga cognitiva, orden de lectura, etc.
Un flujo de trabajo invisible
En Guindo, cuando diseñamos herramientas, tenemos una máxima: la accesibilidad debe ser invisible para el flujo de trabajo. No hablamos de overlays inútiles, sino de que el desarrollador no tenga que salir de su entorno.
Per això hemos integrado Jeikin donde ocurre la acción:
- En el editor: Mediante MCP, conectas tu IA a un sistema de cumplimiento real. No son solo prompts; si la IA encuentra un fallo, lo registra. Si intenta arreglarlo, el sistema verifica que el fix funciona. Si no pasa el test, no se marca como resuelto. El ciclo se cierra: buscar, reportar, arreglar, verificar.
- En el Pull Request: Jeikin revisa cada PR antes del merge. Los errores aparecen como comentarios en el código, con su severidad y el criterio WCAG afectado. Si hay infracciones críticas, el merge se bloquea. Es la red de seguridad para cuando la IA alucina o el desarrollador se salta un paso.
- En el Dashboard: Todo el esfuerzo se traduce en datos. Evidencias para el auditor, tranquilidad para el responsable de producto.

Instrucciones vs. sistema
Muchos insisten: «Mi IA ya sigue mis reglas», pero hay cosas que un archivo de texto no puede hacer por ti:
- Trazabilidad: Saber qué se ha revisado y qué se ha quedado fuera.
- Ejecución: Bloquear un merge si el código es inaccesible.
- Persistencia: La IA olvida al cerrar la sesión; el sistema, no.
- Pruebas reales: Simular contrastes APCA o navegación por teclado.
Las instrucciones son el punto de partida, pero un sistema de cumplimiento es el bucle completo. Ese bucle es lo que evita regresiones y lo que convierte la accesibilidad en una realidad tangible y demostrable.
Pruébalo y dinos qué te parece: Instala la extensión y pasa una revisión. Lo normal es encontrar barreras que ni sabías que estaban ahí, no porque el código sea malo, sino porque la accesibilidad es invisible hasta que alguien decide mirar de verdad.