Por qué los escáneres automáticos de accesibilidad solo detectan el 30% de los problemas (y qué hacer al respecto)

Ejecutas un escaneo automatizado de accesibilidad, el panel de control vuelve en verde y respiras aliviado. Pero aquí hay una verdad incómoda: ese informe limpio puede estar ocultando la mayoría de las barreras reales de accesibilidad de tu sitio. La investigación y los estudios independientes muestran de forma consistente que los escáneres automatizados detectan entre el 30% y el 57% de las violaciones reales de las WCAG, lo que significa que entre la mitad y dos tercios de los problemas que tus usuarios con discapacidad encuentran cada día son completamente invisibles para las herramientas en las que la mayoría de los equipos confían.

El estado de las pruebas automatizadas de accesibilidad

Las pruebas automatizadas de accesibilidad se han disparado en popularidad, y con razón. Cada vez más equipos recurren a la automatización para detectar problemas de accesibilidad: el 50% de las personas encuestadas en un estudio de 2024 dijeron que utilizan herramientas automatizadas de accesibilidad para identificar posibles problemas, frente al 40% en 2023. El atractivo es obvio: los escáneres son rápidos, relativamente baratos y pueden integrarse directamente en los pipelines de CI/CD. Detectan a escala las violaciones obvias, repetibles y basadas en reglas: el atributo alt que falta, el campo de formulario sin etiqueta, el botón con un nombre accesible vacío.

Pero el techo de cobertura es un problema persistente que ningún proveedor de escáneres ha logrado superar. Según Deque, "puedes encontrar en promedio el 57% de los problemas de las WCAG de forma automática", y aun así las herramientas devolverán componentes como incompletos cuando se necesite una revisión manual. Esa cifra del 57% representa el extremo optimista del espectro, alcanzado por uno de los motores de accesibilidad más maduros y ampliamente confiables del mercado utilizando una metodología de medición pragmática y del mundo real. Otras estimaciones son considerablemente más bajas. Las herramientas automatizadas detectan aproximadamente el 30–40% de las violaciones de las WCAG, y el 60–70% restante requiere pruebas manuales.

La discrepancia entre el 30% y el 57% se reduce a cómo defines el denominador. Deque llegó a la cifra del 57% adoptando un enfoque pragmático y del mundo real en lugar de uno teórico: muestreando un gran número de sitios y midiendo cuántos de los defectos de accesibilidad realmente documentados se habrían detectado usando axe-core. Cuando, en cambio, las personas investigadoras miden la cobertura frente a todos los criterios de éxito de las WCAG como un conjunto teórico, las cifras caen en picado. En el momento de escribir esto, al filtrar los niveles A y AA de las WCAG 2.2 para mostrar solo reglas de prueba automatizada aprobadas, se revela cobertura parcial o total para solo 17 de 55 criterios de éxito. De cualquier forma que lo mires, las pruebas automatizadas dejan un vacío significativo —y legalmente peligroso—.

El problema se agrava por lo difícil que es ver ese vacío desde fuera. Un escaneo aprobado señala activamente seguridad, que es precisamente cuando los equipos tienen más probabilidades de dejar de buscar. El panel está en verde. Se hace el despliegue. Usuarios reales con discapacidad se encuentran con barreras reales.

En qué son realmente buenos los escáneres

Antes de profundizar en la brecha de cobertura, vale la pena dejar claro en qué son realmente buenas las herramientas automatizadas. Son rápidas, consistentes e incansables a la hora de comprobar las cosas que pueden determinarse únicamente leyendo el DOM. La automatización de accesibilidad puede detectar de forma fiable violaciones comunes de las WCAG como texto alternativo faltante, enlaces vacíos, etiquetas de formulario incorrectas y relaciones de contraste de color bajas. Se trata de comprobaciones estructurales y binarias: o el atributo existe o no existe, o la relación de contraste supera 4.5:1 o no lo hace.

El informe WebAIM Million, que analiza anualmente las principales páginas de inicio del millón de sitios más visitados, ofrece una imagen vívida de lo extendidos que siguen estando estos errores detectables. El 95.9% de las páginas de inicio presentaban fallos detectados de las WCAG 2. Las seis categorías más comunes —texto con bajo contraste, texto alternativo faltante, etiquetas de formulario faltantes, enlaces vacíos, botones vacíos y ausencia de idioma del documento— representan el 96% de todos los errores detectados, y estos errores más comunes han sido los mismos durante los últimos siete años. Las herramientas automatizadas son realmente útiles para sacar a la luz estas violaciones de alta frecuencia y baja complejidad a escala. El problema es que corregir solo estos problemas sigue dejando un sitio con la mayoría de sus barreras reales intactas.

