Pruebas de accesibilidad en CI/CD

El defecto de accesibilidad más barato es el que nunca llega a tu rama principal. Para cuando una auditoría periódica saca a la luz una etiqueta de formulario ausente o un orden de foco roto, el código infractor ya se ha publicado, otras tres funcionalidades se han construido sobre él y posiblemente ya haya frustrado a un usuario real. La corrección es más difícil, el riesgo de regresión es mayor y el coste —en tiempo de ingeniería y en confianza— se ha multiplicado.

Las pruebas automatizadas de accesibilidad en CI/CD invierten esa economía. En lugar de descubrir problemas semanas o meses después aguas abajo, detectas los automatizables en el momento en que se introducen, en el mismo pull request que los introduce. Este artículo es una guía práctica para equipos de ingeniería: cómo desplazar la accesibilidad a la izquierda, dónde colocar las comprobaciones en la canalización, cómo bloquear compilaciones sin enterrar a los desarrolladores en ruido, cómo integrar con los principales sistemas de CI y —algo crucial— dónde se detiene la automatización y las pruebas humanas tienen que tomar el relevo.

Por qué desplazar la accesibilidad a la izquierda

«Shift left» significa mover las comprobaciones de calidad más temprano en el ciclo de vida del desarrollo, más cerca del momento en que se escribe el código. El principio se entiende bien para la seguridad y para las pruebas funcionales, y la accesibilidad se beneficia de él por exactamente las mismas razones.

Cuando la accesibilidad se trata como una actividad de auditoría en una fase tardía, tres cosas salen mal. Primero, los defectos se acumulan: una única auditoría en el momento del lanzamiento produce un retraso desalentador, y el equipo lo prioriza frente a la presión de publicar: la accesibilidad suele perder. Segundo, se pierde el contexto; el desarrollador que introdujo un botón de icono sin etiqueta hace tres sprints ha seguido adelante, y reconstruir la intención es lento. Tercero, las mismas clases de problema reaparecen con cada nueva funcionalidad, porque nada en el flujo de trabajo diario las previene.

Colocar comprobaciones en CI/CD cierra ese ciclo. La retroalimentación llega mientras el código está fresco y el autor todavía está en contexto. Las regresiones se bloquean antes de que se compongan. Y la accesibilidad se convierte en una puerta de calidad normal y automatizada —como las pruebas unitarias, la comprobación de tipos y el linting— en lugar de un evento especial que le ocurre a otras personas. Si quieres el panorama más amplio de dónde encajan estas comprobaciones, nuestra visión general de la accesibilidad en el ciclo de vida del desarrollo de software mapea cada fase desde el diseño hasta el lanzamiento.

Aquí también importa una expectativa clara. Desplazar a la izquierda no significa desplazar todo a la izquierda. La automatización gestiona una porción específica y valiosa de la conformidad con WCAG 2.2. El resto sigue requiriendo personas. Volveremos a esa frontera en detalle.

Comprobaciones en cada pull request

El lugar de mayor apalancamiento para ejecutar comprobaciones de accesibilidad es el pull request. Es donde los revisores ya están mirando, donde el diff es pequeño y revisable, y donde bloquear es socialmente aceptable porque nadie espera que una rama sin terminar sea perfecta.

Una buena configuración a nivel de PR tiene tres propiedades:

• Rápida. Las comprobaciones de PR compiten con la capacidad de atención del desarrollador. Limítalas a lo que ha cambiado —las páginas o componentes afectados por el diff— en lugar de rastrear todo el sitio en cada push. Un barrido completo del sitio pertenece a una programación, no a cada commit.
• En línea. Los hallazgos deben aparecer donde el desarrollador trabaja: como comentario en el PR, una anotación en el archivo modificado o una comprobación de estado con un enlace al detalle. Un resultado enterrado en un registro de CI que nadie abre es un resultado sobre el que nadie actúa.
• Accionable. Cada hallazgo necesita la regla que infringió, el elemento que encontró, el criterio de éxito de WCAG al que se asigna e, idealmente, una sugerencia de corrección. «regla button-name de axe-core: este <button> no tiene nombre accesible» es útil; «error de accesibilidad» no lo es.

