Metodología

Qué norma aplicamos

El capítulo 9 de la UNE-EN 301 549 adopta WCAG 2.1 en niveles A y AA para contenido web, así que ejecutamos exactamente ese conjunto de reglas: wcag2a, wcag2aa, wcag21a y wcag21aa.

Las reglas de buenas prácticas quedan deliberadamente fuera. Un incumplimiento de buenas prácticas no es un incumplimiento legal, y mezclarlos inflaría las cifras.

Cómo se analiza cada web

• Chromium real mediante Playwright, ventana de 1440x900, idioma es-ES.
• Hasta 4 páginas por sitio: la portada más una selección de secciones distintas, priorizando el recorrido de compra (producto, categoría, carrito) sobre los avisos legales. Las páginas legales son texto plano y puntúan mejor que el resto de un sitio; gastar ahí el presupuesto de páginas habría favorecido a todos los analizados.
• 2,5 segundos de espera tras la carga, más espera de red inactiva, para que el contenido dinámico y los banners de cookies estén presentes. Se evalúa la página tal y como la recibe una persona.
• Se respeta robots.txt. Nunca solicitamos rutas excluidas.

Las páginas bloqueadas se descartan, no se aprueban

Los sistemas anti-bot devuelven pantallas de «Acceso denegado» o de verificación, a menudo con código HTTP 200. Un analizador apuntado a una de esas pantallas encuentra muy pocos problemas y produce una puntuación casi perfecta de un sitio que nunca llegó a ver.

Por eso descartamos toda página cuya respuesta sea un error, cuyo título coincida con un patrón de verificación conocido o cuyo contenido sea mínimo y contenga marcas de sistemas anti-bot. Un sitio en el que no pudimos evaluar ninguna página se declara bloqueado, nunca conforme.

En el estudio, 5 sitios bloquearon el análisis y 10 no respondieron. Los porcentajes se calculan sobre los 217 sitios realmente evaluados.

Sobre presentarnos como un navegador normal

Chromium en modo headless declara navigator.webdriver = true mientras envía un identificador de Chrome corriente. Esa contradicción es en sí misma la señal que activa los bloqueos: en la primera pasada convirtió el 41% de la muestra en errores 403, incluidas tres de las mayores cadenas de distribución españolas, que respondieron con normalidad en cuanto se eliminó la incoherencia.

El análisis se ejecuta por tanto sin ese distintivo de automatización. El límite es explícito:

• Sí hacemos: presentarnos de forma coherente como el navegador Chromium corriente que somos.
• No hacemos: resolver captchas, rotar direcciones IP, usar proxies residenciales, ignorar robots.txt ni reintentar tras una negativa.

Hay también un argumento de honestidad estadística: un 41% de bloqueos no produce una muestra neutra, sino que elimina justo a las empresas con más inversión en infraestructura, que son plausiblemente también las que más han invertido en accesibilidad.

Qué pueden y qué no pueden decir estas cifras

El análisis automático detecta en torno al 57% de los problemas de accesibilidad, según el estudio de Deque sobre más de 2.000 auditorías y 13.000 páginas. El resto exige criterio humano.

De ahí se siguen dos consecuencias opuestas:

• Un fallo detectado es un fallo real. Estas reglas producen muy pocos falsos positivos. Si un botón no tiene nombre accesible, una persona ciega no puede saber qué hace.
• Un resultado limpio no es un aprobado. El análisis automático no puede demostrar conformidad, sólo refutarla. Por eso nuestros informes dicen «sin fallos automáticos» y nunca «conforme».

El porcentaje de incumplimiento que publicamos es, por tanto, un suelo. La cifra real es más alta.

La puntuación de 0 a 100

Existe para ordenar sitios, no para expresar un veredicto legal. Cada regla incumplida resta según su gravedad (crítico 8, grave 5, moderado 2, leve 0,5), escalado por su extensión en las páginas analizadas.

El resultado con significado normativo es el veredicto binario: la conformidad WCAG es de todo o nada, y basta un criterio A o AA incumplido para que la página no sea conforme.