Principales Herramientas de Comprobación de la Accesibilidad Web en 2026

Las herramientas más útiles para comprobar la accesibilidad web en 2026 son WAVE, axe DevTools, Lighthouse y Accessibility Insights. WAVE ayuda a ver problemas directamente sobre la página; axe DevTools encaja en el trabajo de desarrollo y CI; Lighthouse permite una comprobación rápida desde DevTools; Accessibility Insights combina automatización con recorridos manuales guiados. Ninguna puede certificar por sí sola que un sitio sea accesible: una evaluación sólida también necesita pruebas manuales y criterio humano.

La elección depende de qué quieres revisar, cómo accedes a la página y quién debe actuar sobre los resultados. Esta guía compara los cuatro enfoques, explica cómo incorporarlos al flujo de trabajo y propone un proceso repetible para revisar páginas públicas, aplicaciones autenticadas y sitios grandes.

1. Qué puede y qué no puede comprobar un escáner

Una herramienta automática ejecuta reglas sobre el contenido que puede inspeccionar: por ejemplo, estructura, atributos, nombres accesibles y algunas condiciones de presentación. Esto permite localizar problemas frecuentes con rapidez y repetir comprobaciones durante el desarrollo. Sin embargo, el resultado depende de la página y estado que se analizan, de las reglas ejecutadas y de lo que puede inferirse automáticamente.

Hay cuestiones que exigen decidir si el contenido tiene sentido para una persona: si el texto alternativo describe adecuadamente la imagen, si el orden de lectura es lógico, si las instrucciones son comprensibles o si un flujo puede completarse con teclado. WebAIM lo resume así: “Only humans can determine whether a web page is accessible.” También indica que WAVE no puede comprobar todos los problemas de las pautas y que ninguna herramienta automatizada puede hacerlo. El W3C en español advierte de igual modo que ninguna herramienta por sí sola determina si un sitio cumple los estándares de accesibilidad. (WebAIM WAVE Help; W3C: evaluar accesibilidad)

• Automatiza la detección repetible de problemas que pueden expresarse como reglas.
• Revisa manualmente el significado, la secuencia, la interacción y los casos de uso.
• No conviertas una puntuación o la ausencia de alertas en una afirmación de conformidad.

El W3C mantiene una lista con más de 100 herramientas. Esa variedad no significa que exista una que cubra todo: conviene elegir según el objetivo y combinar métodos cuando el riesgo o la obligación de conformidad lo requieran. (Lista de herramientas del W3C)

2. Comparación rápida: WAVE, axe, Lighthouse y Accessibility Insights

Herramienta	Mejor uso	Modalidad	Alcance y límite práctico
WAVE	Aprender e inspeccionar problemas en su contexto visual.	Servicio web, extensiones, API y motor independiente.	Puede ayudar con páginas públicas, locales, dinámicas o protegidas según el método de acceso; no comprueba todos los criterios automáticamente.
axe DevTools	Desarrollo, QA y comprobaciones de reglas WCAG.	Extensión, APIs, CLI, CI y ofertas empresariales.	Se adapta a componentes, páginas y sitios; los hallazgos necesitan interpretación y pruebas manuales.
Lighthouse	Diagnóstico inicial rápido de una página.	Auditoría integrada en Chrome y Edge DevTools.	Útil para triage, pero una auditoría aislada no equivale a una revisión completa de WCAG.
Accessibility Insights	Guiar a equipos de diseño, QA y contenido por una evaluación.	Comprobaciones automáticas y recorridos manuales guiados.	Ayuda a revisar ámbitos visuales, cognitivos y físicos; el evaluador debe aplicar criterio.

La tabla resume el papel práctico de cada herramienta, no una puntuación universal. No hay en las fuentes consultadas una cifra homogénea que indique qué porcentaje de WCAG detecta cada producto; comparar porcentajes como si fueran equivalentes induciría a error. Consulta la guía del W3C para seleccionar herramientas al definir un proceso de evaluación. Las modalidades y descripciones están documentadas por WAVE, el listado del W3C, el Department for Education del Reino Unido y la documentación de Chrome DevTools.

3. WAVE: inspección visual en contexto

