Las mejores herramientas de prueba de accesibilidad web: mejores opciones comparadas (2026)

Las herramientas de prueba de accesibilidad web detectan automáticamente solo alrededor de un tercio de los criterios de éxito de las WCAG, por lo que ninguna herramienta puede confirmar que un sitio es accesible. La combinación mínima viable es una extensión de navegador como ax DevTools o WAVE, un linter de pipeline como axe-core, Pa11y o Lighthouse CI, y pruebas manuales con lector de pantalla y teclado, ya que el estándar de referencia es WCAG 2.2.

Si está desarrollando sitios en XHTML/CSS y necesita cumplir con las WCAG, tarde o temprano se enfrentará a la misma pregunta: ¿qué herramientas de prueba de accesibilidad web merecen un lugar en su flujo de trabajo? La respuesta corta es que ninguna herramienta detecta todo, y confiar en una sola es la forma más rápida de creer que su sitio es accesible cuando en realidad no lo es. La respuesta larga, que es la que importa, depende del tipo de barrera que quieras detectar, en qué fase de desarrollo te encuentres y cuánto tiempo puedas dedicar a la revisión manual.

Este artículo compara las herramientas más relevantes para los desarrolladores de habla hispana, explica qué detecta cada una, dónde fallan y cómo combinarlas para cubrir los criterios WCAG 2.2 de manera realista. Esta no es una lista de los “top 10” sin criterios: es una guía para decidir.

Conclusiones clave

• Ninguna herramienta automatizada detecta más de una fracción de los criterios WCAG. Las estimaciones típicas de la industria sitúan la cobertura automática en alrededor de un tercio de los criterios de éxito; el resto requiere revisión humana.
• La combinación mínima viable de herramientas de prueba de accesibilidad web es: una extensión de navegador para inspección puntual (axe DevTools o WAVE), un linter integrado en el pipeline (axe-core, Pa11y o Lighthouse CI) y pruebas manuales con lector de pantalla y teclado.
• Las herramientas de contraste y estructura (como las integradas en las DevTools del navegador) resuelven problemas concretos rápidamente, pero no reemplazan una auditoría.
• El estándar de referencia es WCAG 2.2, publicado por el W3C, con niveles A, AA y AAA. La mayoría de legislaciones exigen AA.
• Automatiza lo repetitivo, humaniza lo complejo. Los formularios, los widgets interactivos y el orden de enfoque casi siempre requieren verificación manual.

Qué pueden y no pueden detectar las herramientas de prueba de accesibilidad web

Antes de comparar herramientas, es útil comprender los límites. Una herramienta automática analiza el DOM, el CSS calculado y, en algunos casos, el árbol de accesibilidad. Puede detectar de forma fiable:

• Contraste de color insuficiente (cuando el color de fondo es sólido y conocido).
• Faltan atributos “alt” en las imágenes.
• Etiquetas de formulario faltantes o mal asociadas.
• Jerarquía de encabezados rota o saltos de nivel.
• Atributos ARIA no válidos o mal utilizados (roles inexistentes, aria-* sin el rol correspondiente).
• Enlaces con texto vacío o genérico.
• Falta lang en el elemento html.
• Elementos interactivos no accesibles mediante teclado en determinados casos.

Lo que no puede detectar de manera confiable:

• Si un texto alternativo es adecuado en su contexto (solo detecta que existe).
• Si el orden de tabulación tiene un sentido lógico.
• Si un mensaje de error se anuncia correctamente a un lector de pantalla.
• Si el contenido tiene una estructura semántica comprensible.
• Si los widgets personalizados (cuadros combinados, controles deslizantes, menús) se comportan como lo espera el usuario de tecnología de asistencia.
• La calidad de la experiencia con zoom del 400% o con texto ampliado.

Esta distinción es la que separa una auditoría real de una “pasada el validador”. El W3C mantiene una página oficial sobre cómo cumplir con las WCAG que es útil tener a mano.

Relacionado: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Comparativa de herramientas por categoría

Esta tabla resume las principales herramientas de prueba de accesibilidad web:

Herramienta	Tipo	Ideal para	Cobertura	Costo
axe DevTools	Extensión del navegador	Inspección puntual, desarrolladores	Altas reglas automáticas	Gratis (versión básica)
ONDA	Extensión/web	Revisión visual rápida, docentes	Media-alta, muy visual	Gratis
Faro	Integrado en Chrome/CI	Rendimiento + accesibilidad en auditoría	Medios	Gratis
axe-core	Librería JS	Integración en pruebas y CI	Alta, motor de muchas otras	Gratis (código abierto)
Pa11y	CLI/CI	Automatización en pipeline	Media-alta	Gratis (código abierto)
IBM Equal Access	Extensión/CI	Cobertura amplia, informes detallados	Alta	Gratis
Información sobre accesibilidad	Ampliación / escritorio	Guía paso a paso para revisión manual	Alta + manual de asistencia	Gratis (Microsoft)
NVDA / VoiceOver	Lector de pantalla	Pruebas manuales reales	Sin aplicación (manual)	Gratis