El escáner de QualiBooth está construido para funcionar exactamente en este modo: invocado desde tu canalización mediante CLI o API, reportando hallazgos de vuelta al pull request y rastreándolos en paneles para que el equipo pueda ver cómo la deuda de accesibilidad tiende a la baja con el tiempo. La mecánica de configurar esto en distintas plataformas se cubre en nuestro servicio de integración de accesibilidad en CI/CD.

Puertas de compilación y umbrales

Reportar hallazgos es necesario pero no suficiente. Un informe que no bloquea nada será, bajo la presión de los plazos, ignorado. Una puerta —una comprobación que puede hacer fallar la compilación— es lo que da dientes a la accesibilidad en la canalización. El arte está en elegir sobre qué bloquear.

El enfoque ingenuo es hacer fallar la compilación ante cualquier infracción de accesibilidad. En un proyecto desde cero eso puede funcionar. En una base de código existente con un retraso de problemas conocidos, es un desastre: la primera ejecución falla, cada compilación falla para siempre, y el equipo desactiva la comprobación en un día. La puerta tiene que calibrarse.

Una estrategia de umbrales viable se ve así:

• Bloquear solo ante regresiones nuevas y graves. Compara el escaneo actual con una línea base (cubierta en la siguiente sección). Haz fallar la compilación cuando el diff introduce infracciones nuevas en o por encima de una severidad que elijas —por ejemplo, crítica y grave— y deja pasar como advertencias los problemas de menor severidad o preexistentes.
• Diferenciar severidades. No todas las infracciones son iguales. Una trampa de teclado completa justifica un fallo duro; un aviso menor de buenas prácticas podría ser informativo. Asigna los niveles de impacto de las reglas al comportamiento de la puerta para que la puerta refleje el daño real al usuario.
• Permitir excepciones acotadas, deliberadamente. A veces un problema conocido se rastrea y se programa. Da soporte a un mecanismo de supresión explícito y revisable —anotado y con límite temporal— en lugar de dejar que los desarrolladores desactiven toda la comprobación de forma general.

El objetivo es una puerta en la que el equipo confíe. Una puerta que falla por buenas razones se respeta; una puerta que falla por ruido se esquiva. Ajustar los umbrales a tu base de código es parte de construir esa confianza, y es una parte central de la mejora de procesos de accesibilidad.

Fijar una línea base de los problemas existentes

Casi ninguna base de código real comienza con cero defectos de accesibilidad. La pregunta práctica no es «¿cómo no tenemos problemas?» sino «¿cómo dejamos de añadir nuevos mientras saldamos los viejos?». La línea base es la respuesta.

Una línea base es una instantánea registrada de los problemas de accesibilidad que ya existen cuando activas la puerta. Cada escaneo posterior se compara con ella. La puerta falla ante lo que es nuevo respecto a la línea base; el retraso existente se reconoce pero no bloquea las compilaciones. Esto te permite activar la aplicación de inmediato sin detener el desarrollo.

Algunas prácticas mantienen las líneas base saludables:

• Haz de la línea base un artefacto rastreado. Súbela al repositorio o guárdala en tu plataforma de accesibilidad para que los cambios sean visibles y revisables, no silenciosos.
• Deja que solo se encoja. La línea base debe reducirse a medida que se corrigen los problemas, nunca crecer para absorber nuevas infracciones. Si una corrección elimina un problema, regenera la línea base para que reintroducir el problema más tarde haga fallar la puerta.
• Programa la reducción deliberada. El retraso capturado en la línea base no desaparece por sí solo. Combina la puerta con un plan para reducirlo: asignación de sprints, un epic de limpieza dedicado o una cadencia de auditoría recurrente. Nuestra explicación sobre auditorías de accesibilidad recurrentes describe cómo estructurar ese trabajo continuo.

La línea base es lo que hace que «activar la puerta hoy» sea realista para un equipo que ha estado publicando durante años.

Pruebas de componentes y Storybook

Las comprobaciones de PR contra páginas renderizadas son valiosas, pero detectan los problemas tarde: después de que un componente defectuoso ya se haya compuesto en una página. Probar a nivel de componente los detecta en el origen, antes de que un solo error de nombre accesible se propague a cuarenta pantallas.

Si tu equipo usa un explorador de componentes como Storybook, es un arnés ideal para esto. Cada historia renderiza un componente de forma aislada, en sus diversos estados, que es precisamente lo que un motor de accesibilidad automatizado necesita: un DOM determinista y enfocado para evaluar.