WAVE resulta útil cuando necesitas entender dónde aparece un problema y cómo se relaciona con el contenido cercano. Su presentación visual ayuda a revisar la página mientras se observan indicadores de errores, advertencias y estructura. Puede ser apropiado para aprender patrones, hacer una primera inspección y revisar páginas cuyo contexto importa.

Hay varias formas de usarlo: el servicio web sirve para páginas accesibles públicamente; las extensiones permiten analizar la página que ya está abierta en el navegador; WAVE también ofrece API y un motor independiente. La extensión del navegador es especialmente práctica si la página es local, dinámica o requiere iniciar sesión, porque la comprobación parte de la página cargada en ese navegador. Comprueba el método adecuado para tu entorno en la documentación de WAVE Help.

Flujo recomendado

1. Abre la página en el estado que quieres evaluar: carga contenido dinámico, inicia sesión si procede y elige el estado de interfaz relevante.
2. Ejecuta WAVE mediante el método compatible con esa página.
3. Inspecciona los indicadores en contexto y abre cada hallazgo para entender qué elemento señala.
4. Verifica manualmente si el hallazgo es un problema real, si falta contexto o si hay un caso que la herramienta no puede juzgar.
5. Corrige el origen en el componente o plantilla compartida cuando sea posible, y vuelve a revisar los estados relacionados.

Precaución: ver la página en el navegador no implica que se hayan recorrido todas sus rutas, diálogos, estados desplegables o contenido que aparece tras una interacción. Repite el análisis en los estados que importan y completa la revisión con teclado y lector de pantalla.

4. axe DevTools: pruebas durante el desarrollo y en CI

axe DevTools es una opción adecuada cuando las comprobaciones forman parte del trabajo habitual de desarrollo. Su ecosistema incluye extensión, APIs, CLI, CI y ofertas empresariales, lo que permite elegir una modalidad para explorar una página y otra para repetir comprobaciones en una canalización. Úsalo para encontrar defectos pronto, mantener registros de ejecución y revisar componentes antes de que se propaguen por el sitio.

Cómo añadirlo a un flujo técnico

1. Define el alcance: empieza por las plantillas y componentes compartidos, y añade páginas críticas y estados interactivos.
2. Ejecuta en un estado reproducible: prepara autenticación, datos de prueba, idioma, viewport y contenido necesario antes de analizar.
3. Guarda el resultado: conserva informes versionados o artefactos de CI con la revisión de código correspondiente.
4. Clasifica los hallazgos: corrige problemas reales, registra decisiones sobre falsos positivos y evita silenciar alertas sin explicación.
5. Añade pruebas manuales: incluye teclado, foco, formularios, mensajes de error, diálogos y contenido dependiente de interacción.

La automatización repetida puede impedir que vuelvan a entrar errores detectables, pero no determina si un flujo es comprensible ni sustituye una evaluación completa. Consulta la documentación de axe y sus opciones actuales desde la lista de herramientas del W3C.

5. Lighthouse: triage rápido desde DevTools

Lighthouse es conveniente para una comprobación inicial de una página sin montar un flujo aparte: está integrado en las herramientas de desarrollo de Chrome y Edge. Puede ayudarte a encontrar señales que merecen investigación durante una revisión rápida o una depuración. La documentación de Chrome DevTools y la guía de Microsoft Edge describen el uso de estas funciones.

Uso paso a paso

1. Abre la página en Chrome o Edge y DevTools.
2. Ejecuta la auditoría de accesibilidad de Lighthouse desde el panel correspondiente.
3. Revisa cada resultado y visita el elemento señalado; no trates la puntuación como certificado.
4. Prueba también los estados que no están presentes en la carga inicial: menús abiertos, errores de formulario, modales y contenido cargado al desplazarse.
5. Repite la auditoría después de los cambios y registra qué páginas y estados cubriste.

Una auditoría rápida es una buena puerta de entrada, no una muestra completa del sitio. Para páginas protegidas o interacciones complejas, la extensión de una herramienta que opere sobre la pestaña actual puede ser más adecuada que introducir una URL en un servicio web.

6. Accessibility Insights: automatización más evaluación guiada