Las herramientas, una por una

axe DevTools

Este es probablemente el punto de partida más habitual para las herramientas de prueba de accesibilidad web. Funciona como una extensión para Chrome, Firefox y Edge, y se basa en el motor axe-core, que es de código abierto y está integrado en muchas otras herramientas (incluido Lighthouse). Su gran ventaja es la reducción de los falsos positivos: cuando señala algo, suele ser un problema real.

Detecta bien el contraste, ARIA, estructura de encabezados, formularios y landmarks. Su limitación es la misma que todas las demás: no evalúa la calidad semántica ni la experiencia con un lector de pantalla. La versión gratuita cubre la mayoría de las necesidades de un desarrollador individual; Las funciones de seguimiento continuo y los informes del equipo están en planes pagos.

Vale la pena echarle un vistazo: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

ONDA (WebAIM)

WAVE, de WebAIM, tiene un enfoque muy visual: superpone iconos en la página para indicar errores, alertas, elementos correctos y puntos de revisión manual. Es excelente para enseñar accesibilidad o para un primer paso rápido, porque muestra el problema en contexto.

Su punto débil es que genera mucho “ruido”: muchas alertas son avisos que requieren criterio humano. Aún así, para aquellos que comienzan, ver los íconos en la página acelera mucho la comprensión.

Faro

Lighthouse está integrado en Chrome DevTools y también se puede ejecutar desde la línea de comandos o en CI. Su auditoría de accesibilidad utiliza axe-core debajo, por lo que las reglas son similares a las de ax DevTools, pero el informe es más superficial y está diseñado para dar una puntuación rápida.

Úselo como un semáforo en integración continua, no como una auditoría. Una puntuación de 100 en Lighthouse no significa que el sitio sea accesible; significa que no se detectaron problemas automáticos.

axe-core y Pa11y para el pipeline

Aquí está el verdadero valor para los equipos. axe-core es una biblioteca de JavaScript que puedes invocar en pruebas con Jest, Playwright o Cypress. Pa11y es una herramienta de línea de comandos que ejecuta análisis en URL y devuelve resultados en diferentes formatos, ideal para integrarse en una canalización de CI.

La ventaja de automatizar en CI es que evitas regresiones: si alguien introduce una imagen sin “alt” o rompe el contraste, la construcción falla. La desventaja es que sólo cubre la parte automática, por lo que no sustituye la revisión manual, sólo la complementa.

Relacionado: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad..

Comprobador de accesibilidad de IBM Equal Access

Menos conocido que axe, pero con amplia cobertura y reglas propias. Ofrece una extensión de navegador y una versión para CI. Su informe distingue entre problemas y “necesita revisión”, lo cual es honesto y útil. Es una buena segunda opinión cuando se quieren contrastar resultados con Axe.

Información sobre accesibilidad (Microsoft)

Su punto fuerte es que guía la revisión manual. Además del análisis automático, ofrece un modo de “Evaluación” que lo lleva paso a paso a través de los criterios WCAG, con instrucciones concretas sobre qué verificar y cómo. Para aquellos que quieran aprender a auditar de verdad, es una de las mejores opciones gratuitas.

Lectores de pantalla: la prueba que ninguna herramienta reemplaza

NVDA (Windows, gratis) y VoiceOver (macOS/iOS, integrado) son las herramientas que revelan los problemas que ningún analizador detecta: orden de lectura confuso, controles que no anuncian su estado y mensajes de error que pasan desapercibidos. Aprender los conceptos básicos de un lector de pantalla es la inversión con mayor retorno para cualquier desarrollador que trabaje en accesibilidad.

Vale la pena echarle un vistazo: Deque axe DevTools Pro — El estándar de la industria para probar la accesibilidad durante el desarrollo..

Cómo decidir: criterios prácticos

Si tiene que elegir herramientas de prueba de accesibilidad web, hágase estas preguntas:

