Garantizar que un sitio web sea accesible no depende solo de revisiones manuales. Las herramientas de testeo automático permiten detectar errores de accesibilidad de forma rápida, repetible y escalable, integrándose incluso en los flujos de trabajo de desarrollo. Conocer el estándar que las respalda y saber cuándo usar cada herramienta marca la diferencia entre un producto inclusivo y uno que excluye usuarios.
¿Qué es WCAG y por qué es la base de todo test de accesibilidad?
WCAG (Web Content Accessibility Guidelines) es el estándar mundial creado por la W3C a fines de los noventa [0:18]. Funciona como la guía de referencia para determinar si un sitio es accesible y es adoptada por distintas leyes de accesibilidad alrededor del mundo. Tanto los tests manuales como los automáticos se basan en este estándar.
Un ejemplo concreto dentro de WCAG es el Skip Link (también llamado skip navigation), que permite a usuarios de teclado saltar directamente al contenido principal [0:50]. WCAG contempla además distintos niveles de conformidad que varían según el público objetivo del producto.
¿Qué herramientas automáticas existen para evaluar accesibilidad?
¿Cómo funciona Wave y qué información ofrece?
Wave (Web Accessibility Evaluation Tool) es un producto gratuito de WebAIM [1:14]. Al correr un test, entrega:
- Un pantallazo general del estado del sitio.
- Información semántica: árbol de headings, párrafos y elementos.
- Detalles sobre Aria Labels, textos alternativos y errores de contraste [1:44].
Lo interesante es que superpone los resultados visualmente sobre la página, lo que facilita identificar exactamente qué elemento presenta cada falla [2:04]. Sin embargo, hay que tener cuidado con los falsos positivos, especialmente en colores con degradados de fondo, donde la herramienta puede no calcular correctamente el contraste [2:26].
¿Qué ventajas tiene Lighthouse frente a otras herramientas?
Lighthouse (también conocido como web.dev) es un producto de Google que permite realizar auditorías de accesibilidad, performance, seguridad y más [2:42]. Antes era una extensión que se debía instalar, pero hoy viene integrada en Chrome y también se puede usar desde su sitio web.
Lighthouse utiliza internamente Axe-core como motor de análisis [3:06]. Es más simple que Wave: entrega un listado de errores con instrucciones para corregirlos y un puntaje del uno al cien. Ese puntaje pondera los errores según su gravedad; por ejemplo, la falta de foco visual pesa más que la ausencia de un skip navigation [3:30].
Además del puntaje, Lighthouse muestra:
- Passed Audits: lo que el sitio hace bien.
- Not Applicable: tests que no se ejecutaron porque no aplican, como verificar textos alternativos en páginas sin imágenes [3:58].
- Un listado de elementos para testear manualmente [4:16].
Lighthouse tiene una API disponible en NPM y GitHub que se puede integrar en pipelines de integración continua [4:22]. Se puede configurar un threshold (mínimo indispensable): si el puntaje cae por debajo de ese valor al enviar código nuevo, el pipeline falla y alerta al equipo [4:36]. Esto evita introducir nuevos errores de accesibilidad con cada feature.
Nunca busquen tener cien de cien [5:00]. El objetivo es establecer una buena base y no bajarla.
¿Por qué Axe es considerada la herramienta más confiable?
Axe, desarrollada por la empresa Deque, es reconocida como la herramienta de testeo automático más confiable y completa de la industria [5:30]. De hecho, cuando se ejecuta Lighthouse, lo que corre internamente es Axe con una interfaz diferente [5:48].
Axe está disponible como:
- Extensión de navegador para Firefox, Chrome y Edge.
- API a través de NPM y GitHub.
La extensión permite testear una página en distintos estados: con un modal abierto, un submenú desplegado o diferentes tamaños de pantalla [6:08]. Además, incluye un inspector de elementos que hace highlight sobre el componente problemático al hacer clic en un error [7:04].
La API se puede combinar con librerías como Jest-Axe para agregar testeos de accesibilidad directamente a los unit tests de proyectos con React Testing Library [6:36].
Los resultados se categorizan por versión de WCAG y pueden filtrarse por leyes específicas de cada país, como la Sección 508 de Estados Unidos [6:52]. Los errores se agrupan en niveles: críticos, serios, moderados y menores. La recomendación es priorizar los críticos primero, aunque si con una línea de código se arreglan veinte errores menores, vale la pena hacerlo de inmediato [7:24].
¿Cómo evitar errores de accesibilidad antes del commit con linters?
Los linters atajan errores antes de que el código llegue al repositorio [7:46]. Se integran con editores como Visual Studio Code. El plugin recomendado actualmente es ESLint-plugin-jsx-a11y, un plugin de ESLint específico para accesibilidad disponible en NPM [8:04]. Anteriormente se usaba React Ally, que ahora redirige a Axe-core en su versión de React.
Como caso de estudio, en una empresa se configuró Lighthouse en el pipeline de envío a producción con un valor base de ochenta puntos [8:30]. Si un deploy bajaba el puntaje, el pipeline fallaba y el código no llegaba a producción. Un enfoque directo, pero efectivo para mantener la accesibilidad como responsabilidad compartida del equipo.
¿Ya integraste alguna de estas herramientas en tu flujo de trabajo? Comparte tu experiencia y qué resultados obtuviste.
