Actualizado el 28 de septiembre de 2026. Volvimos a medir las 88 páginas de inicio después de encontrar y corregir errores en nuestro propio verificador: había contado algunos problemas de mejores prácticas como fallos de WCAG, y leyó mal los colores de ciertos botones, incluyendo dos de los ejemplos en la primera versión de este artículo. Cada cifra a continuación es la nueva medición, y la verificamos cruzadamente con axe-core. Las cifras originales se enumeran al final para que puedas ver qué cambió.
Las agencias web construyen y cuidan una gran parte de la web. Así que hicimos una pregunta simple: ¿qué tan accesibles son los sitios web de las propias agencias?
Realizamos una verificación automatizada de WCAG 2.1 AA en las páginas de inicio de 88 agencias web WordPress en el Reino Unido, Estados Unidos, Canadá, Australia, Países Bajos e Irlanda. 80 de ellas pudieron escanearse. Esto es lo que encontramos, y lo que significa si construyes o mantienes sitios de clientes.
Hallazgos clave
- El 82% de las páginas de inicio de agencias (66 de 80) tenían al menos un fallo claro de WCAG 2.1 Nivel A/AA: bajo contraste de texto, foco de teclado invisible, controles sin nombre accesible, texto alternativo faltante y similares. axe-core, el motor de código abierto en el que se basan muchas herramientas de accesibilidad, encontró al menos un fallo de WCAG 2.1 A/AA en el 88% de las mismas páginas.
- El 68% tenía texto que no cumple con el contraste mínimo (WCAG 1.4.3); axe-core: 70%. El sitio con fallo mediano tenía 3 hallazgos de contraste separados.
- El 45% tenía elementos interactivos sin indicador de foco de teclado visible (WCAG 2.4.7).
- El 40% tenía enlaces, botones o widgets ARIA que un lector de pantalla no puede nombrar correctamente (WCAG 4.1.2); axe-core, que ejecuta más de estas verificaciones, encontró el 55%.
- El 31% falló tres o más criterios diferentes de WCAG.
- La puntuación automatizada mediana fue 88/100. 32 de 80 sitios obtuvieron 90 o más.
Los resultados en detalle
Porcentaje de páginas de inicio de agencias escaneadas (n = 80) con al menos un hallazgo para cada criterio de éxito de WCAG 2.1:
| Criterio WCAG | Qué significa | Sitios afectados |
|---|---|---|
| 1.4.3 Contrast (Minimum) — AA | Color de texto demasiado cercano a su fondo | 54 (68%) |
| 2.4.7 Focus Visible — AA | Sin contorno visible cuando presionas Tab en un elemento | 36 (45%) |
| 4.1.2 Name, Role, Value — A | Botones/enlaces sin nombre accesible, contenido enfocable oculto para lectores de pantalla, ARIA inválido | 32 (40%) |
| 1.1.1 Non-text Content — A | Imágenes significativas sin texto alternativo, o un nombre de archivo como texto alternativo | 14 (18%) |
| 1.4.11 Non-text Contrast — AA | Bordes de campos de formulario demasiado tenues para ver dónde está el campo | 8 (10%) |
| 1.4.4 Resize Text — AA | Configuración de viewport que bloquea el zoom de pellizco en móvil | 6 (8%) |
Por país, las agencias holandesas tuvieron la puntuación mediana más alta (92, n = 15), seguidas por Irlanda (91, n = 8), Australia (84), el Reino Unido (83), Estados Unidos (82) y Canadá (70, n = 5). Las muestras por país son pequeñas, así que tómalo como una pista, no como un ranking, pero es interesante dado que la Ley Europea de Accesibilidad se aplica en la UE desde el 28 de junio de 2025.
Cómo se ven realmente los fallos
Ninguno de estos es exótico. Son los patrones cotidianos que provienen de constructores de páginas, valores predeterminados de temas y paletas de marca que nunca se verificaron en contraste:
- Llamados a la acción en el color de la marca. Los botones "Client Login", "View our services" y "Get in touch" de una agencia son texto blanco sobre un verde medio a 2.63:1. AA requiere 4.5:1 para texto de ese tamaño.
- Texto gris medio sobre un fondo claro. Etiquetas de sección en #888888 sobre #f8f8f8 resultan en 3.34:1: lo suficientemente cerca para verse bien al diseñador, no lo suficiente para aprobar.
- Enlaces y botones sin nombre (29 sitios): típicamente un enlace de logo o un botón de icono. Un lector de pantalla anuncia solo "enlace" o "botón", por lo que los usuarios no pueden saber a dónde va.
- Oculto pero enfocable (3 sitios). Menús y deslizadores envueltos en
aria-hidden="true"que aún contienen enlaces enfocables: los usuarios de teclado aterrizan en elementos que los lectores de pantalla no pueden ver. outline: nonesin reemplazo (36 sitios). Los usuarios de teclado pierden la noción de dónde están en la página.
Por qué esto importa para las agencias
Si el propio sitio insignia de una agencia, generalmente en el que invierte más cuidado, tiene estos problemas, los mismos patrones probablemente estén en los sitios de clientes construidos con los mismos temas, constructores y hábitos. Esto es cada vez más un riesgo comercial, no solo una brecha de mejores prácticas:
- UE: la Ley Europea de Accesibilidad cubre muchos servicios de comercio electrónico y en línea desde el 28 de junio de 2025, con EN 301 549 referenciando WCAG 2.1 AA.
- Reino Unido: la Equality Act 2010 requiere ajustes razonables para usuarios discapacitados, y los sitios del sector público deben cumplir con WCAG 2.2 AA.
- Estados Unidos: las demandas de accesibilidad web bajo la ADA continúan apuntando a empresas de todos los tamaños.
La buena noticia: la mayoría de los fallos anteriores son arreglos rápidos: un token de color, un aria-label, un estilo :focus-visible, un atributo alt. La parte difícil es notarlos en docenas de sitios de clientes, y notarlos nuevamente cuando una actualización de plugin o una nueva página de destino los trae de vuelta.
Metodología
- Muestra: 88 agencias tomadas de los resultados de búsqueda de Google para "WordPress web design agency" más una ciudad (Londres, Manchester, Nueva York, Chicago, Los Ángeles, Austin, Toronto, Sídney, Melbourne, Ámsterdam, Utrecht/Róterdam, Dublín), más un pequeño conjunto de agencias de planes de cuidado WordPress del Reino Unido y Países Bajos. Se excluyeron directorios y sitios de clasificación. No estamos nombrando agencias: el punto es el patrón, no alguna empresa en particular.
- Escaneados: 80 páginas de inicio el 28 de septiembre de 2026. 8 no pudieron escanearse porque la protección contra bots bloqueó los navegadores automatizados.
- Cómo: cada página de inicio se cargó en Chrome sin interfaz gráfica en un viewport de escritorio de 1440×900 y se verificó con las mismas reglas determinísticas que alimentan el verificador de accesibilidad gratuito de QA Proof (sin IA involucrada en los hallazgos). Las mismas páginas también se ejecutaron a través de axe-core 4.13 como verificación cruzada independiente.
- Qué cuenta como "fallo claro": hallazgos mapeados a los criterios WCAG 2.1 A/AA 1.1.1, 1.4.3, 1.4.4, 1.4.11, 2.4.2, 2.4.7, 3.1.1 y 4.1.2. Deliberadamente excluimos de las cifras principales todo lo que es consejo en lugar de un fallo de WCAG: tamaño de objetivo WCAG 2.2, contenido fuera de regiones de referencia, orden de encabezados, IDs duplicados y texto cuyo fondo no pudo determinarse de manera confiable.
- Límites: solo página de inicio; las verificaciones automatizadas detectan solo parte de WCAG, y ninguna herramienta automatizada está libre de falsos positivos o errores: los dos motores anteriores no coinciden en lugares. Un escaneo automatizado aprobado no significa que un sitio sea accesible: aún se necesitan pruebas manuales con teclado y lector de pantalla.
- Qué cambió el 28 de septiembre: la primera versión (17 de septiembre, 73 sitios escaneados) reportó 90% con al menos un fallo claro, 74% contraste, 64% controles sin nombre, 42% foco invisible y una puntuación mediana de 76. Parte de esa diferencia son los errores de nuestro verificador, que corregimos (contó algunos problemas de mejores prácticas y algunos elementos invisibles como fallos, y leyó el color de un botón en lugar del color de su texto), y parte es simplemente que los sitios cambiaron en once días.
Verifica tu propio sitio (o el de un cliente)
Puedes ejecutar la misma verificación en cualquier página pública en aproximadamente un minuto, sin registro: qaproof.io/free-accessibility-checker. Muestra tu puntuación, el desglose de gravedad y los problemas principales con el elemento exacto y el fragmento de código.
Para agencias que cuidan muchos sitios, la auditoría de accesibilidad completa de QA Proof agrega cada hallazgo, guía de solución e informes PDF que puedes compartir con clientes, y el monitoreo visual detecta roturas de diseño después de actualizaciones de plugins y temas.