Metodología: cómo medimos la accesibilidad de los sitios municipales

Versión 1.1 · 1 de septiembre de 2026 · Maksim Galatin & Claude (Anthropic) · licencia CC BY 4.0

Por qué hizo falta una metodología aparte

Mediciones automáticas de accesibilidad hay muchas en el mundo. Las realizan escáneres como axe-core: son baratos, reproducibles y miden el marcado de la página.

Datos sobre lo que ocurre al intentar recorrer el camino con el teclado casi no existen. Un conjunto de reglas revisa el marcado; no intenta llegar al objetivo. Hace falta un recorrido que pulse Tab de verdad en una página viva y observe dónde queda el foco.

Hacemos ambas mediciones y las comparamos entre sí. La discrepancia entre ellas es el resultado principal de este trabajo, y solo aparece cuando ambas revisiones recorren exactamente la misma muestra.

Parte I. Medición automática

Qué entra en la muestra

Para EE. UU., el registro oficial de dominios .gov de la agencia CISA (cisagov/dotgov-data, licencia CC0, actualizado a diario). De él se toman las organizaciones de tipo City y County: 11 659 registros en 51 estados y territorios.

Es una diferencia importante frente a una selección reunida mediante búsquedas. A la pregunta «¿de dónde sacaron estas ciudades?» hay una respuesta verificable en un minuto: todo el registro oficial, no lo que logramos encontrar.

Para Europa, organizaciones municipales de OpenStreetMap según las etiquetas amenity=townhall, office=government y afines.

Cómo revisamos

Un navegador real (Chromium mediante Puppeteer), no una petición HTTP. La razón: buena parte de los sitios actuales se construye con scripts, y revisar el HTML de origen mide algo distinto de lo que ve una persona.

En cada sitio: abrimos la página y esperamos el evento domcontentloaded; ejecutamos axe-core, un conjunto abierto de reglas conforme a WCAG 2.1 AA; registramos cada regla que se activa, el número de apariciones y el selector del DOM; buscamos la página de pago y comprobamos el camino hasta ella.

Qué contamos y cómo

Densidad de infracciones = número de reglas activadas dividido por el número de páginas revisadas. Densidad y no cifra absoluta: un sitio grande tiene más páginas, y comparar por suma de infracciones equivale a penalizar el tamaño.

Lo que NO hacemos, y esto importa

No condenamos un sitio entero por una sola página, no contamos las advertencias como infracciones y no sustituimos la medición por un juicio. La parte automática responde únicamente a si una regla se activó, y a nada más.

Parte II. Recorrido por teclado

Aquí empieza lo que ninguna auditoría automática hace.

La tarea encomendada

Recorrer el camino de una persona que quiere pagar un impuesto o una multa municipal usando solo el teclado. No tocar el ratón en absoluto.

Quién realiza la revisión

El recorrido lo realiza un agente informático en un navegador Chrome real, no una persona sentada ante una mesa. Lo decimos con claridad, porque de esa respuesta depende cómo deben leerse todas las cifras que siguen.

El agente maneja una página real igual que una persona sin ratón: pulsa Tab, lee adónde se ha desplazado el foco y se detiene donde ya no hay adónde desplazarse. No analiza el HTML de origen ni juzga por el marcado: recorre la página viva con todos sus scripts, avisos de consentimiento y ventanas emergentes.

Lo que esto aporta. Reproducibilidad: el mismo recorrido puede repetirse y dar el mismo resultado, mientras que a una persona real no se la puede sentar ante 67 000 páginas ni pedirle que repita el camino un mes después. Y escala: una medición de este tamaño sencillamente no se hace a mano, y por eso hasta ahora no existían estos datos.

Lo que esto NO aporta, y lo reconocemos. El agente no sustituye a un usuario de lector de pantalla ni mide hasta qué punto la página resultó comprensible. Responde a una sola pregunta: si es físicamente posible llegar al objetivo solo con el teclado. No afirmamos haber realizado pruebas con participantes ciegos: no las hicimos.

Qué se registra en cada sitio

El último campo es el decisivo: permite comparar dos mediciones sobre un mismo objeto.

Qué se considera barrera

• El foco no se ve (outline: none): no se sabe dónde se está
• Trampa de foco: no se puede salir del elemento con el teclado
• Campo sin etiqueta: el lector de pantalla no puede decir qué introducir
• Un botón que no es un botón: un div con manejador no recibe el foco
• Ventana modal que no se cierra con la tecla Escape

Cómo se elige la muestra del recorrido

Se revisan ambos grupos: los sitios que la revisión automática consideró accesibles y los que rechazó. De otro modo tendríamos una medición unilateral que solo muestra los errores que nos convienen.

Parte III. Qué arroja la comparación

La magnitud principal de esta investigación es la discrepancia entre la máquina y el recorrido, y se mide en ambos sentidos:

Falsa tranquilidad — la revisión automática dice «accesible» y el recorrido no pasa.
Falsa alarma — la revisión automática rechaza la página y el recorrido sí pasa.