Una configuración típica de pruebas de componentes:

• Ejecutar una comprobación de accesibilidad en cada historia. Herramientas como el addon de a11y de Storybook (construido sobre axe-core) pueden escanear cada historia automáticamente, y las mismas comprobaciones pueden ejecutarse sin interfaz en CI para que las infracciones de componentes hagan fallar la canalización, no solo la UI local.
• Cubrir estados, no solo el predeterminado. Renderiza y prueba el estado deshabilitado, el estado de error, el estado de carga, los estados abierto y cerrado. Los errores de accesibilidad adoran los estados límite: un mensaje de error sin asociación programática, un modal que no atrapa el foco.
• Corregir una vez, beneficiarse en todas partes. Un componente correctamente construido y probado se convierte en una garantía reutilizable. Cada página que lo consume hereda la corrección. Este es el lugar de mayor apalancamiento para invertir, y se combina de forma natural con el conjunto de herramientas de accesibilidad y el software de escaneo de accesibilidad más amplios que tu equipo ya utiliza.

Las pruebas de componentes no reemplazan las pruebas a nivel de página —la composición introduce problemas que ningún componente aislado puede revelar, como regiones de referencia (landmark) duplicadas o un esquema de encabezados general roto— pero reducen drásticamente cuántos defectos llegan siquiera a la página.

Integración con tu sistema de CI

El patrón de integración es el mismo en todas las plataformas: instalar o invocar el escáner, ejecutarlo contra el objetivo (una URL, un artefacto compilado o historias de componentes) y traducir su código de salida e informe en un pass/fail de la canalización y un artefacto visible para el desarrollador. Como QualiBooth se integra mediante CLI y API, encaja en prácticamente cualquier sistema. Así difieren los principales en la práctica.

GitHub Actions

La configuración más común. Añade un flujo de trabajo activado en pull_request, levanta tu app (o despliega una vista previa), ejecuta la CLI de accesibilidad contra ella y publica los resultados como una ejecución de comprobación o comentario en el PR. GitHub Actions facilita las anotaciones en línea y las comprobaciones de estado requeridas, por lo que una puerta de accesibilidad fallida puede bloquear la fusión mediante reglas de protección de ramas. Cachear los binarios del navegador y las dependencias mantiene el trabajo rápido.

GitLab CI

Define un trabajo accessibility en .gitlab-ci.yml, normalmente en una etapa dedicada después de la compilación. GitLab puede mostrar los resultados en el widget de merge request, y puedes almacenar el informe JSON como artefacto del trabajo para descarga y seguimiento de tendencias. Las reglas de aprobación de merge request te permiten hacer que la puerta sea bloqueante.

Jenkins

En un Jenkinsfile, añade una etapa que ejecuta el escáner y archiva el informe. Jenkins es común en entornos empresariales y on-premise, donde la capacidad de ejecutar todo detrás del cortafuegos importa. Usa el plugin de publicación apropiado para renderizar los resultados, y haz fallar la etapa ante un código de salida distinto de cero para bloquear la compilación.

CircleCI

Añade un trabajo a .circleci/config.yml, usa un ejecutor con un navegador disponible y almacena el informe con store_artifacts. Los workflows de CircleCI te permiten ejecutar el trabajo de accesibilidad en paralelo con otras comprobaciones para que no extienda el tiempo total de la canalización, y puedes exigir que pase antes de que se ejecute un trabajo de despliegue.

Azure DevOps

Añade una tarea a tu canalización YAML que ejecute la CLI, luego publica el informe con la tarea de publicación de artefactos. Las políticas de ramas de Azure DevOps pueden exigir que la comprobación de accesibilidad pase antes de que se complete un pull request, dándote la misma puerta dura que las demás plataformas.

Sea cual sea el sistema que uses, la estrategia de alcance correcta es consistente: escaneos rápidos de alcance limitado al cambio en los pull requests; un rastreo más completo en una programación nocturna o previa al lanzamiento. Ayudamos a los equipos a configurar esto de extremo a extremo como parte de la integración de accesibilidad en CI/CD, y asesoramos a los equipos de plataforma que prefieren implementarlo ellos mismos.

Reducir los falsos positivos

