Lo que las pruebas automatizadas de accesibilidad pueden demostrar y lo que no

Las pruebas automatizadas de accesibilidad pueden mostrar que partes de una página no cumplen determinados requisitos: una imagen no tiene alternativa textual, un campo de formulario no tiene etiqueta, la página no declara ningún idioma o un texto tiene menos contraste de color del que exigen las WCAG. No pueden demostrar que una página, o una tienda entera, sea conforme con las WCAG 2.2 AA.

Sobre lo que las herramientas no pueden hacer, la guía del W3C para seleccionar herramientas de evaluación de la accesibilidad web dice lo siguiente (las citas de fuentes en inglés se han traducido en esta página): «Las herramientas no pueden comprobar automáticamente todos los aspectos de la accesibilidad. Se requiere juicio humano. A veces las herramientas de evaluación pueden producir resultados falsos o engañosos. Las herramientas de evaluación de la accesibilidad web no pueden determinar la accesibilidad; solo pueden ayudar a hacerlo».

El W3C contempla ambos tipos de pruebas. Understanding Conformance, parte de los documentos Understanding WCAG 2.2 del W3C, dice que todos los criterios de conformidad de las WCAG 2 están redactados como criterios comprobables, y añade: «Probar los criterios de conformidad implicaría una combinación de pruebas automatizadas y evaluación humana».

La línea entre ambos pasa por los propios criterios de conformidad. Muchos piden a la vez algo que un programa puede encontrar y algo que tiene que juzgar una persona. El criterio de conformidad 1.1.1 pide una alternativa textual «que cumpla una finalidad equivalente». El criterio de conformidad 2.4.6 dice, en su texto completo: «Los encabezados y las etiquetas describen el tema o la finalidad». Un programa puede encontrar la alternativa textual, el encabezado y la etiqueta. Que cumplan o no su finalidad es un juicio sobre el significado.

Un escáner basado en un motor de reglas como axe-core carga una página en un navegador y aplica un conjunto de reglas a la página tal como la muestra el navegador. Cada regla busca un tipo de fallo, por ejemplo un botón sin nombre accesible, e indica el elemento en el que lo ha encontrado.

axe-core, el motor de reglas de código abierto de Deque Systems que el escáner de Validiscan ejecuta, tiene reglas para las WCAG 2.0, 2.1 y 2.2 en los niveles A, AA y AAA, además de reglas de buenas prácticas (README de axe-core). Según el recuento hecho para esta guía a partir de la lista de reglas de axe-core 4.13.0, la lista incluye 63 reglas en los niveles A y AA de las WCAG, sin contar las que marca como experimentales u obsoletas. En conjunto, estas 63 reglas están vinculadas a 20 de los 55 criterios de conformidad que tienen las WCAG 2.2 en esos niveles.

Un escaneo ve lo que hay en la página en el momento en que se ejecutan las reglas. La documentación de la API de axe-core enumera los pasos de una prueba, y el último es: «Repetir para todo el contenido inactivo o no renderizado tras hacerlo visible». Un menú, un cuadro de diálogo o un mensaje de error que solo aparece después de un clic o de enviar un formulario únicamente se prueba si algo lo abre antes. Por eso algunas comprobaciones interactúan con la página: la recorren con la tecla Tab o la muestran con un ancho reducido, y miden lo que ocurre. Las comprobaciones de Validiscan de este tipo se describen más abajo.

No. Un fallo que notifica una regla es una evidencia de que no se cumple un requisito. Un resultado superado solo muestra que la regla no encontró ningún fallo del tipo que busca.

El W3C traza esta línea para sus propias reglas de prueba. Las reglas ACT (ACT Rules) describen cómo comprobar la conformidad con las WCAG y con WAI-ARIA, y una regla ACT puede probar un único aspecto de un requisito: «una regla ACT podría comprobar que una celda de una tabla tiene un encabezado, en lugar de probar por completo el criterio de conformidad 1.3.1 “Info and Relationships”». Cuando un contenido no supera una regla ACT, no cumple el requisito correspondiente. Cuando la supera, «no se detectó ningún fallo correspondiente», lo que «no significa necesariamente que el contenido cumpla todos los aspectos del requisito de accesibilidad correspondiente». Las reglas ACT son informativas: no se requieren para determinar la conformidad con las WCAG.

El README de axe-core afirma, entre sus principios: «No devuelve ningún falso positivo (salvo errores de programación)». Añade que axe-core devuelve como «incomplete» los elementos sobre los que no pudo tener certeza y que entonces hace falta una revisión manual. Es la afirmación del propio proyecto sobre su diseño, no una medición independiente, y la guía del W3C citada más arriba advierte, de las herramientas de evaluación en general, de que pueden producir resultados falsos o engañosos. Lo que sí deja claro el diseño es que el número de fallos notificados no es un total. Cuenta lo que las reglas pudieron establecer, no todo lo que está mal.

Tres reglas de axe-core 4.13.0 muestran dónde está el límite:

