Pruebas de accesibilidad automatizadas y manuales en el ciclo de vida de desarrollo de CI/CD

La accesibilidad que se verifica solo una vez al año, en una revisión manual única, casi siempre se erosiona rápidamente: cualquier pequeña actualización de código puede romper algo que ya estaba reparado. La solución: incorporar las pruebas de accesibilidad en el propio proceso de desarrollo (CI/CD) como un paso automatizado, de modo que los problemas se detecten antes de que lleguen a producción. Este artículo explica cómo.

Por qué un cheque único no es suficiente

Un equipo de desarrollo que envía actualizaciones cada semana, o a veces todos los días, no puede depender de una auditoría de accesibilidad anual para mantener el cumplimiento continuo. Un nuevo componente agregado sin tener en cuenta la accesibilidad, o un cambio de CSS que accidentalmente reduce el contraste, puede alterar la accesibilidad que ya estaba corregida, y nadie se da cuenta hasta que un usuario o una queja lo revela. El mismo principio se aplica también a los documentos; consulte nuestra guía sobreerrores comunes de mapeo.

Qué herramientas automatizadas en el proceso de CI/CD pueden detectar

Herramientas como axe-core, Pa11y o Lighthouse CI pueden ejecutarse automáticamente en cada solicitud de extracción o antes de cada implementación; en cuestión de segundos verifican cosas como: contraste de color, etiquetas ARIA incorrectas o duplicadas, texto alternativo faltante, etiquetas de formulario faltantes y orden de encabezado incorrecto. Si la verificación falla, la solicitud de extracción se bloquea automáticamente para que no pueda fusionarse, al igual que una revisión de código regular o una prueba unitaria fallida.

Donde todavía se necesitan pruebas manuales

Al igual que con las pruebas de documentos, las herramientas automatizadas en el proceso de CI/CD detectan problemas estructurales claros, pero no pueden juzgar la experiencia real del usuario: si la navegación con el teclado tiene sentido, si un lector de pantalla "cuenta una historia coherente" en la página o si un componente personalizado (como un carrusel o modal) es realmente utilizable en el mundo real. Por eso vale la pena combinar las comprobaciones automáticas continuas con una auditoría manual periódica (trimestral, por ejemplo).

Cómo implementarlo en la práctica

1. Elija una herramienta de prueba que se ajuste a su pila de tecnología (axe-core para la mayoría de los proyectos de JavaScript, Lighthouse CI para proyectos basados en navegador).
2. Ejecútelo como un paso en su canal de CI, generalmente como una acción de GitHub, un trabajo de CI de GitLab o un paso equivalente en cualquier herramienta de CI/CD que utilice.
3. Establezca un umbral de falla claro (por ejemplo: no hay problemas de nivel "crítico" por núcleo de hacha) antes de que la verificación se convierta en un bloqueador.
4. Cubra también sus archivos PDF: si su organización genera documentos automáticamente (facturas, informes), considere agregar escaneo automático para ellos también, como parte del proceso de publicación.