Por qué existe la brecha: lo que los escáneres no pueden evaluar

El techo de cobertura no es un fallo de ingeniería, es una limitación fundamental de lo que una máquina puede evaluar sin juicio humano. La brecha existe porque las máquinas no pueden entender el contexto, la intención de la persona usuaria ni cuestiones subjetivas como si la jerarquía de encabezados tiene sentido o si el texto alternativo es preciso. Un escáner puede confirmar que una imagen tiene un atributo alt. No puede decirte si ese atributo dice "photo-123-final-v2.jpg" o una descripción realmente útil. Las herramientas pueden marcar que una imagen tiene texto alternativo, pero solo una persona puede juzgar si ese texto describe bien la imagen.

Estas son las principales categorías de problemas que se escapan de forma sistemática a la detección automatizada:

• Experiencia con lector de pantalla: Las herramientas automatizadas no pueden escuchar cómo un lector de pantalla anuncia el contenido. Pueden comprobar la validez de los atributos ARIA, pero no pueden determinar si los anuncios resultantes tienen sentido para las personas usuarias. Un campo de formulario puede tener un aria-label técnicamente válido que se lea como una cadena confusa de caracteres para una persona usuaria real de NVDA o JAWS.
• Orden lógico de lectura y de foco: En la práctica, el orden de lectura a menudo no tiene sentido cuando las personas usuarias de lectores de pantalla acceden a información que visualmente puede leerse perfectamente bien. En un diseño de columnas, un lector de pantalla lee la primera línea de la columna 1 y luego la columna 2, lo que genera confusión. Los escáneres analizan el orden del DOM de forma aislada, sin el contexto de cómo el diseño visual transforma ese orden para una persona vidente.
• Texto significativo de enlaces y botones en contexto: Las herramientas automatizadas pueden comprobar si existe un enlace y si incluye texto, pero no siempre pueden juzgar si el propósito de ese enlace es claro. Cinco enlaces de "Leer más" en la misma página pasan las comprobaciones automatizadas y fallan para las personas usuarias reales que necesitan entender adónde lleva cada uno.
• Contenido dinámico y regiones en vivo: Las herramientas automatizadas no podrán detectar problemas con contenido cargado dinámicamente. Habrá que ejecutar la prueba de nuevo después de que se añada la actualización dinámica, pero incluso entonces, la herramienta no puede decir si un lector de pantalla lo leerá o no.
• Accesibilidad cognitiva y lenguaje claro: La automatización puede detectar problemas estructurales como el orden de los encabezados o la presencia de etiquetas, pero no puede evaluar la legibilidad, la claridad o si las instrucciones son fáciles de seguir. Un proceso de compra complejo de varios pasos con mensajes de error confusos puede ser estructuralmente "limpio" y, al mismo tiempo, profundamente inaccesible para las personas con discapacidades cognitivas.
• Navegación con teclado en interacciones complejas: La automatización puede probar el foco básico del teclado y su operabilidad, pero no puede validar por completo interacciones complejas de varios pasos, gestos personalizados o dispositivos de entrada alternativos. Un widget de selector de fecha personalizado puede ser totalmente operable con teclado en teoría y una trampa completa en la práctica.
• Elementos visuales superpuestos y contraste en degradados: Las herramientas automatizadas pueden evaluar las relaciones de contraste, pero no siempre tienen en cuenta elementos superpuestos, imágenes detrás del texto o contenido que cambia dinámicamente y que interfiere con la legibilidad.

Un escaneo automatizado limpio significa que has abordado el 30–40% de los problemas que la automatización puede detectar. El 60–70% restante no se ha probado. Nunca afirmes conformidad con las WCAG basándote únicamente en pruebas automatizadas.

Un dato especialmente llamativo: en un estudio, defensores de la accesibilidad del gobierno del Reino Unido crearon intencionadamente una página web con 142 barreras de accesibilidad y luego analizaron la página con 13 herramientas automatizadas de accesibilidad. La herramienta con mejor rendimiento solo pudo identificar el 40% de las barreras. La herramienta con peor rendimiento encontró apenas el 13%. Incluso cuando se apiló la baraja a favor de las herramientas —utilizando una página controlada con problemas conocidos y documentados—, los resultados fueron aleccionadores. Y combinar herramientas no lo resuelve del todo: incluso utilizando seis herramientas en paralelo, la mitad de todos los criterios de éxito de las WCAG 2 no están cubiertos y se pasan por alto 6 de cada 10 violaciones.

El riesgo legal de depender en exceso de la automatización