Estado del trabajo a fecha de 1 de septiembre de 2026

Limitaciones que reconocemos

1. El recorrido de EE. UU. ha terminado: se ha recorrido todo el registro CISA, 11 659 sitios de 11 659. Las cifras de EE. UU. son definitivas; solo cambiarán al incorporar otros países, y se dirá con claridad.

2. No todos los registros tienen captura. Donde la página no llegó a abrirse, no había nada que capturar.

3. Una barrera antirrobots no es lo mismo que la inaccesibilidad. No sabemos qué hay detrás y no lo anotamos como barrera.

4. El recorrido no sustituye a un usuario real. Responde a una sola pregunta: si es físicamente posible llegar al objetivo solo con el teclado. El objetivo es DISTINTO en cada uno de los ocho tipos de página: encontrar un documento, presentar una solicitud 311, llegar al paso de pago, encontrar el acta de una sesión, la navegación principal, una oferta de empleo, un contacto, un evento del calendario. Las cifras globales — 74,6 % no llegaron, 25,4 % sí — abarcan los ocho objetivos, no uno solo. El objetivo de pago por sí solo: 19,0 % llegaron.

5. El umbral de 40 pulsaciones de Tab es nuestro. Se justifica porque la mediana de un camino exitoso son tres pulsaciones, pero sigue siendo una elección nuestra y no un estándar. Comprobado con un análisis de sensibilidad: los umbrales de 40, 60 y 100 dan cifras IDÉNTICAS — nadie alcanza la meta más allá de cuarenta pulsaciones y el percentil 99 de los caminos exitosos es 35. Umbrales menores sí cambian el resultado: con 30 la proporción baja 0,6 puntos, con 20 baja 2,1 y con 10 baja 5,7. La cifra principal se mueve igual: 53,8 % con 40, 55,0 % con 30, 57,6 % con 20. Cuarenta es, por tanto, un margen y no una decisión de modelado.

6. Los sitios inaccesibles para la revisión automática quedaban antes fuera de la muestra por completo. Son 787, entre ellos Nueva York al completo; 230 de esos municipios están obligados a cumplir el plazo del 26 de abril de 2027. Los estamos recorriendo aparte, en el mismo orden: de los grandes a los pequeños.

7. Parte de las páginas se revisó dos veces, y calculamos qué cambia eso. El recorrido avanza por rondas y una misma dirección vuelve a aparecer a veces: 348 registros de 95 524, el 0,4 % del historial. Recalculamos todas las proporciones dejando un solo registro, el más reciente, por cada par «dirección y tipo de página». La cifra principal no se movió en absoluto: 74,6 % antes y después; la proporción de los que llegaron, 25,4 % en ambos casos. Una diferencia de una centésima de punto, que mencionamos aquí para no tener que explicarla después.

8. Las observaciones no son independientes, y lo hemos medido. Las ocho tareas de un mismo sitio están relacionadas: un sitio mal construido suele fallar en las ocho. La correlación intraclase es 0,263 y el factor de inflación de la varianza 2,72 — ocho tareas no dan ocho observaciones independientes, sino unas tres. El tamaño efectivo de la muestra es 17 272 en lugar de 47 036 registros medibles. El intervalo de confianza de la cifra principal, corregido por esto: 52,7 % [51,7; 53,8]. Sin corregir sería [53,2; 54,4], casi la mitad de ancho, y sería falso. Aparte: contando por municipio en vez de por página — un voto por sitio — da 52,7 % frente a 53,8 %. Una diferencia de 1,1 puntos: la conclusión no depende de la unidad de conteo.

Apertura

• Los datos brutos se publican íntegros, incluidos los registros que no nos convienen
• El código de revisión es abierto
• Se adjuntan las capturas del recorrido: una por cada página revisada
• Los errores de versiones anteriores se describen en la propia metodología y no se reescriben a posteriori

También nos revisamos a nosotros mismos

Una investigación sobre accesibilidad cuyos propios sitios no son accesibles no vale nada. El 27 de agosto de 2026 sometimos nuestros cuatro sitios al mismo procedimiento que los municipales: con teclado, en un navegador real, comprobando la visibilidad del foco en cada paso.

Digamos aparte lo que encontramos en nosotros mismos. En nuestro código hay 83 apariciones de outline: none, precisamente la línea que provoca el 31 % de todas las interrupciones en nuestra propia investigación. Son inofensivas solo porque las anula una regla global :focus-visible. Esa es justamente la diferencia entre «está mal escrito» y «funciona mal», y la mostramos con nuestro propio ejemplo.

Declaración de conflicto de intereses

Cómo citar

Maksim Galatin & Claude (Anthropic). Municipal Website Accessibility: Automated Scan versus Keyboard Traversal. AIfa Works, 2026. CC BY 4.0. aifa.works/research/methodology

Comentarios

Si encuentra un error en la metodología o en los datos, escríbanos: contact@codeofdigitaleternity.com

Los datos en sí — aifa.works/research/data