1. ¿Trabajas solo o en equipo? Individual: extensión de navegador + lector de pantalla. Equipo: agregue CI con axe-core o Pa11y.
2. ¿En qué fase te encuentras? Durante el desarrollo, linter en el editor y la extensión. Antes de publicar, una auditoría completa con Accessibility Insights. En producción, seguimiento continuo.
3. ¿Qué regulaciones se aplican? Si necesita cumplir con una legislación específica (por ejemplo, la Directiva Europea de Accesibilidad Web o la Sección 508 en los EE. UU.), verifique que la herramienta asigne sus resultados a los criterios WCAG correspondientes.
4. ¿Cuál es el presupuesto? Todos los mencionados tienen una versión gratuita funcional. Los pagos agregan informes, monitoreo y colaboración, no necesariamente una mejor detección.

Un flujo realista para un sitio XHTML/CSS podría ser: ax DevTools durante el desarrollo, Pa11y en CI, Accessibility Insights antes de cada lanzamiento importante y una sesión con NVDA o VoiceOver para flujos críticos (inicio de sesión, formularios, navegación).

Errores comunes al usar estas herramientas

• Creer que “cero errores” equivale a ser accesible. Falso. Esto sólo significa que estas herramientas de prueba de accesibilidad web no detectaron problemas automáticos.
• Ignorar advertencias. Muchas herramientas separan los errores de las alertas; Las alertas suelen estar donde están los verdaderos problemas.
• No probar con el teclado. Al desplazarse por la página se revelan problemas de enfoque que ninguna extensión señala bien.
• Olvidar el zoom y el texto ampliado. Prueba al 200% y 400%; el reflujo es un criterio relevante de las WCAG 2.2.
• Automatizar sin entender. Una prueba que se aprueba no enseña nada si no sabes lo que comprueba.

Conclusión

Las mejores herramientas de prueba de accesibilidad web no son las que tienen más funciones, sino las que se adaptan a su flujo de trabajo y lo obligan a realizar la parte manual. Comience con ax DevTools o WAVE para los problemas obvios, automatice con axe-core o Pa11y para evitar regresiones y reserve tiempo para realizar pruebas con el teclado y el lector de pantalla. Esta combinación, más que cualquier herramienta aislada, es lo que acerca a un sitio al verdadero cumplimiento de las WCAG.

Fuentes y lecturas adicionales

• Accesibilidad web — Wikipedia: La accesibilidad web, o eAccessibility, es la práctica inclusiva de garantizar que no existan barreras que impidan la interacción o el acceso a sitios web en el mundo…

Preguntas frecuentes

¿Cuál es la mejor herramienta gratuita de pruebas de accesibilidad web?

No existe una mejor entre las herramientas de prueba de accesibilidad web, porque cada una cubre cosas distintas. Para inspecciones puntuales, ax DevTools y WAVE son los más utilizados y gratuitos. Para automatizar en CI, axe-core y Pa11y son de código abierto y muy confiables. Para aprender a auditar manualmente, Accessibility Insights de Microsoft es difícil de superar en su versión gratuita.

¿Las herramientas automáticas detectan todos los problemas de accesibilidad?

No. Detectan parte de los criterios WCAG, principalmente los relacionados con atributos, contraste y estructura. Cuestiones como el orden de enfoque, la calidad del texto alternativo o el comportamiento de los widgets personalizados requieren una revisión humana con el teclado y el lector de pantalla.

¿Qué diferencia hay entre WCAG 2.1 y WCAG 2.2?

WCAG 2.2 agrega nuevos criterios de éxito en comparación con 2.1, centrándose principalmente en la interacción con el puntero, el enfoque y las ayudas de entrada. Se mantienen los niveles A, AA y AAA. La mayoría de la legislación sigue exigiendo el nivel AA, y es recomendable comprobar a qué versión hace referencia la normativa que te aplica.

¿Puedo integrar las pruebas de accesibilidad en mi pipeline de CI?

Sí, es muy recomendable. Herramientas como axe-core (a través de Playwright, Cypress o Jest) y Pa11y le permiten realizar análisis automáticos en cada compilación y fallar si se detectan regresiones. Abarcan sólo las partes automáticas, pero evitan que vuelvan a aparecer problemas ya resueltos.

¿Necesito aprender a usar un lector de pantalla?

Si trabajas en serio la accesibilidad, sí. NVDA en Windows y VoiceOver en macOS son gratuitos y son suficientes para detectar problemas que ninguna extensión detecta. No es necesario ser un experto: conocer la navegación básica por encabezados, enlaces y formularios ya proporciona información valiosa.

¿Una puntuación alta en Lighthouse garantiza que mi sitio sea accesible?

No. Lighthouse utiliza axe-core internamente y solo evalúa reglas automáticas. Una puntuación de 100 indica que no se detectaron problemas automáticos, no que el sitio cumpla con las WCAG. El cumplimiento real requiere pruebas manuales adicionales.