Nada destruye la confianza de un equipo en una puerta de accesibilidad más rápido que los falsos positivos. Si la comprobación marca no-problemas, los desarrolladores aprenden a ignorarla, suprimirla por completo o esquivarla, y la puerta se convierte en teatro. Mantener la señal alta no es opcional; es lo que hace que todo el esfuerzo sea duradero.

Los motores automatizados son conservadores por diseño y a veces reportan cosas que no son fallos reales en contexto. Fuentes comunes de ruido:

• Contenido oculto o aún no renderizado. Los elementos detrás de un menú cerrado o una sección de carga diferida pueden marcarse fuera de contexto. Escanea los estados realmente renderizados e interactuados.
• Componentes personalizados que el motor malinterpreta. Un control personalizado correctamente implementado con ARIA adecuado puede aún así disparar una regla genérica. Estos merecen una excepción revisada y documentada, no una desactivación general.
• Temporización dinámica. Escanear antes de que la app se haya hidratado produce fallos fantasma. Espera a un estado estable antes de evaluar.
• Incrustaciones de terceros. Los problemas dentro de un iframe que no controlas deben rastrearse por separado, para que tu puerta mida tu calidad.

Las defensas prácticas son ajustar el conjunto de reglas a tu stack, acotar las supresiones de forma estrecha y revisable, escanear estados realistas y bloquear solo sobre las severidades que representan un daño genuino al usuario. Acertar con esta calibración para una base de código específica es exactamente el tipo de trabajo que cubre nuestra consultoría de accesibilidad.

El límite honesto: la automatización detecta solo parte de WCAG

Aquí está la frontera que todo equipo de ingeniería necesita interiorizar, y que nunca difuminaremos: las pruebas automatizadas detectan de forma fiable solo alrededor del 30–40 % de los criterios de éxito de WCAG. El otro 60–70 % requiere juicio humano, y ninguna cantidad de ingeniería de canalización cambia eso.

La razón es estructural. La automatización destaca en hechos comprobables por máquina: ¿hay texto alternativo en esta imagen? ¿Cumple este texto la relación de contraste? ¿Tiene este campo de formulario una etiqueta programática? ¿Está presente el marcado de encabezados? Son comprobaciones reales e importantes, y detectarlas automáticamente en cada PR es genuinamente valioso.

Pero muchísimos requisitos de WCAG son semánticos y experienciales, y una máquina no puede evaluarlos:

• ¿Es el texto alternativo significativo, o es "image123.jpg"? Un escáner confirma que el texto alternativo existe; solo una persona puede juzgar si transmite la información correcta.
• ¿Tiene sentido el orden de foco para alguien que navega por teclado, o está técnicamente presente pero es ilógico?
• ¿Es la página realmente usable con un lector de pantalla, de principio a fin, para completar una tarea real?
• ¿Ayudan los mensajes de error a un usuario confundido a recuperarse, o están meramente asociados correctamente en el marcado?
• ¿Es el contenido comprensible, el lenguaje claro, la interacción predecible?

Estas son preguntas sobre la experiencia humana, y se responden mediante pruebas humanas, idealmente mediante auditorías realizadas por personas con discapacidad, que usan tecnología asistiva a diario y sacan a la luz problemas que ninguna herramienta automatizada y ningún desarrollador vidente notaría jamás. Una auditoría manual de accesibilidad exhaustiva sigue siendo el fundamento de la conformidad real.

Así que el modelo mental correcto es por capas, no uno u otro:

1. La automatización de CI/CD evita que los problemas comprobables por máquina lleguen a publicarse y protege contra la regresión, de forma continua, económica, en cada cambio.
2. Las pruebas manuales y con tecnología asistiva cubren la mayoría experiencial de WCAG que la automatización no puede alcanzar.
3. Las auditorías recurrentes vuelven a verificar el panorama completo a medida que el producto evoluciona, porque la conformidad es un objetivo móvil, no un certificado único.

Esta estratificación es también lo que esperan los regímenes del mundo real. Ya sea que tu obligación provenga del European Accessibility Act, la ADA o la Section 508, la conformidad se mide frente al estándar completo, no frente a la porción que un escáner resulta cubrir. Una canalización en verde es necesaria, no suficiente.