• Imágenes. La regla de las imágenes da por superada una imagen que tiene un atributo alt o, entre algunas otras opciones, una etiqueta ARIA, y el mensaje que da su comprobación al superarla es «Element has an alt attribute» (el elemento tiene un atributo alt) (comprobación has-alt). La comprobación verifica que el atributo existe, no lo que dice. Un alt vacío, que marca una imagen como decorativa, también supera la regla. Juzgar si el texto describe la imagen, y si la imagen es de verdad decorativa, corresponde a una persona.
• Subtítulos de vídeo. La regla de los subtítulos da por superado un vídeo que tiene una pista de subtítulos. Si no la tiene, no puede dar el vídeo por no superado porque, como dice un comentario en su código, «los medios pueden usar otro método de subtitulado». Devuelve «pendiente de revisión» con el mensaje «Check that captions are available for the element» (comprobar que hay subtítulos disponibles para el elemento) (comprobación caption). Que los subtítulos sean exactos o no escapa a su alcance.
• Contraste de color. La comprobación del contraste calcula la relación entre el texto y su fondo, y enumera 15 motivos para devolver, en su lugar, «pendiente de revisión», entre ellos una imagen de fondo, un degradado de fondo y un elemento solapado por otro (comprobación color-contrast). El texto sobre una imagen de fondo, como un banner, pasa a «pendiente de revisión».

Según la valoración propia de Validiscan, en unos pocos criterios de conformidad de las WCAG 2.2 una prueba automática puede decidir la mayoría de los casos. En la mayoría de los criterios, una prueba automática puede establecer algunos fallos, pero si el criterio se cumple lo decide una persona. En alrededor de un tercio, solo puede decidir una persona.

Esta agrupación no es una clasificación del W3C. Se basa en el texto de cada criterio de conformidad de las WCAG 2.2, en las reglas ACT del W3C, en la lista de reglas de axe-core 4.13.0 y en un borrador de trabajo del W3C, Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them, que aquí se cita como trabajo en curso, como pide el propio borrador. El borrador resume el problema general: «Sabemos cómo comprobar automáticamente la presencia de marcado pertinente y contar sus apariciones. Sin embargo, aún no sabemos cómo verificar automáticamente la calidad de lo que ese marcado transmite al usuario».

Agrupados así, los 55 criterios de conformidad de las WCAG 2.2 de los niveles A y AA se reparten en tres grupos:

La agrupación describe lo que una prueba automática puede establecer en principio. Lo que prueba una herramienta concreta es más limitado y varía de una herramienta a otra.

En una evaluación completa, las herramientas ayudan y las personas evalúan. La metodología de evaluación del W3C da a las herramientas dos funciones: ayudar a identificar una muestra representativa y asistir a las personas que después la evalúan.

La WCAG-EM 2.0, la metodología de evaluación de las WCAG (WCAG Evaluation Methodology) que el grupo de trabajo Accessibility Guidelines Working Group del W3C publicó como Group Note el 23 de julio de 2026, tiene cinco pasos:

1. Definir el alcance de la evaluación.
2. Explorar el producto digital que se evalúa.
3. Seleccionar una muestra representativa.
4. Evaluar la muestra seleccionada.
5. Informar de los hallazgos de la evaluación.

Sobre las herramientas, la WCAG-EM 2.0 dice: «Aunque la mayoría de las comprobaciones de accesibilidad no se pueden automatizar por completo, las herramientas de evaluación pueden ayudar de forma significativa a quienes evalúan durante el proceso de evaluación y contribuir a una evaluación más eficaz». Su ejemplo: «algunas herramientas de evaluación de la accesibilidad pueden escanear un producto digital entero para ayudar a identificar muestras pertinentes para la evaluación manual».

La WCAG-EM 2.0 también distingue los estudios a gran escala de la evaluación de un solo producto. Los estudios de muchos productos se realizan «normalmente utilizando sobre todo herramientas de evaluación automatizadas», y esas evaluaciones «no suelen abordar la profundidad cualitativa necesaria de la revisión de conformidad por producto para la que está diseñada esta metodología».

En una prueba publicada sobre un conjunto conocido de barreras, ninguna de las herramientas automáticas probadas encontró más de la mitad. El Government Digital Service (GDS) del Reino Unido colocó a propósito 142 barreras de accesibilidad en una página de contenido y ejecutó en ella 13 herramientas automáticas. En su auditoría de herramientas de accesibilidad (accessibility tool audit), actualizada por última vez el 13 de abril de 2018, la mejor herramienta encontró el 40 % de las barreras y la peor, el 13 %. Si se cuentan las barreras que una herramienta señaló para que las comprobara una persona, por ejemplo si las descripciones del texto alternativo eran exactas, la mejor herramienta llegó al 50 %. El README del proyecto lo resume así: los verificadores automáticos son «buenos para encontrar problemas sencillos y evidentes, pero no son capaces de detectar muchos problemas de accesibilidad». Las cifras proceden de versiones de las herramientas de 2017 y 2018 y de una página de prueba creada para ese fin, no de una tienda real, así que muestran un intervalo, no una tasa para ninguna tienda actual.

