axe-core
También: axe
Motor de pruebas de accesibilidad automatizado de código abierto desarrollado por Deque, utilizado por extensiones de navegador (axe DevTools, Accessibility Insights), scripts de integración continua y Lighthouse. Detecta entre el 30 % y el 40 % de los problemas de WCAG.
axe-core es el motor de pruebas de accesibilidad automatizado de código abierto desarrollado por Deque Systems. Impulsa un amplio ecosistema de herramientas de prueba — extensiones de navegador (axe DevTools, Accessibility Insights), scripts de integración continua (axe-cli, jest-axe, cypress-axe, playwright-axe) y, sobre todo, la auditoría de accesibilidad de Lighthouse.
Durante la última década, axe-core ha sido el verificador de accesibilidad automatizado más desplegado del mundo. La mayoría de las canalizaciones de integración continua relacionadas con la accesibilidad que existen hoy en día ejecutan axe-core por debajo, a menudo sin que el equipo lo sepa.
En qué destaca axe-core
El conjunto de reglas de axe-core es conservador por diseño: una regla se incluye únicamente cuando su tasa de falsos positivos es esencialmente cero. Eso convierte a axe-core en una compuerta de integración continua fiable — cuando señala una violación, la violación es real y el equipo puede actuar sin preocuparse por comprobaciones inestables.
Entre las reglas que axe-core detecta de forma fiable se incluyen:
- Etiquetas ausentes o vacías en controles de formulario.
- Atributos alt ausentes (e incluyendo alt claramente inútil como nombres de archivo).
- Contraste de color insuficiente (texto y componentes de interfaz).
- ARIA no válido — roles inexistentes, propiedades requeridas ausentes, estructuras de elementos hijo no permitidas.
- IDs duplicados que rompen las referencias ARIA.
- Atributo de idioma ausente en
<html>. - Botones sin nombre accesible.
- Campos de formulario sin etiqueta programática.
- Enlace vacío (
<a href>...</a>sin texto ni alt). - Saltos de nivel de encabezado y ausencia de
<h1>en algunas configuraciones.
Esa lista cubre un porcentaje significativo de los fallos de accesibilidad más evidentes. Ejecutar axe-core en integración continua los detecta en el momento de la revisión del código, no en el de la auditoría.
El techo
Los propios autores de axe-core son explícitos al respecto: las herramientas automatizadas pueden detectar como máximo entre el 30 % y el 40 % de los problemas de WCAG. El resto requiere criterio humano y pruebas con tecnología de asistencia.
En concreto, axe-core no puede detectar:
- Texto alternativo incorrecto — puede indicar que alt está ausente, pero no
que
alt="hamburger icon"es incorrecto para un botón que abre un menú. - Texto de enlace engañoso — los enlaces «Haga clic aquí» son correctos según la especificación, aunque inútiles para los usuarios de lectores de pantalla.
- Orden de foco deficiente — un orden de tabulación que no coincide con el orden visual es un fallo del criterio 2.4.3 que ningún verificador estático puede detectar.
- Estructura de encabezados incorrecta — axe-core detecta la ausencia de h1 y los saltos de nivel, pero no puede determinar que una página ha usado h2 donde debería haber usado h1.
- Contenido que solo funciona para ciertos grupos de usuarios — accesible según WCAG pero inutilizable para personas con baja visión, discapacidad cognitiva, etc.
Un sitio con cero violaciones en axe-core es necesario para la accesibilidad, pero no suficiente. El trabajo restante — orden de foco, calidad del contenido, comportamiento con lectores de pantalla, pruebas con usuarios reales — es lo que ocupa la mayor parte del tiempo.
Cómo usar axe-core operativamente
Tres patrones de despliegue funcionan bien conjuntamente:
- En el editor. axe DevTools y Accessibility Insights se ejecutan bajo demanda contra el DOM renderizado en una pestaña del navegador. Se usa durante el desarrollo.
- En integración continua. axe-cli, jest-axe, cypress-axe o playwright-axe fallan la compilación ante nuevas violaciones. Se usa para prevenir regresiones.
- En el momento de la auditoría. Los auditores externos ejecutan axe-core como punto de partida y añaden pruebas manuales por encima. Se usa para validar el nivel de referencia automatizado.
La combinación mantiene en cero los problemas detectables automáticamente mientras un programa de accesibilidad real gestiona el resto.