axe DevTools: auditar accesibilidad en el navegador y qué no detecta
axe DevTools audita accesibilidad en el navegador con el motor axe-core. Qué revisa, qué planes tiene hoy y qué debe revisarse a mano con criterio.
¿Qué hace axe DevTools?
Abres una página en el navegador, lanzas la extensión y recibes una lista de problemas agrupados por gravedad y por criterio WCAG. Cada hallazgo indica el elemento afectado, por qué falla y cómo se corrige. Eso la hace útil para encontrar problemas técnicos concretos: un contraste insuficiente, una imagen sin texto alternativo, un campo de formulario sin etiqueta.
La página oficial describe la extensión como una herramienta de pruebas automatizadas y de pruebas guiadas por IA para encontrar más problemas que la automatización sola (Deque, “axe DevTools”). Esa parte guiada es la que cubre lo que un script no puede decidir.
¿Qué planes tiene hoy?
Según la página oficial de precios de Deque (noviembre de 2026), hay tres opciones (Deque, “Pricing”):
- Extensión gratuita: pruebas automatizadas básicas, página por página.
- Extensión Pro: añade funciones con IA, pruebas guiadas inteligentes, análisis de flujos de usuario e integración con Jira. Tiene una prueba de 14 días con todas las funciones y sin tarjeta; al terminar, la cuenta pasa al plan gratuito.
- Axe DevTools for Web (paquete): incluye todo lo de Pro más conexiones MCP, acceso a linter, integraciones con CI/CD y API. Se contrata a través de ventas.
La página no publica precios de Pro ni del paquete, así que consúltalos con Deque antes de presupuestar.
¿Qué tan completa es la automatización?
Este es el dato que más se malinterpreta. En marzo de 2021 Deque publicó un estudio con unas 2.000 auditorías anonimizadas, más de 13.000 páginas y casi 300.000 incidencias, y concluyó que, en promedio, su automatización cubría por completo el 57% de los problemas encontrados. La medida es el volumen total de incidencias, ponderado por gravedad e impacto, y no el porcentaje de criterios de éxito WCAG que una herramienta puede probar (Deque, “Automated testing study identifies 57 percent of digital accessibility issues”).
Es un dato útil, pero tiene dos límites. Es del propio fabricante, y mide otra cosa que un porcentaje de criterios. Lo que sí se desprende es que la automatización encuentra una parte importante de los problemas y deja el resto para revisar a mano.
¿Por qué le importa a un diseñador?
Porque la extensión te permite comprobar la versión real del producto, con el código que se renderiza, y no solo el diseño. Un contraste que pasó en Figma puede fallar en el navegador por un color que se aplica con otra regla CSS. Un botón que parece bien puede no tener nombre accesible.
También te ayuda a conversar con desarrollo con evidencia. En lugar de decir «creo que el botón no se entiende», puedes mostrar el hallazgo, el criterio afectado y la corrección sugerida.
¿Qué no detecta?
Las herramientas automáticas no pueden decidir si un texto alternativo describe bien una imagen, si el orden de lectura tiene sentido o si un mensaje de error es claro. Tampoco reemplazan la prueba con lectores de pantalla ni con personas que usan tecnologías de apoyo. Por eso, la prueba con lectores de pantalla sigue siendo parte del proceso.
Para la parte de color, la matemática del contraste te ayuda a entender por qué un valor falla y qué cambio lo arregla.
Ejemplo
Ejemplo ilustrativo: un equipo publica una página de registro. Al ejecutar axe DevTools, aparecen tres problemas: un campo sin etiqueta asociada, un enlace de «Leer más» repetido diez veces sin contexto y un botón de envío con contraste insuficiente. Los tres son fáciles de corregir y la herramienta indica el criterio de cada uno. Lo que no aparece es si los mensajes de error se anuncian bien a un lector de pantalla. Para eso, el equipo hace una prueba manual con un lector y lo añade a la lista.
¿Cuándo NO conviene depender de ella?
- Como única revisión. Una auditoría automática no es una auditoría completa de accesibilidad.
- Para decidir sobre intención o claridad. Si un texto confunde, la herramienta no lo sabe.
- Antes de tener diseño. Para revisar la paleta o los estados, Stark en Figma te sirve antes de codificar.
- Como excusa para no corregir. Un informe lleno de hallazgos sin plan de trabajo solo genera ruido.
Errores comunes
- Declarar accesible una página porque la extensión no encontró errores.
- Ignorar los hallazgos de nivel bajo sin revisar su impacto.
- Corregir solo lo que la herramienta marca y no el patrón que lo produce.
- Ejecutarla una vez al final, en lugar de integrarla en el flujo.
- Confundir la versión gratuita con la de pago sin revisar qué incluye cada una.
Cómo empezar mañana
Instala la extensión en el navegador y abre la página más visitada de tu producto. Revisa primero los problemas de gravedad alta. Para cada uno, anota el criterio, el elemento y la corrección. Después, abre un ticket por patrón, no por elemento: si el mismo error aparece en diez botones, el problema está en el componente. Guarda cada resultado con la fecha y la versión auditada. Así puedes comparar la siguiente revisión con esta y ver si los problemas bajan o se repiten, que es la señal que de verdad importa. Y añade a tu proceso una revisión de accesibilidad que incluya pruebas manuales, no solo esta extensión.