Accesibilidad con Axe en CI y un pipeline que propone fixes

Contexto

La accesibilidad era uno de los Tech OKRs, y las apps tenían problemas conocidos. Faltaban etiquetas, el contraste era insuficiente, había estados comunicados solo por color y formularios sin asociación con sus errores. Todo eso lo detectaba una herramienta de auditoría externa, pero la detección llegaba tarde y en paquete.

Problema

Sin chequeos sistemáticos, los problemas se descubren al final del ciclo y arreglarlos cuesta más. No había visibilidad de cuántos había, en qué plataforma, ni quién era dueño de cada uno.

Y hay una cosa que se subestima. La mayoría de los arreglos son de baja complejidad, como una etiqueta, un rol o un contraste. Son tantos y tan repetitivos que arreglarlos a mano no escala y se vuelven a romper.

Qué decidimos (y qué descartamos)

Decidimos avanzar por iteraciones, empezando por lo que desbloqueaba a los equipos más rápido y subiendo en automatización:

1. Escaneo manual con una herramienta sin código.
2. Linter para React Native, primero a demanda y luego como pre-push.
3. SDK de pruebas automatizadas sobre los tests de UI ya existentes.
4. Informes HTML como artefactos del CI/CD.
5. Monitoreo del puntaje, y que un PR no pueda bajarlo.

Descartamos empezar por lo más completo. Una integración perfecta en el CI se habría llevado meses, y mientras tanto nadie habría empezado a arreglar nada. Y descartamos, por el momento, integrar el SDK nativo de Android en los tests instrumentados. Lo dejamos tachado en el RFC, a la vista, porque documentar lo que no hacés también es parte del diseño.

Después, con el problema ya medido, sumamos una segunda línea, la remediación asistida por IA.

Cómo lo hicimos

El camino de herramientas. Escribí el RFC con las iteraciones, los trade-offs y las preguntas abiertas, por ejemplo si el pre-push bloquea o solo informa. Y una guía corta para que cualquier equipo pudiera escanear sus pantallas a mano sin esperarme.

El pipeline con IA. La idea es una cadena de pasos explícitos:

1. Leer los problemas del informe de auditoría, con su regla, severidad, componente afectado y guía de arreglo.
2. Identificar el repositorio y la tecnología (Android, iOS o una feature de React Native). Si acá se falla, el resto no importa.
3. Localizar el código afectado con RAG sobre una base vectorial del código.
4. Generar un arreglo y abrir un PR que explique el problema, la regla, el cambio y por qué lo resuelve.
5. Una persona lo revisa. Aprueba, pide cambios o rechaza.

Cada ejecución deja un informe que dice qué se arregló, qué se saltó y qué falló.

Resultado

Los equipos pudieron empezar a trabajar en accesibilidad en cuestión de días, sin esperar una infraestructura perfecta. Se empezaron a ver las violaciones por plataforma y por feature. Y la accesibilidad pasó de ser un reclamo de auditoría a ser una parte del flujo normal de desarrollo.

Sobre la IA, prefiero no exagerar. Propone, una persona decide. Si sale mal, sale en un PR, donde es barato corregirlo.

Qué haría distinto

Haría más visible desde el primer día quién es el dueño de cada hallazgo. Una lista de problemas sin dueño es un cementerio.

Y probaría con usuarios que usan lectores de pantalla antes de celebrar. Una herramienta detecta lo que sabe buscar; una persona con un lector de pantalla encuentra lo que importa.