Los test automáticos de accesibilidad son herramientas que evalúan si un sitio web cumple con los criterios del estándar internacional WCAG. Son útiles para developers, equipos de QA y diseñadores que quieren detectar errores antes de enviar código a producción.

Antes de revisar cada herramienta, conviene entender la base sobre la que todas trabajan: el estándar WCAG.

¿Qué es WCAG y por qué importa en accesibilidad?

WCAG (Web Content Accessibility Guidelines) es el estándar mundial creado por la W3C a finales de los 90. Es la guía base para definir si algo es accesible y la usan distintas leyes en el mundo para construir sus propias normativas. También es la referencia que toman los test manuales y automáticos.

Dentro de WCAG encuentras prácticas como el skip link (también llamado skip navigation), que permite saltar bloques de navegación repetidos. Existen distintos niveles de conformidad que cambian según quién sea tu audiencia objetivo [00:18].

¿Qué es WCAG? Es el estándar internacional de accesibilidad creado por la W3C. Define criterios para que un sitio sea usable por todas las personas, incluidas aquellas con discapacidad.

¿Cómo funciona WAVE para evaluar accesibilidad?

WAVE (Web Accessibility Evaluation Tool) es un producto de WebAIM, online y gratuito [01:13]. Cuando corres un test, obtienes un pantallazo general del estado del sitio con información sobre semántica, headings y párrafos.

Entre lo que reporta encuentras:

• Detalles sobre aria-labels bien o mal usados.
• Textos alternativos de imágenes.
• Errores de contraste.
• Errores de textos alternativos redundantes.

La visualización de la página testeada con los detalles superpuestos hace que sea fácil identificar a qué elemento se refiere cada falla. Cuidado con los falsos positivos en colores, sobre todo cuando hay degradados de fondo con texto encima: la herramienta puede no interpretarlos correctamente [02:31].

¿Qué hace Lighthouse y cómo se integra al pipeline?

Lighthouse, también conocido como web.dev, es un producto de Google integrado en Chrome DevTools que permite auditar accesibilidad, performance, progressive web apps, mejores prácticas y seguridad [02:51].

Para accesibilidad usa como base Axe-core. Es más simple que WAVE: te entrega un listado de errores con instrucciones para arreglarlos y un puntaje del 1 al 100. Algunos errores pesan más que otros; por ejemplo, la falta de foco visual se considera más grave que la ausencia de un skip navigation.

Además del puntaje, encuentras:

• Passed audits: lo que hiciste bien.
• N/A (not applicable): tests que no aplican (por ejemplo, no se evalúan textos alternativos si no hay imágenes).
• Lista de chequeos manuales adicionales.

Lighthouse tiene una API disponible en npm y GitHub que puedes agregar a tu pipeline de integración continua. Allí defines un threshold: un mínimo del puntaje. Si envías una nueva feature y el test devuelve menos de 70, por ejemplo, el pipeline falla y te avisa [04:39].

¿Para qué sirve un threshold en Lighthouse? Para evitar que código nuevo introduzca errores de accesibilidad. Si el puntaje baja del mínimo definido, el pipeline falla y bloquea el deploy.

Nunca busques 100 de 100. La meta es tener una buena base y no bajarla.

¿Por qué Axe es la herramienta más confiable de accesibilidad?

Axe es desarrollada por Deque, empresa estadounidense reconocida en la industria que también ofrece Deque University, axe-con (conferencia anual online) y Axe Monitor [05:46]. Es considerada la herramienta de testeo automático más confiable y completa, al punto de que Lighthouse usa Axe-core por debajo: cuando corres Lighthouse, en realidad estás corriendo Axe con otra interfaz.

¿Cómo se usa la extensión de navegador de Axe?

Disponible en Firefox, Chrome y Edge. Permite testear la página en distintos estados:

• Página en estado normal.
• Con un submenú o modal abierto.
• En distintas posiciones de scroll.
• En diferentes tamaños de pantalla.

Un detalle muy útil: tiene un inspector de elementos propio. Al dar clic en un error, hace highlight sobre el elemento exacto que falla y te muestra cómo resolverlo [07:43].

¿Cómo se integra Axe a los unit tests?

La API se consigue por npm o GitHub. Con jest-axe puedes unir la librería core de Axe con Jest, lo que permite agregar tests de accesibilidad directamente a tus unit tests en proyectos React (por ejemplo, junto a React Testing Library) [07:08].

Los resultados se categorizan por:

• Versión de WCAG (2.0, 2.1).
• Leyes específicas como la Sección 508 de Estados Unidos.
• Nivel de impacto: críticos, serios, moderados y menores.

Lo ideal es priorizar primero los críticos y serios. Pero si con una línea de código arreglas 20 errores menores, hazlo enseguida.

¿Qué linters de accesibilidad puedo usar en mi editor?

Los linters atajan errores antes de que lleguen al repositorio. Se integran con Visual Studio Code y otros editores, evitando que hagas commit de código incorrecto [08:30].

Durante mucho tiempo el referente fue react-a11y, pero hoy se recomienda eslint-plugin-jsx-a11y, un plugin de ESLint pensado para accesibilidad. Si buscas react-a11y en npm, te va a redirigir a Axe Core en su versión React.

Caso real: Lighthouse en el pipeline de producción

En una empresa con la que trabajé (a la que llamamos Manzana), implementamos Lighthouse en el pipeline de envío a producción con un valor base de 80 [09:25]. Si alguien enviaba código que bajaba ese puntaje a 75, el pipeline fallaba y no se podía deployar.

Es un método un poco brusco, pero efectivo: traslada la responsabilidad de mantener la accesibilidad al equipo que envía código. ¿Has implementado tests automáticos de accesibilidad en tu proyecto? Cuéntame qué herramienta te dio mejores resultados.