Su sitio obtiene 100/100 en la auditoría axe-core. Y sin embargo, desde la última actualización de CSS, el contraste de sus botones cayó por debajo del umbral legal y el indicador de foco desapareció — invisible para el analizador de código, pero muy real para el usuario y para el regulador. Es el punto ciego de las herramientas de accesibilidad clásicas: leen el código, no el renderizado.
Y lo que está en juego no es solo estético. Las obligaciones de accesibilidad web varían según la jurisdicción: la Unión Europea impone el nivel AA a través del European Accessibility Act, los Estados Unidos exigen la conformidad con la Section 508 bajo el ADA, Canadá alinea el ACA con el WCAG 2.1 AA, y el Reino Unido aplica sus propias reglas a través del Equality Act. Esta guía compara los requisitos por región, detalla los pasos de un test WCAG completo y explica cómo el test visual automatizado complementa las herramientas de análisis estático para cubrir el conjunto de los criterios.
¿Su auditoría de código dice «conforme», pero la pantalla cuenta otra cosa? Delta-QA detecta las desviaciones de contraste, de foco o de maquetación que los analizadores estáticos no ven, en local y sin registro. Probar Delta-QA gratis →
Índice
- Lo que las WCAG exigen visualmente
- Requisitos de prueba WCAG por región
- Cómo realizar un test WCAG completo: los pasos
- Por qué las herramientas de accesibilidad clásicas no son suficientes
- Las pruebas visuales como red de seguridad para la accesibilidad
- Los criterios WCAG que las pruebas visuales detectan de forma nativa
- Cómo implementar una vigilancia visual de la accesibilidad
- La accesibilidad visual no es un lujo, es una obligación
- FAQ
Lo que las WCAG exigen visualmente
Las WCAG (Web Content Accessibility Guidelines) en su versión 2.2 contienen 86 criterios de éxito repartidos en tres niveles de conformidad: A, AA y AAA. Entre estos criterios, una proporción significativa concierne directamente a la apariencia visual de las interfaces.
Veamos los más importantes.
El contraste de colores (criterio 1.4.3 para el nivel AA, 1.4.6 para el AAA) impone una relación de contraste mínima de 4.5:1 para el texto normal y de 3:1 para el texto de gran tamaño. Este criterio es puramente visual: se verifica comparando los colores del texto y su fondo.
El tamaño del texto (criterio 1.4.4) exige que el contenido pueda ampliarse hasta el 200% sin pérdida de información ni de funcionalidad. Esto significa que a un zoom del 200%, el texto no debe desbordar sus contenedores, los elementos no deben superponerse y la información debe seguir siendo legible. Todo esto es verificable visualmente.
El indicador de foco (criterio 2.4.7 para el AA, reforzado por 2.4.11 y 2.4.12 en WCAG 2.2) requiere que cada elemento interactivo muestre un indicador visible cuando recibe el foco del teclado. Este indicador debe tener un contraste suficiente y una superficie mínima. Una vez más, es un criterio visual.
El espaciado del texto (criterio 1.4.12) exige que el contenido siga siendo funcional cuando el usuario modifica la altura de línea a 1,5 veces el tamaño de fuente, el espaciado entre párrafos a 2 veces, el espaciado entre letras a 0,12 veces y el espaciado entre palabras a 0,16 veces. Si estos ajustes rompen la maquetación, es una violación de accesibilidad detectable visualmente.
El redimensionamiento del contenido (criterio 1.4.10, también llamado "reflow") impone que el contenido se muestre sin desplazamiento horizontal a una anchura de 320 píxeles CSS. Es exactamente lo que verifica la prueba responsive.
La conclusión es clara: una parte importante de la conformidad WCAG se basa en propiedades visuales medibles.
Requisitos de prueba WCAG por región
Las obligaciones legales en materia de accesibilidad digital difieren según las jurisdicciones. El cuadro siguiente compara los requisitos de cuatro regiones principales.
| Región | Norma requerida | Nivel WCAG obligatorio | Fecha / Año | Texto legal | Herramienta(s) recomendada(s) |
|---|---|---|---|---|---|
| UE / EAA | EN 301 549 (alineada con WCAG 2.1) | AA | Junio 2025 (entrada en vigor) | European Accessibility Act (EAA) — Directiva 2019/882 | axe-core, WAVE, Lighthouse |
| US / ADA + Section 508 | Section 508 (alineada con WCAG 2.0) | AA | Section 508: enero 2018 (actualización); ADA: jurisprudencia continua | ADA.gov — Section 508 (29 U.S.C. § 794d) | axe-core, ANDI, WAVE |
| Canadá / ACA | ACA (alineada con WCAG 2.1) | AA | Junio 2024 (fase 1); junio 2025 (fase 2) | Ley Canadiense sobre la Accesibilidad (ACA) | axe-core, Accessibility Insights |
| UK / EQS | Public Sector Bodies Accessibility Regulations 2018 | AA | Septiembre 2020 (sector público) | Equality Act 2010 — Accessibility Regulations | axe-core, WAVE, Pa11y |
Puntos clave del cuadro:
- Las cuatro jurisdicciones exigen como mínimo el nivel WCAG AA. Ninguna impone AAA, pero alcanzarlo reduce el riesgo jurídico.
- La Unión Europea tiene la fecha límite más reciente y la más restrictiva con el EAA, que cubre también el sector privado.
- Los Estados Unidos permanecen en WCAG 2.0 a través de la Section 508, pero los tribunales aplican cada vez más WCAG 2.1 AA como referencia bajo el ADA.
- Canadá y el Reino Unido se han alineado con WCAG 2.1 AA, con calendarios de aplicación escalonados.
- axe-core, desarrollado por Deque Systems, es la herramienta más citada en todas las jurisdicciones — se integra con los frameworks de prueba y el CI/CD.
Cómo realizar un test WCAG completo: los pasos
Un test WCAG completo combina análisis automatizado, verificación visual y auditoría manual. Estos son los pasos a seguir, en orden.
- Definir el perímetro del test. Identifique las páginas y componentes a probar, la o las jurisdicciones aplicables (cf. cuadro anterior) y el nivel de conformidad objetivo (AA en la casi totalidad de los casos).
- Ejecutar un análisis automatizado con axe-core. Ejecute axe-core en cada página del perímetro. Esta herramienta detecta aproximadamente entre el 30 y el 50 % de las violaciones WCAG — aquellas verificables por análisis del DOM (alternativas textuales faltantes, roles ARIA incorrectos, estructura de encabezados, atributos de formulario).
- Ejecutar una auditoría Lighthouse. Complemente el análisis axe-core con Google Lighthouse, que evalúa la categoría «Accessibility» sobre 100 y señala los problemas comunes con sugerencias de corrección.
- Verificar los criterios visuales mediante prueba de captura de pantalla. Capture sus páginas en condiciones de accesibilidad: zoom 200 %, anchura 320 px, espaciados WCAG inyectados (criterio 1.4.12), foco de teclado forzado. Compare los resultados con una baseline conforme para detectar las regresiones. El test de regresión visual es el método más fiable para este paso.
- Probar manualmente la navegación por teclado. Recorra cada página únicamente con el teclado (Tab, Shift+Tab, Enter, Espacio, flechas). Verifique que el orden de tabulación es lógico, que cada elemento interactivo recibe un foco visible y que no existe ninguna trampa de teclado.
- Verificar la compatibilidad con las tecnologías de asistencia. Pruebe sus páginas con un lector de pantalla (NVDA en Windows, VoiceOver en macOS/iOS, TalkBack en Android). Verifique que el contenido se anuncia correctamente, que los landmarks de región están presentes y que los formularios son utilizables.
- Probar en varios navegadores y dispositivos. Los problemas de accesibilidad varían de un motor de renderizado a otro. Un contraste conforme en Chrome puede no serlo en Safari. El test visual cross-browser captura estas diferencias.
- Documentar los resultados y las correcciones. Para cada violación detectada, referencie el criterio WCAG concernido, la jurisdicción aplicable, la gravedad y la corrección aplicada. Esta documentación sirve como prueba de conformidad en caso de inspección.
- Integrar las pruebas en el pipeline CI/CD. Automatice los pasos 2, 3 y 4 para que se ejecuten en cada pull request. Cualquier regresión se bloquea antes de la puesta en producción.
- Planificar una auditoría recurrente. Incluso con una automatización completa, una auditoría manual trimestral o semestral por un experto WCAG sigue siendo recomendada para cubrir los criterios no automatizables.
Por qué las herramientas de accesibilidad clásicas no son suficientes
Las herramientas de auditoría de accesibilidad como axe-core o Lighthouse son indispensables. Analizan el DOM, verifican los atributos ARIA, detectan las etiquetas faltantes y señalan las violaciones estructurales. Nadie cuestiona eso.
Pero estas herramientas tienen una limitación fundamental: analizan el código, no el renderizado. Verifican lo que el HTML y el CSS declaran, no lo que el usuario ve realmente.
Un ejemplo concreto. Imagina un botón cuyo texto es blanco sobre fondo azul, con una relación de contraste conforme de 5.2:1. Durante una actualización de CSS, un desarrollador modifica el color de fondo del botón para hacerlo más claro, sin tocar el texto. La relación cae a 2.8:1. axe-core puede detectar esto en algunos casos, pero solo si la hoja de estilos es correctamente interpretada por el motor de análisis. Las pruebas visuales, en cambio, capturan esta regresión inmediatamente, porque comparan el renderizado real del botón antes y después de la modificación.
Otro caso frecuente: el indicador de foco se define en CSS, pero una actualización del framework elimina o sobrescribe el estilo outline. Funcionalmente, el botón sigue siendo clicable. Estructuralmente, el HTML está intacto. Pero visualmente, el foco ha desaparecido. Ninguna herramienta de análisis del DOM señala este problema de manera fiable. Las pruebas visuales detectan la diferencia de renderizado.
Estas herramientas tampoco detectan los problemas relacionados con el zoom. Cuando un usuario amplía el texto al 200%, los desbordamientos, las superposiciones y los textos truncados son problemas puramente visuales. No aparecen en el análisis estático del código.
Las herramientas de accesibilidad clásicas son necesarias pero insuficientes. Cubren los criterios estructurales (alternativas textuales, estructura de encabezados, roles ARIA), pero dejan un punto ciego en todo lo que se refiere al renderizado visual.
Las pruebas visuales como red de seguridad para la accesibilidad
Las pruebas visuales automatizadas consisten en capturar capturas de pantalla de tus páginas y componentes, y luego compararlas con una referencia (baseline) para detectar cualquier cambio visual no intencionado. Aplicado a la accesibilidad, este mecanismo se convierte en una red de seguridad formidable.
He aquí por qué.
Detecta regresiones, no solo violaciones. Una auditoría de accesibilidad te dice si tu sitio es conforme en un momento dado. Las pruebas visuales te alertan en cuanto un cambio de código degrada la accesibilidad visual. Es la diferencia entre un diagnóstico y un sistema de alarma.
Funciona sobre el renderizado real. Las pruebas visuales capturan lo que el navegador muestra realmente, después de aplicar todas las hojas de estilos, los scripts JavaScript y los cálculos de layout. No interpreta el CSS, constata el resultado.
Cubre los casos multi-navegador y multi-resolución. Los problemas de accesibilidad visual varían según los navegadores y los tamaños de pantalla. Un contraste conforme en Chrome puede no serlo en Safari si las fuentes se renderizan de forma diferente. Las pruebas visuales cross-browser capturan estas diferencias.
Se integra en CI/CD. Al ejecutar pruebas visuales en cada pull request, detectas las regresiones de accesibilidad antes de que lleguen a producción. Es prevención, no corrección.
No requiere experiencia en accesibilidad para configurarse. Cualquier miembro del equipo puede configurar una prueba visual que capture las páginas a diferentes niveles de zoom o con estilos de foco forzados. La comparación es automática.
¿Tu cumplimiento WCAG se queda en una puntuación automática? Inspecciona visualmente la conformidad región por región con Delta-QA, gratis en escritorio y sin enviar tus capturas a ninguna nube. Probar Delta-QA gratis →
Los criterios WCAG que las pruebas visuales detectan de forma nativa
Veamos criterio por criterio los aspectos WCAG que las pruebas visuales cubren eficazmente.
Criterios 1.4.3 y 1.4.6 — Contraste. Al combinar las pruebas visuales con filtros de simulación de daltonismo o extrayendo los colores de las capturas de pantalla, puedes verificar que el contraste se mantiene conforme después de cada modificación. Un cambio de paleta que degrade el contraste será inmediatamente visible en la comparación de capturas.
Criterio 1.4.4 — Redimensionamiento del texto. Captura tus páginas a un zoom del 200%. Cualquier regresión (texto truncado, elementos que se superponen, contenedores que desbordan) será detectada por la comparación visual.
Criterio 1.4.10 — Reflow. Captura tus páginas a una anchura de 320 píxeles CSS. Las pruebas visuales responsive verifican que el contenido se adapta correctamente sin desplazamiento horizontal.
Criterio 1.4.12 — Espaciado del texto. Inyecta los estilos de espaciado requeridos por el criterio (altura de línea 1.5, espaciado de párrafo 2x, letras 0.12em, palabras 0.16em) y captura el resultado. Compara con la baseline para detectar los elementos que se rompen bajo estas restricciones.
Criterios 2.4.7, 2.4.11, 2.4.12 — Foco visible. Fuerza el foco del teclado en cada elemento interactivo y captura el resultado. Las pruebas visuales detectan la desaparición o la degradación del indicador de foco.
Criterio 1.4.11 — Contraste de elementos no textuales. Los iconos, los bordes de campos de formulario, los indicadores de estado: todos estos elementos deben tener una relación de contraste de al menos 3:1. Las pruebas visuales los supervisan de forma natural.
Cómo implementar una vigilancia visual de la accesibilidad
La implementación práctica se basa en unos pocos principios simples.
Crea baselines en condiciones de accesibilidad. No te limites a capturar tus páginas en su estado predeterminado. Crea baselines adicionales: a un zoom del 200%, a una anchura de 320 píxeles, con los estilos de espaciado WCAG inyectados y con el foco forzado en los elementos interactivos.
Integra estas pruebas en tu pipeline CI/CD. Cada pull request debería activar una comparación visual en todas estas condiciones. Si un cambio de CSS degrada la accesibilidad visual, la prueba bloquea el merge.
Utiliza umbrales de tolerancia adaptados. Para las pruebas de accesibilidad, reduce el umbral de diferencia aceptable. Un cambio de 2 píxeles en un indicador de foco puede hacerlo no conforme. La tolerancia debe ser más estricta que para una prueba visual generalista.
Documenta tus baselines de accesibilidad. Cada baseline debe estar asociada al criterio WCAG que verifica. Esto facilita la auditoría y la trazabilidad en caso de inspección.
Combina con herramientas de análisis estático. Las pruebas visuales no reemplazan a axe-core o Lighthouse. Las complementan. Utiliza las herramientas de análisis para los criterios estructurales (alternativas textuales, estructura de encabezados, ARIA), y las pruebas visuales para los criterios de renderizado. Juntos, cubren prácticamente la totalidad de las WCAG.
Una herramienta como Delta-QA, que permite configurar pruebas visuales sin escribir código, hace que este enfoque sea accesible para todo el equipo, incluidos los responsables de accesibilidad que no son desarrolladores.
La accesibilidad visual no es un lujo, es una obligación
Desde junio de 2025, el European Accessibility Act (EAA) obliga a las empresas de la Unión Europea a hacer accesibles sus productos y servicios digitales. En los Estados Unidos, el ADA y la Section 508 imponen requisitos similares. En Canadá, la Ley Canadiense sobre la Accesibilidad entra en aplicación progresiva. En el Reino Unido, las Public Sector Bodies Accessibility Regulations 2018 están en vigor desde 2020.
Las sanciones económicas existen y aumentan. Pero más allá del riesgo jurídico, la accesibilidad es una ventaja competitiva. Según la Organización Mundial de la Salud, más de mil millones de personas en el mundo viven con alguna forma de discapacidad. Ignorar la accesibilidad es ignorar un mercado considerable.
La accesibilidad visual es la parte más fácilmente automatizable de esta obligación. No necesitas un experto WCAG para capturar capturas de pantalla en diferentes condiciones y comparar los resultados. Necesitas una herramienta de pruebas visuales bien configurada.
¿Listo para convertir tu conformidad WCAG en una vigilancia continua? Captura una primera baseline accesible y deja que Delta-QA bloquee cada regresión visual antes de producción, gratis y sin registro. Probar Delta-QA gratis →
FAQ
¿Cómo probar la conformidad WCAG por región?
Comience por identificar la o las jurisdicciones aplicables a su producto (UE, US, Canadá, UK u otra). Refiérase al cuadro comparativo anterior para conocer la norma y el nivel requerido. Ejecute un test automatizado con axe-core para las violaciones estructurales, compleméntelo con un test visual automatizado (capturas a 200 % de zoom, 320 px de anchura, foco forzado) para los criterios de renderizado, y termine con una auditoría manual con teclado y lector de pantalla. Documente cada resultado con la referencia jurisdiccional.
¿Es obligatorio el test WCAG en la UE?
Sí. El European Accessibility Act (Directiva 2019/882), en vigor desde junio de 2025, impone la conformidad con la norma EN 301 549, alineada con WCAG 2.1 nivel AA. El incumplimiento expone a sanciones nacionales variables según el Estado miembro. El perímetro cubre los productos y servicios digitales destinados a los consumidores: e-commerce, servicios bancarios, transportes, telecomunicaciones, medios.
¿Qué nivel WCAG se requiere para la conformidad legal?
Las cuatro jurisdicciones principales (UE, US, Canadá, UK) exigen el nivel AA. Ninguna impone legalmente el nivel AAA, aunque ciertos criterios AAA (en particular el contraste reforzado a 7:1) son recomendados para reducir el riesgo de litigio. En la práctica, apuntar a WCAG 2.1 AA cubre las obligaciones de todas las regiones mencionadas en esta guía.
¿Cuál es la fecha límite del European Accessibility Act?
El EAA fue adoptado en 2019 (Directiva 2019/882) y entró en vigor el 28 de junio de 2025. Las empresas debían estar conformes en esa fecha. Los Estados miembros debían transponer la directiva al derecho nacional — algunos se han retrasado, pero la obligación se aplica independientemente de la transposición local. Las microempresas (menos de 10 empleados y menos de 2 millones de euros de facturación) se benefician de exenciones.
¿Qué precisión tienen las herramientas automatizadas de test WCAG?
Las herramientas automatizadas como axe-core detectan entre el 30 y el 50 % de las violaciones WCAG, según los estudios realizados por Deque Systems y el W3C WAI. Cubren eficazmente los criterios estructurales (alternativas textuales, roles ARIA, estructura de encabezados) pero dejan un punto ciego sobre los criterios de renderizado visual y la experiencia de usuario real. Por eso un test completo combina automatización, test visual y auditoría manual.
¿Las pruebas visuales sustituyen una auditoría completa de accesibilidad WCAG?
No. Las pruebas visuales cubren los criterios visuales de las WCAG (contraste, foco, espaciado, zoom, reflow), pero no los criterios estructurales como las alternativas textuales, la navegación por teclado o los roles ARIA. Complementan una auditoría, no la sustituyen. Aproximadamente entre el 30 y el 40% de los criterios WCAG 2.2 tienen un componente visual directo.
¿Qué niveles de conformidad WCAG ayudan a verificar las pruebas visuales?
Las pruebas visuales son pertinentes para los tres niveles: A, AA y AAA. El nivel AA, que es el más comúnmente exigido por las regulaciones, contiene varios criterios visuales importantes (contraste 1.4.3, foco visible 2.4.7, reflow 1.4.10, espaciado 1.4.12). El nivel AAA refuerza los requisitos de contraste (1.4.6 con una relación de 7:1) y añade criterios adicionales, todos verificables visualmente.
¿Cómo probar la accesibilidad visual sin competencia técnica?
Con una herramienta no-code como Delta-QA, configuras las páginas a probar, defines las condiciones (tamaño de pantalla, zoom, navegador), y la herramienta captura y compara automáticamente las capturas de pantalla. No se necesita ninguna línea de código. La interfaz te muestra las diferencias visuales y tú decides si son aceptables o no.
¿Con qué frecuencia hay que verificar la accesibilidad visual?
Con cada modificación del código front-end. La integración en CI/CD es el mejor enfoque: cada pull request activa automáticamente las pruebas. Si no puedes automatizar a este nivel, una prueba semanal es un mínimo aceptable para detectar regresiones antes de que se acumulen.
¿Las pruebas visuales detectan problemas de accesibilidad en móvil?
Sí, siempre que configures pruebas en las resoluciones móviles habituales (360px, 375px, 414px de ancho). Las pruebas visuales responsive capturan el renderizado real en cada resolución y detectan problemas de reflow, texto truncado, elementos demasiado pequeños para activar con el tacto y contrastes degradados por el renderizado móvil.
¿El European Accessibility Act afecta a mi empresa?
Si vende productos o servicios digitales a consumidores en la Unión Europea, sí. El EAA se aplica desde junio de 2025 a los sitios de comercio electrónico, servicios bancarios, medios de comunicación, transporte y telecomunicaciones, entre otros. Las microempresas con menos de 10 empleados y menos de 2 millones de euros de facturación se benefician de exenciones, pero las demás deben cumplir.
- El test visual para Product Managers: guía completa
- Test visual y design systems: componentes y páginas
Conclusión
Un wcag test region eficaz exige conocer las obligaciones legales de cada jurisdicción, combinar el análisis automatizado y el test visual, e integrar estas verificaciones en el ciclo de desarrollo. Las cuatro regiones principales (UE, US, Canadá, UK) convergen hacia WCAG AA, pero los referentes, fechas límite y perímetros difieren. El test visual automatizado cubre el punto ciego de las herramientas de análisis estático verificando el renderizado real — lo que el usuario ve, no lo que el código declara.
En lugar de tratar la accesibilidad como una auditoría puntual que se realiza una vez al año, integra las pruebas visuales en tu pipeline para convertirla en una vigilancia continua. Es más eficaz, más fiable e infinitamente menos costoso que la corrección tardía.