Esto no es solo una preocupación teórica sobre la experiencia de usuario. Las consecuencias legales por incumplimiento de accesibilidad están aumentando drásticamente, y un escaneo automatizado aprobado ofrece casi ninguna protección en una demanda. En 2024, se presentaron más de 4,000 demandas en tribunales estadounidenses alegando barreras a la accesibilidad de sitios web o móviles. Solo en la primera mitad de 2025 se presentaron 2,014 demandas por sitios web bajo la ADA, un aumento del 37% respecto a 2024.

Los acuerdos extrajudiciales promedian $30,000, mientras que las sentencias judiciales promedian $85,000. En todos los casos se suman honorarios de defensa legal de $30,000–$175,000. Peor aún, llegar a un acuerdo una vez no garantiza seguridad: el 45–46% de las demandas federales de accesibilidad digital de 2025 se dirigieron a empresas que ya habían sido demandadas antes. Ser demandado y parchear solo lo que las herramientas automatizadas señalan, sin abordar las brechas estructurales más amplias, simplemente pinta un blanco en tu espalda para la próxima persona demandante.

También vale la pena abordar una idea errónea común sobre los widgets y superposiciones de accesibilidad como atajo hacia el cumplimiento. Los datos de 2025 muestran que se presentaron 456 demandas bajo la ADA contra sitios web que tenían widgets de accesibilidad instalados, lo que representa el 22.64% del total de demandas, lo que enfatiza que simplemente añadir un widget de accesibilidad no es una solución integral. Las herramientas automatizadas solo pueden detectar el 30% de los problemas de las WCAG, lo que significa que cualquier herramienta o widget que dependa únicamente de la detección automatizada, por definición, deja la mayoría de los problemas sin abordar. Lo que diferencia a un SDK de accesibilidad realmente valioso —como Accsible— de los productos de superposición que han enfrentado reacciones legales y regulatorias es la combinación de remediación automatizada con un compromiso con una estrategia de cumplimiento honesta y por capas, en lugar de garantías falsas.

Una estrategia de pruebas por capas que realmente funciona

La respuesta a la brecha de cobertura no es abandonar los escáneres automatizados, sino utilizarlos correctamente, como la primera capa de una estrategia integral, no la última. De los 86 criterios de éxito de las WCAG 2.2, el setenta por ciento requiere revisión humana para interpretar correctamente los criterios y aplicarlos a las zonas grises que quedan fuera del alcance de la tecnología de accesibilidad automatizada. Eso significa que el juicio humano no es opcional, está estructuralmente requerido por la propia norma.

Un programa sólido de pruebas de accesibilidad suele funcionar en tres capas:

1. Escaneo automatizado (continuo): Integra escáneres como axe-core en tu pipeline de CI/CD y ejecútalos en cada build. Detecta las violaciones estructurales y binarias antes de que lleguen a producción. Establece umbrales y haz que los builds fallen ante nuevas violaciones críticas. Esta es tu red de seguridad para lo obvio: rápida, escalable y barata. Ejecuta herramientas automatizadas temprano y con frecuencia durante el desarrollo. Integra axe o WAVE en tu pipeline de CI/CD para que los problemas se detecten antes de que el código llegue a QA. Esto desplaza las pruebas de accesibilidad hacia la izquierda, detectando problemas cuando es más barato solucionarlos.
2. Auditoría manual experta (periódica): Realiza auditorías manuales estructuradas frente a la lista completa de verificación de las WCAG, llevadas a cabo por personas con un conocimiento profundo de accesibilidad. Las pruebas manuales de accesibilidad las realizan personas expertas formadas que utilizan activamente sitios web con tecnologías de apoyo como lectores de pantalla, navegación por teclado o software de magnificación. Evalúan el contexto y la experiencia de usuario: el orden lógico del foco y la sensación intuitiva de la navegación, la claridad de los formularios y los mensajes de error, la legibilidad dentro de contenido complejo. Las auditorías manuales suelen realizarse trimestralmente o cuando se lanzan funcionalidades importantes, y deberían cubrir de extremo a extremo los recorridos de usuario de mayor tráfico. Las auditorías de accesibilidad manuales guiadas se sitúan entre las pruebas totalmente manuales y las totalmente automatizadas, reduciendo la brecha de cobertura, y algunas estimaciones sitúan la cobertura en hasta el 80% con este enfoque.
3. Pruebas con tecnología de apoyo y con personas usuarias (continuas): No puedes depender únicamente de herramientas automatizadas para determinar los problemas de accesibilidad de tu sitio. Todo proyecto web necesita una estrategia de pruebas con personas usuarias, y es muy recomendable que incluyas grupos de usuarias y usuarios de accesibilidad: personas usuarias de lectores de pantalla, personas que solo usan teclado, personas no oyentes, personas con discapacidades motrices. Las personas usuarias reales con discapacidad encuentran problemas que ninguna lista de verificación anticipa. Haz pruebas con NVDA y JAWS en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. Navega todo tu flujo de compra o registro utilizando solo el teclado. Escucha realmente cómo suena tu contenido cuando se lee en voz alta.

