Integración de accesibilidad en CI/CD

El error de accesibilidad más barato es el que nunca se fusiona. La integración de accesibilidad en CI/CD desplaza las pruebas hacia la izquierda, hacia tu pipeline de desarrollo, de modo que las regresiones se detecten automáticamente en cada pull request en lugar de aflorar meses después en una auditoría, o en una reclamación.

Por qué integrar la accesibilidad en CI/CD

La mayoría de los equipos prueban la accesibilidad a posteriori: una auditoría periódica produce una larga lista, el equipo la corrige y luego las mismas clases de problemas vuelven a colarse silenciosamente con las siguientes funciones. Automatizar las comprobaciones en el pipeline rompe ese ciclo. Cada cambio se evalúa a medida que se hace, los desarrolladores reciben retroalimentación mientras el código está reciente y tu conformidad, lograda con esfuerzo, queda protegida frente a regresiones silenciosas.

Cómo funciona

La función Code Analysis de QualiBooth se integra con GitHub Actions. Una vez configurado, el workflow se ejecuta automáticamente en cada push y pull request:

1. Instala la GitHub Action de QualiBooth y añade tu secreto QUALIBOOTH_ORG_UUID.
2. Confirma el archivo de workflow: GitHub activará los escaneos de accesibilidad automáticamente desde ese momento.
3. Los resultados aparecen en el panel Scan Runs de QualiBooth, con búsqueda por repositorio, rama o hash de commit.
4. Cada infracción se ubica en una ruta de archivo y número de línea con gravedad Error o Warning.
5. Cuando se aplica una corrección, el siguiente escaneo marca el problema como corregido: el progreso es medible ejecución a ejecución.

El escaneo basado en ESLint admite actualmente proyectos React, Vue, JavaScript y TypeScript. La compatibilidad con más frameworks y plataformas de CI está en la hoja de ruta.

Qué configuramos

1. Integración con GitHub Actions — la acción de QualiBooth conectada al workflow de tu repositorio.
2. Retroalimentación en los PR — comprobaciones automáticas que comentan los hallazgos directamente en los pull requests.
3. Detección de regresiones — cada análisis se compara con una línea base para que los nuevos problemas se separen claramente del backlog existente.
4. Referencias — una instantánea de los problemas existentes para que apliques puertas a los problemas nuevos, no a todo tu backlog de una vez.
5. Panel de Scan Runs — cada ejecución registrada con rama, commit, recuentos de problemas y seguimiento de problemas corregidos.

Dónde se ejecutan las comprobaciones

• Pull requests — escaneos rápidos de los archivos modificados para una retroalimentación ágil al revisor
• Pushes de rama — monitorización continua para detectar regresiones antes de la revisión del PR
• Comprobaciones pre-merge — detectar nuevas regresiones antes de que lleguen a la rama principal
• Barridos programados — escaneos nocturnos o de versión más completos de toda la aplicación

Un límite honesto

Las pruebas automáticas detectan de forma fiable solo entre el 30 y el 40 % de los criterios de éxito de WCAG. Somos explícitos al respecto: la integración en CI/CD es la forma de evitar que los problemas automatizables lleguen a publicarse y de protegerte frente a las regresiones, pero no sustituye al juicio humano. Nuestra guía sobre pruebas de accesibilidad automatizadas en CI/CD explica dónde se sitúa esa línea en la práctica. La imagen completa surge de combinar las puertas automáticas con auditorías manuales por personas con discapacidad y auditorías periódicas.

Para quién es

Equipos de ingeniería y de plataforma que publican de forma continua y quieren que la accesibilidad sea una puerta de calidad estándar y automática, igual que las pruebas y el linting. Es un componente natural de un programa más amplio de mejora de procesos de accesibilidad.