Accessibility Insights está pensado para equipos que necesitan ayuda para recorrer comprobaciones, incluidas tareas manuales guiadas además de análisis automático. Puede aportar estructura a una revisión de diseño, QA o contenido, donde no basta con ejecutar una regla y cerrar el ticket. El recurso de herramientas y pruebas del Department for Education describe este enfoque.

Un recorrido guiado es útil si el equipo necesita recordar qué revisar y dejar constancia del proceso. Aun así, seguir los pasos no elimina la necesidad de juicio: el evaluador debe determinar si el contenido y la interacción funcionan para las personas destinatarias. Usa las comprobaciones automáticas para detectar problemas técnicos y el recorrido manual para examinar aspectos que requieren percepción o interpretación.

7. Cómo elegir según tu situación

Situación	Empieza con	Completa con
Una página pública y un diagnóstico breve	Lighthouse y WAVE.	Revisión manual de los hallazgos y teclado.
Página dinámica, local o con autenticación	Extensión de WAVE o axe DevTools en el navegador.	Prueba de los estados tras interacción y sesión.
Equipo de desarrollo con CI/CD	axe DevTools, CLI o integración adecuada.	Informes versionados, revisión manual periódica y teclado.
Diseño, QA o contenido que necesita orientación	Accessibility Insights.	Revisión experta y participación de usuarios cuando el riesgo lo justifique.
Sitio extenso o requisito de conformidad	Evaluación con alcance de sitio completo e informes apropiados.	Metodología como WCAG-EM y evaluadores con experiencia.

Esta selección es un punto de partida, no una clasificación absoluta. El W3C recomienda elegir herramientas según el propósito, la cobertura y el contexto de evaluación; para sitios grandes o necesidades formales, define alcance y método antes de confiar en un escaneo. Consulta cómo seleccionar herramientas y la información del W3C sobre evaluación de accesibilidad.

8. Proceso completo para revisar una página o un sitio

1. Define qué significa terminar. Anota páginas, plantillas, idiomas, roles, dispositivos y estados interactivos incluidos. Una revisión de la portada no cubre automáticamente el flujo de pago o el área autenticada.
2. Prepara una sesión representativa. Carga datos realistas, autentícate, acepta o rechaza opciones pertinentes y espera a que termine el contenido dinámico. Registra las condiciones para poder repetirlas.
3. Haz un pase automático. Elige WAVE para inspección visual, axe para desarrollo y repetición o Lighthouse para triage. Puedes combinar herramientas, pero no sumes sus puntuaciones como si midieran lo mismo.
4. Valida cada hallazgo. Reproduce el problema, identifica la causa y determina a qué componente afecta. Registra también las áreas no evaluadas automáticamente.
5. Prueba con teclado. Recorre la página sin ratón. Comprueba el orden de foco, que el foco sea visible, que los controles respondan y que los diálogos permitan entrar y salir de forma coherente.
6. Prueba con tecnologías de asistencia. Revisa nombres, roles, estados, instrucciones y mensajes relevantes con lector de pantalla cuando corresponda. Confirma el orden de lectura, no solo la presencia de atributos.
7. Incluye personas y experiencia adecuada al riesgo. Para flujos importantes, complejos o de alto impacto, una revisión experta y pruebas con usuarios pueden descubrir barreras que las reglas no detectan.
8. Verifica la corrección en contexto. Repite las comprobaciones tras cambiar el código y revisa las páginas hermanas que usan el mismo componente. Mantén evidencia del alcance, fecha, herramientas y limitaciones.

Para una evaluación formal, considera aplicar una metodología de evaluación de sitios como WCAG-EM y documenta qué se examinó. El objetivo del registro es que el equipo pueda entender el alcance y repetir la revisión, no presentar una puntuación aislada como garantía.

9. Casos difíciles: autenticación, contenido dinámico y sitios grandes

Páginas protegidas o locales

El escaneo basado en URL solo puede analizar lo que su método de acceso permite cargar. Si la página requiere inicio de sesión, un entorno local o datos de prueba, usa una extensión en el navegador autenticado cuando esté disponible. Comprueba que la ruta y el estado que ves sean los que se analizaron; analiza también permisos o roles distintos si generan interfaces distintas.