Cuando los equipos implementan las tres capas, la cobertura combinada puede acercarse al 80–90% de los problemas del mundo real, una mejora drástica frente al techo del 30–57% de la automatización por sí sola. El objetivo no es la perfección desde el primer día; es un proceso sistemático y documentado que demuestre un esfuerzo genuino de buena fe y cierre continuamente la brecha.

Integrar la accesibilidad en tu flujo de trabajo de desarrollo

El cambio cultural más importante es pasar de considerar la accesibilidad como una lista de verificación previa al lanzamiento a una práctica continua. Muchas organizaciones cometen el error de tratarla como una auditoría puntual que encargan cuando temen una demanda, en lugar de un estándar de calidad integrado en cada sprint. Para cuando una auditoría revela problemas en un sistema en producción, el coste de solucionarlos es de cinco a diez veces mayor de lo que habría sido en la fase de diseño.

Empieza por hacer que los criterios de accesibilidad formen parte de tu definición de hecho. Cuando una persona desarrolladora entrega un nuevo componente, una comprobación automatizada rápida debería ejecutarse automáticamente. Cuando una persona diseñadora crea un nuevo patrón, el contraste de color y los estados de foco deberían revisarse antes incluso de entregar el diseño. Cuando una persona editora de contenido añade una nueva imagen, debería tener una comprensión clara de cómo es un texto alternativo significativo, no solo de que se requiere texto alternativo.

Para las personas responsables de cumplimiento, la implicación práctica es la documentación. Algunos equipos ejecutan pruebas automatizadas pero nunca abordan los hallazgos. Esto no aporta ningún valor y crea documentación de que sabías de los problemas pero no los solucionaste, algo problemático en situaciones legales. Un programa de accesibilidad solo es defendible si puedes mostrar un proceso razonable y de buena fe de mejora continua: escaneos regulares, hallazgos documentados, una hoja de ruta de remediación y evidencia de que estás actuando en función de lo que aprendes. La conformidad con las WCAG no es un binario que logras una vez, es una postura que mantienes.

Herramientas como Accsible existen para apoyar este enfoque por capas: proporcionando un SDK que incorpora mejoras de accesibilidad directamente en la experiencia de usuario, sacando a la luz problemas en tiempo real y complementando el proceso de auditoría manual en lugar de intentar reemplazarlo. La superposición o el SDK adecuados no son un escudo mágico contra demandas; son un componente de un programa reflexivo que reconoce lo que la automatización puede y no puede hacer.

Conclusiones clave

• Los escáneres automatizados son un punto de partida, no una meta final. Incluso las mejores herramientas detectan entre el 30% y el 57% de las violaciones reales de las WCAG. Un informe de escaneo limpio no significa que tu sitio sea accesible, significa que se ha abordado el subconjunto detectable de problemas.
• La mayoría de los criterios de éxito de las WCAG requieren juicio humano. La experiencia con lector de pantalla, el orden lógico de lectura, el texto significativo de los enlaces en contexto, la claridad cognitiva y las interacciones complejas con teclado son áreas en las que la automatización es estructuralmente incapaz de darte una respuesta fiable.
• El entorno legal es hostil a la complacencia. Se presentaron más de 5,100 demandas federales bajo la ADA por sitios web en 2025, los acuerdos suelen costar $30,000–$85,000 más honorarios de defensa, y casi la mitad de las personas demandadas ya habían sido demandadas antes, lo que sugiere que las correcciones superficiales no son suficientes.
• Una estrategia de tres capas —escaneo automatizado, auditorías manuales expertas y pruebas reales con tecnología de apoyo— puede llevar la cobertura hacia el 80–90% y te da la postura de cumplimiento documentada y de buena fe que los tribunales y reguladores esperan ver.
• Desplaza la accesibilidad hacia la izquierda. Detectar problemas en la fase de diseño y desarrollo cuesta una fracción de lo que cuesta la remediación después del lanzamiento. Integra comprobaciones automatizadas en CI/CD, haz que la accesibilidad forme parte de tu definición de hecho y realiza auditorías manuales periódicas en tus recorridos de usuario más transitados.