Una cosa más que conviene dejar explícita: las superposiciones de accesibilidad (overlays) —los widgets de JavaScript que prometen conformidad instantánea— no son sustituto de ninguna capa anterior, y QualiBooth no las respalda. No corrigen el código subyacente, frecuentemente interfieren con las mismas tecnologías asistivas de las que dependen los usuarios y no hacen nada por los criterios experienciales que más importan. La accesibilidad real proviene de construirla dentro del producto, que es exactamente lo que entrega la integración de CI/CD más las pruebas humanas.

Poniéndolo todo junto

Una canalización de accesibilidad madura no es una herramienta ni una regla: es un conjunto de capas que cada una hace aquello en lo que es buena:

• Las comprobaciones a nivel de componente (p. ej. en Storybook) detectan los defectos en el origen.
• Las comprobaciones a nivel de PR dan retroalimentación rápida, en línea y accionable en cada cambio, acotada al diff.
• Las puertas de compilación con líneas base bloquean nuevas regresiones graves sin detener el trabajo en los problemas heredados.
• Los barridos completos programados detectan problemas a nivel de composición y rastrean toda la base de código a lo largo del tiempo.
• Los paneles de tendencias convierten la salida bruta de CI en una imagen clara de la deuda y el progreso.
• Las auditorías humanas cubren el 60–70 % de WCAG que la automatización no puede estructuralmente.

Empieza poco a poco. Añade una única comprobación de PR en las páginas o componentes que más importan, fija la línea base de los problemas existentes para que la puerta esté en verde el primer día, y avanza desde ahí. El objetivo es un flujo de trabajo donde las regresiones de accesibilidad se vuelvan tan difíciles de fusionar como las pruebas unitarias fallidas, y donde los problemas que la automatización no puede detectar se enrutan a las personas que sí pueden.

Si quieres ayuda para diseñar o implementar esa canalización, nuestro servicio de integración de accesibilidad en CI/CD hace exactamente esto, y puedes ver el motor de escaneo que hay detrás en un escaneo gratuito o una demo en vivo.

Preguntas frecuentes

¿Las pruebas automatizadas de accesibilidad reemplazan las auditorías manuales?

No, y cualquier proveedor que afirme lo contrario te está engañando. Las comprobaciones automatizadas detectan de forma fiable solo alrededor del 30–40 % de los criterios de éxito de WCAG: los comprobables por máquina. La mayoría experiencial, como si el texto alternativo es significativo o si un usuario de lector de pantalla puede completar una tarea, requiere pruebas humanas. La automatización de CI/CD previene regresiones y detecta los problemas fáciles temprano; no certifica la conformidad por sí sola.

¿No ralentizarán las comprobaciones de accesibilidad nuestras compilaciones?

No si están correctamente acotadas. Ejecuta escaneos rápidos de alcance limitado al cambio en los pull requests y reserva los rastreos completos del sitio para una programación nocturna o previa al lanzamiento. Los trabajos de accesibilidad también pueden ejecutarse en paralelo con tus otras comprobaciones de CI, así que añaden poco al tiempo total de la canalización. Cachear los binarios del navegador y las dependencias mantiene bajo el coste por ejecución.

¿Cómo evitamos que la puerta falle ante nuestro retraso existente?

Fíjale una línea base. Registra una instantánea de los problemas que existen cuando activas la puerta, y configura la puerta para que falle solo ante infracciones nuevas respecto a esa línea base. Tu retraso existente se reconoce y rastrea pero no bloquea las compilaciones, así que puedes habilitar la aplicación de inmediato y reducir el retraso en una programación deliberada.

¿Con qué sistemas de CI puede integrarse esto?

Con los comunes —GitHub Actions, GitLab CI, Jenkins, CircleCI y Azure DevOps— y efectivamente con cualquier otro, porque QualiBooth se integra mediante CLI y API. El patrón es el mismo en todas partes: ejecutar el escáner, traducir su código de salida en un pass/fail y mostrar el informe donde los desarrolladores lo verán.

¿Por dónde deberíamos empezar?

Añade una comprobación a nivel de PR en tus páginas de mayor tráfico o tu biblioteca de componentes compartida, fija la línea base de los problemas actuales, bloquea solo ante nuevas regresiones graves y expande desde ahí. Combínala desde el principio con un plan de pruebas manuales, ya que la automatización cubre solo parte del estándar. Si prefieres no construirlo solo, habla con un experto sobre implementarlo en tu canalización, o compara opciones en nuestra página de precios.