Testing de accesibilidad web con axe y Playwright

No, y creer que sí es el error más común. Las herramientas automáticas de accesibilidad, incluida axe, detectan solo una parte de los problemas, del orden de un tercio a la mitad según las mediciones, porque solo pueden comprobar lo que es verificable mecánicamente a partir del HTML: imágenes sin texto alternativo, contraste insuficiente, campos sin etiqueta, encabezados mal jerarquizados. Pasar todas esas comprobaciones significa que el sitio no tiene los errores más evidentes, no que sea accesible. Cosas fundamentales como si el orden de tabulación tiene lógica, si el contenido se entiende con un lector de pantalla o si un texto alternativo describe de verdad la imagen requieren el juicio de una persona. La automatización es una red que atrapa lo barato y libera tiempo, no un certificado de accesibilidad.

Son cosas distintas y complementarias. Las WCAG son las Pautas de Accesibilidad para el Contenido Web del W3C: el estándar internacional que define, en criterios concretos y organizados por niveles, qué hace accesible a un sitio. Son la norma, no una herramienta. axe, en cambio, es un motor de reglas de código abierto mantenido por Deque que analiza una página y comprueba automáticamente el cumplimiento de aquellas pautas que se pueden verificar de forma mecánica, reportando cada violación con su regla, su gravedad y el elemento que la provoca. Dicho simple: las WCAG dicen qué debe cumplirse, y axe comprueba automáticamente la parte de ese qué que una máquina puede evaluar. Para la parte que una máquina no puede evaluar, sigue haciendo falta una persona que conozca las WCAG.

Porque integrarlo en Playwright hace que las comprobaciones de accesibilidad corran automáticamente en cada prueba, sin que nadie tenga que acordarse de abrir una extensión y ejecutarla a mano página por página. Es el mismo motor de reglas que usan muchas extensiones de navegador, pero al vivir dentro de la suite de pruebas automatizadas se ejecuta con cada cambio y puede formar parte del pipeline de integración continua, frenando las regresiones antes de que lleguen a producción. La extensión de navegador sigue siendo útil para una revisión puntual y exploratoria durante el desarrollo, pero para una red de seguridad permanente que proteja el sitio a lo largo del tiempo, la integración automatizada es mucho más efectiva porque no depende de que alguien se acuerde de correrla.

Con una integración gradual y realista. Si se activa de golpe sobre todo un sitio con problemas heredados, la prueba falla por cientos de violaciones el primer día y termina ignorada o desactivada. Lo que funciona es empezar por las páginas más usadas, fijar una línea base que registre las violaciones existentes como deuda conocida y hacer que la prueba falle solo ante violaciones nuevas, de modo que se frene la regresión sin bloquear el trabajo. También conviene acotar el estándar a un nivel concreto de las WCAG para evitar ruido, y correr la comprobación dentro del pipeline como una prueba más. La idea es que la accesibilidad automatizada sea una red de seguridad que el equipo valora, no un obstáculo que aprende a esquivar.

Tres, como mínimo, porque cubren justamente lo que la automatización no puede juzgar. La primera es navegar el sitio usando solo el teclado, sin ratón, para comprobar que se llega a todos los elementos interactivos, que se ve claramente dónde está el foco en cada momento y que el orden en que se recorren los elementos tiene sentido. La segunda es probar el sitio con un lector de pantalla, la tecnología que usan las personas ciegas, para verificar que el contenido se entiende al escucharlo de principio a fin. La tercera es revisar que los textos alternativos de las imágenes no solo existan, cosa que ya comprueba axe, sino que describan de verdad lo que la imagen comunica. Estas revisiones son, en el fondo, testing manual exploratorio aplicado a la accesibilidad.

Es ambas cosas, y conviene no verla como un lujo opcional. Como buena práctica, la accesibilidad amplía el público que puede usar un sitio e mejora la calidad general del producto, porque muchas mejoras de accesibilidad —estructura clara, buen contraste, contenido comprensible— benefician a todo el mundo, no solo a quienes tienen alguna discapacidad. Y como obligación, en muchos países existe legislación que exige que ciertos sitios, especialmente los públicos y los de empresas de cierto tamaño, cumplan con estándares de accesibilidad, con las WCAG como referencia habitual. Además, tratar la accesibilidad desde el principio, empezando por un HTML semántico bien hecho, sale mucho más barato que intentar agregarla al final sobre un sitio que no la contempló.