Las herramientas pueden dar cifras distintas para la misma página. No todas prueban las mismas cosas, como muestra el intervalo de la auditoría del GDS, y no todas leen las WCAG de la misma manera. La guía de axe-core para proponer reglas dice que «no todos los evaluadores tienen la misma interpretación de las pautas de accesibilidad» y que todas sus reglas deben ser coherentes con la interpretación de Deque Systems, la desarrolladora de axe-core.

Los estudios automatizados a gran escala muestran el mismo límite desde el otro lado. El análisis de WebAIM de las páginas de inicio del millón de sitios web principales, con datos de febrero de 2026, detectó fallos de las WCAG 2 en el 95,9 % de ellas. WebAIM añade su propia advertencia: «Como solo se tuvieron en cuenta los fallos de las WCAG detectables automáticamente, esto sugiere que la tasa de conformidad plena con las WCAG 2 A/AA era sin duda inferior al 4,1 %». Los seis tipos de fallo que encontró con más frecuencia son todos de los que puede detectar una regla automática: texto con poco contraste, falta de texto alternativo en las imágenes, falta de etiquetas en los campos de formulario, enlaces vacíos, botones vacíos y falta de idioma del documento. Una lista así muestra lo que las herramientas pueden ver. No es una clasificación de todas las barreras.

El escáner de Validiscan ejecuta reglas automáticas y una persona recorre una lista de comprobación manual. Qué criterios de conformidad prueban las reglas y cuáles tienen un punto en la lista se publica criterio por criterio.

El escáner ejecuta 102 reglas: 79 reglas de axe-core y 23 comprobaciones que escribió el propio Validiscan, muchas de ellas para lo que axe-core no comprueba, como las trampas de teclado, el orden del foco y la adaptación del contenido al ancho de pantalla (reflow). Otras 11 reglas de axe-core están desactivadas porque una comprobación propia de Validiscan comprueba lo mismo, de modo que un elemento nunca genera dos hallazgos, y 15 no se ejecutan porque axe-core las marca como experimentales u obsoletas, o porque solo comprueban el nivel AAA. El catálogo de reglas enumera cada regla con su estado.

Algunas comprobaciones propias de Validiscan interactúan con la página. Una de ellas: «Sigue la secuencia de Tab y detecta bucles y callejones sin salida»; otra: «Muestra las páginas con un ancho de 320 píxeles CSS (el equivalente a un zoom del 400 %)». Miden el comportamiento. No juzgan el significado.

De los 55 criterios de conformidad de las WCAG 2.2 de los niveles A y AA, 33 los comprueba al menos una regla que ejecuta el escáner. Los otros 22 no los comprueba ninguna regla que ejecute el escáner, y cada uno de ellos tiene un punto en la lista de comprobación manual, de 35 puntos. La lista también tiene puntos para algunos criterios que una regla solo comprueba en parte, como el manejo con el teclado, el orden del foco y los subtítulos. Para los demás criterios que comprueba una regla, la lista no tiene ningún punto. La matriz de criterios muestra, para cada criterio de conformidad, las reglas que lo comprueban y si la lista de comprobación manual tiene un punto para él.

Para cada punto de la lista, Validiscan registra superado, no superado o no aplicable, con notas y, si lo hay, un archivo de evidencia. Los resultados forman parte del Remediation Evidence Package, en su sección «Revisión manual y hallazgos excluidos». La sección «Alcance y metodología» del paquete enumera los límites de la evaluación, entre ellos:

• «Las pruebas automáticas solo detectan una parte de las barreras de accesibilidad. Un criterio solo se considera cumplido cuando las pruebas automáticas lo cubren por completo o cuando se ha superado una revisión manual».
• «El contenido de marcos de otro origen (cross-origin) y de shadow DOM cerrado, como los campos de pago y algunas herramientas de consentimiento y widgets, no se evalúa de forma automática».

En la aplicación de Validiscan, se considera que las pruebas automáticas cubren por completo un criterio cuando lo comprueba una regla que ejecuta el escáner y la lista de comprobación manual no tiene ningún punto para él. Para un criterio así, un resultado «Cumple» en el paquete se apoya solo en pruebas automáticas. A fecha de 6 de octubre de 2026, entre esos criterios hay algunos que la agrupación anterior deja para que los decida una persona, como el 1.1.1 Non-text Content y el 2.4.4 Link Purpose (In Context).

Hoy el escáner no conserva los resultados que una regla marca para revisión, así que no aparecen como hallazgos. La página del método lo incluye entre los límites.

El paquete indica, criterio por criterio, la conformidad con los criterios de conformidad de las WCAG 2.1 AA y de las WCAG 2.2 AA, tal como se evaluaron en las páginas y fechas indicadas. Este paquete aporta evidencias de una evaluación y de trabajos de corrección. No es un certificado y no afirma el cumplimiento de ninguna obligación legal. La revisión gratuita es solo automática, sin revisiones manuales, así que los fallos que notifica no son un total.