Interacciones y contenido que aparece tarde

Una captura inicial puede omitir menús, diálogos, validaciones y resultados de búsqueda. Abre cada elemento relevante y ejecuta las comprobaciones en ese estado. Para contenido que carga de forma diferida, espera a que aparezca y confirma que el análisis lo incluye. Registra dependencias de red o datos que vuelvan inestable la revisión.

Aplicaciones con muchas páginas

Empieza por una muestra basada en plantillas y componentes, pero no confundas esa muestra con cobertura total. Añade rutas críticas, variaciones de rol y páginas que difieren sustancialmente. En CI, una comprobación por componente puede ser rápida; reserva también revisiones de página integrada para detectar problemas que solo aparecen cuando los componentes se combinan.

10. Errores habituales, causas y solución

Problema	Causa probable	Qué hacer
No se puede analizar la página	URL inaccesible, autenticación, contenido local o restricciones del método web.	Prueba una extensión sobre la pestaña autenticada o el método de WAVE adecuado; confirma permisos y estado de sesión.
El resultado cambia entre ejecuciones	Contenido dinámico, datos variables, solicitudes lentas o estados no reproducibles.	Fija datos de prueba, espera a que la interfaz esté lista y conserva pasos de reproducción.
El informe parece limpio, pero alguien no puede completar el flujo	La automatización no juzga todas las interacciones ni el significado del contenido.	Prueba teclado y lector de pantalla; revisa el flujo completo y pide evaluación humana.
La misma alerta aparece en muchas rutas	Defecto en una plantilla o componente compartido.	Busca y corrige la causa compartida; vuelve a ejecutar sobre las rutas que lo usan.
Hay demasiadas alertas para priorizar	Se analizó un alcance grande sin triage o se mezclaron defectos, advertencias y decisiones de contexto.	Reproduce, agrupa por causa y componente, prioriza impacto y asigna responsables; no descartes en bloque.
Una puntuación empeora aunque no haya cambios de accesibilidad	Variación del contenido, la sesión, el navegador o las condiciones de ejecución.	Compara hallazgos concretos y entorno de ejecución; conserva evidencia antes de atribuirlo a una regresión.
Se afirma conformidad basándose en una auditoría	Se confundió una comprobación parcial con una evaluación completa.	Describe el alcance real y completa el proceso con evaluación manual adecuada; no uses puntuación como certificación.

11. Rendimiento, fiabilidad y coste del proceso

La duración depende del tamaño y estado de la página, de la carga de contenido y del método de análisis. No hay en las fuentes de este artículo un benchmark comparable para afirmar que una herramienta sea siempre más rápida. En la práctica, automatizar páginas representativas y componentes en CI ayuda a encontrar regresiones temprano; ejecutar auditorías completas en cada cambio puede tener sentido o no según el tiempo de ejecución y el coste de mantener pruebas estables.

Mejora la fiabilidad fijando rutas, datos, roles y estados; esperando a que la interfaz esté lista; conservando informes; y revisando resultados inestables antes de bloquear un despliegue. Una alerta automatizada puede ser un defecto real, un caso que necesita interpretación o una condición que no se reprodujo correctamente. Define cómo se registran las decisiones y quién valida una excepción.

El coste de las herramientas depende de sus modalidades y planes actuales; no atribuyas precios sin verificarlos directamente con cada proveedor. También hay coste de implementación y revisión humana. En equipos pequeños, las opciones integradas y extensiones pueden bastar para comenzar; en organizaciones con sitios extensos, necesidades de informes o controles de CI, compara el alcance requerido con el coste de una plataforma y de mantener el proceso. El tiempo de especialistas y de participantes en pruebas también debe contemplarse cuando el riesgo lo justifica.

12. Alternativa para capturar evidencia visual: ScreenshotNeo

Las herramientas de accesibilidad anteriores analizan barreras; una captura de pantalla sirve para guardar evidencia visual de una página o estado y compartirla en una incidencia. ScreenshotNeo, de Yorker Media, es una API de capturas y un servidor MCP para desarrolladores. Puede complementar el registro de una revisión visual, pero una imagen no comprueba accesibilidad ni reemplaza WAVE, axe, Lighthouse, Accessibility Insights o las pruebas manuales.

Para capturar una página con una sola solicitud GET, necesitas una clave de API. El endpoint es https://api.screenshotneo.com/v1/shot. La API devuelve una captura PNG, JPEG o WebP, o un PDF. Consulta la documentación de ScreenshotNeo para opciones y parámetros.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo admite captura de página completa y de un elemento por selector; modos oscuro, dispositivos y tamaños de viewport; escala retina; PDF con opciones de papel, márgenes, orientación y páginas; HTML/CSS a imagen; CSS y JavaScript personalizados; clic previo; espera por selector, demora o red inactiva; bloqueo de anuncios, rastreadores, solicitudes o tipos de recurso; cabeceras, cookies, user agent y Authorization; zona horaria y geolocalización; fondo transparente, redimensionado y caché con TTL; enlaces firmados para etiquetas <img> públicas, trabajos asíncronos con webhooks firmados, capturas masivas de hasta 100 URL por llamada, API de uso y especificación OpenAPI. También admite los nombres de parámetros usados por otras APIs de capturas para facilitar una migración.

Su servidor MCP ofrece take_screenshot, get_page_info y capture_pdf para Claude, Cursor y cualquier cliente MCP. Antes de la captura, acepta el banner de cookies/consentimiento como un visitante y elimina más de 60 plataformas de consentimiento conocidas, ventanas emergentes de newsletters y widgets de chat; cada paso puede desactivarse. Solo se cobran capturas limpias: las comprobaciones de bots/CAPTCHA, páginas en blanco, timeouts, cargas fallidas y aciertos de caché no cuestan, y la respuesta indica el resultado mediante las cabeceras X-Page-Verdict y X-Billed.

Or skip the browser setup

Una llamada devuelve la captura sin que tengas que instalar y mantener un navegador automatizado para ese trabajo:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Los banners de cookies, las ventanas emergentes y los widgets de chat se eliminan antes de la captura. Las comprobaciones de bots, páginas en blanco y cargas fallidas nunca se facturan. Un servidor MCP permite que agentes de IA tomen capturas. El plan gratuito incluye 1.000 capturas al mes sin tarjeta; los planes de pago empiezan en $5 por 3.000. Los planes publicados también incluyen Growth por $15 para 15.000, Pro por $39 para 60.000, Scale por $99 para 250.000 y Business por $249 para 1.000.000; la facturación anual ofrece dos meses gratis y todas las funciones están en todos los planes. Consulta la documentación y regístrate gratis para obtener 1.000 capturas al mes sin tarjeta.

13. Preguntas frecuentes

¿Cuál es la mejor herramienta de accesibilidad web en 2026?

Depende de la tarea: WAVE para inspección visual, axe DevTools para desarrollo y CI, Lighthouse para triage rápido y Accessibility Insights para evaluación guiada. Combina herramientas y revisión humana según el riesgo.

¿WAVE o axe?

Elige WAVE cuando te ayude más ver los problemas sobre la página. Elige axe cuando quieras integrar comprobaciones en desarrollo, CLI o CI. Ambos resultados requieren interpretación y comprobaciones manuales.

¿Lighthouse detecta todos los errores WCAG?

No. Lighthouse es útil para diagnóstico, pero las fuentes dejan claro que ninguna herramienta automatizada cubre todos los problemas de accesibilidad.

¿Necesito una auditoría manual además del escáner?

Sí. La automatización no puede determinar por sí sola si la experiencia completa funciona para personas con distintas necesidades. El alcance manual debe ajustarse al sitio y al impacto de los flujos.

¿Cómo compruebo una página con inicio de sesión?

Usa un método que analice la página ya cargada en un navegador autenticado, como una extensión compatible, y asegúrate de revisar las rutas y estados asociados al rol de prueba.

¿Qué debo conservar de cada revisión?

Registra el alcance, las páginas y estados, las herramientas y condiciones de ejecución, los hallazgos confirmados, las limitaciones y las comprobaciones manuales completadas. Así el equipo puede reproducir y mantener la evaluación.