La accesibilidad de un sitio web se prueba en dos capas: un análisis automático que encuentra rápido los errores medibles y una revisión manual para todo lo que tiene que valorar una persona. Las herramientas automáticas como axe-core, Lighthouse y WAVE detectan etiquetas que faltan, enlaces vacíos y ARIA incorrecto. Ninguna herramienta ve si un texto alternativo es correcto, si tu checkout funciona solo con teclado o si un lector de pantalla lee tu formulario de forma lógica.
Este artículo forma parte de nuestra guía completa sobre accesibilidad web. Aquí tienes una visión honesta de lo que pueden y no pueden hacer las herramientas automáticas, una rutina de pruebas manuales paso a paso, el método de evaluación oficial del W3C y una recomendación sobre con qué frecuencia probar.
La norma frente a la que pruebas es WCAG, las Pautas de Accesibilidad para el Contenido Web del W3C. En Europa, el objetivo suele ser el nivel AA. Qué requisitos incluye exactamente lo explicamos en WCAG 2.2 explicado.
¿Qué pueden hacer las herramientas automáticas?
Las herramientas automáticas de accesibilidad comprueban reglas que se pueden deducir objetivamente del código, como si una imagen tiene un atributo alt o un campo de entrada tiene una etiqueta. Son rápidas, repetibles y adecuadas para ejecutarlas en cada versión. Hay tres herramientas que verás con más frecuencia.
axe-core es la biblioteca de pruebas de código abierto de Deque. Según el README en GitHub, axe-core tiene reglas para WCAG 2.0, 2.1 y 2.2 en los niveles A, AA y AAA, además de reglas de buenas prácticas. Deque aspira a cero falsos positivos: un error que axe-core notifica es, en principio, un error real. Los casos dudosos axe-core los marca como "incomplete", con la indicación de que hace falta una revisión manual.
Lighthouse viene integrado en Chrome DevTools. Según la documentación sobre el cálculo de la puntuación, la puntuación de accesibilidad es una media ponderada de auditorías automáticas, con pesos basados en la estimación de impacto de axe. Cada auditoría remite a una regla de axe-core. Lighthouse menciona aparte las comprobaciones manuales, pero estas no cuentan en la puntuación.
WAVE, de WebAIM, muestra errores y alertas como iconos sobre tu página. La extensión del navegador prueba la página tal como se muestra en tu navegador, es decir, también después de ejecutar JavaScript. La página de ayuda de WAVE lo dice claramente: WAVE no puede decirte si tu contenido es accesible; solo una persona puede determinarlo.
¿Cuántos problemas detecta una herramienta automática? Deque publicó en 2021 un estudio propio basado en más de 2.000 auditorías. Según Deque, las pruebas automáticas con axe cubrían de media el 57 por ciento del número de problemas encontrados. Dos salvedades: es un estudio del propio proveedor y cuenta los problemas por volumen, no por criterios de conformidad. Por eso los errores frecuentes pesan mucho. En tu sitio, el porcentaje puede ser mayor o menor.
¿Qué no pueden hacer las herramientas automáticas?
Las herramientas automáticas no pueden valorar si algo es comprensible, lógico o utilizable, y es justo ahí donde están muchas de las barreras más graves. Algunos ejemplos que ningún escáner detecta de forma fiable:
- La calidad del texto alternativo. Una herramienta ve que hay un texto alternativo, no si "IMG_4032.jpg" o "imagen" describe la foto.
- El manejo con teclado de componentes propios. Un menú desplegable que solo responde a un clic de ratón, o una ventana emergente en la que el foco queda atrapado, solo lo notas si lo pruebas tú.
- Un orden de foco y de lectura lógico. El código puede ser válido mientras el foco salta de la cabecera al pie de página.
- Mensajes de error útiles. Una herramienta no ve si "Entrada no válida" ayuda al visitante a resolver el problema.
- El comportamiento al hacer zoom y el reajuste del contenido. El texto que se solapa o los botones cortados al 400 por ciento de zoom solo los ves en la pantalla.
- Contenido que solo aparece con JavaScript, si la herramienta solo lee el HTML en bruto.
El contraste de color está a medio camino. axe-core tiene una regla de contraste, pero solo funciona en una página realmente renderizada. El texto sobre una imagen de fondo o un degradado suele dar un resultado "incomplete". Por eso, mide también el contraste manualmente con un medidor de contraste.
Automático o manual: por tipo de comprobación
Lo que puede determinar una herramienta automática varía mucho según el tipo de comprobación. Esta tabla ofrece una visión práctica de las comprobaciones más habituales.
| Comprobación | Criterio de WCAG | Automática | Requiere revisión manual |
|---|---|---|---|
| Atributo alt presente | 1.1.1 (A) | Sí | No |
| El texto alternativo es correcto en contenido | 1.1.1 (A) | No | Sí |
| El campo de formulario tiene etiqueta | 1.3.1, 4.1.2 (A) | Sí | Solo para la claridad |
| Idioma de la página (atributo lang) | 3.1.1 (A) | Sí | No |
| Roles y atributos ARIA válidos | 4.1.2 (A) | Sí | Sí, para el comportamiento |
| Contraste de color del texto | 1.4.3 (AA) | En parte, solo en un navegador | Sí, con imágenes y degradados |
| Manejo con teclado | 2.1.1 (A) | No | Sí |
| Foco visible | 2.4.7 (AA) | No | Sí |
| Orden del foco | 2.4.3 (A) | No | Sí |
| Zoom hasta el 200% y reajuste | 1.4.4, 1.4.10 (AA) | No | Sí |
| Mensajes de error y sugerencias | 3.3.1 (A), 3.3.3 (AA) | No | Sí |
| Subtítulos de vídeo | 1.2.2 (A) | Solo si hay una pista | Sí, para la calidad |
La conclusión de la tabla: las pruebas automáticas son un buen primer filtro, pero gran parte de los criterios exige criterio humano. Encontrarás un resumen de los errores que más vemos en ambas capas en errores de accesibilidad más comunes.
Una rutina de pruebas manuales paso a paso
Una prueba manual básica no requiere software especializado y encuentra justo los problemas que se les escapan a los escáneres. Haz estos pasos con cada tipo de página: inicio, categoría, producto, formulario y checkout.
- Aparta el ratón. Navega con Tab, Mayús+Tab, Intro, la barra espaciadora y las flechas. ¿Llegas a cada enlace, botón y campo? ¿El foco es siempre visible? ¿Puedes abrir y volver a cerrar menús, ventanas emergentes y el banner de cookies sin quedarte atascado?
- Comprueba el orden. ¿Sigue el foco el orden visual de lectura? ¿Empieza la página con un enlace para saltar al contenido principal?
- Haz zoom al 200 por ciento. Usa el zoom del navegador. Según WCAG 2.2 (criterio 1.4.4), el texto debe poder ampliarse hasta el 200 por ciento sin pérdida de contenido ni de funcionalidad.
- Prueba el reajuste al 400 por ciento. En una ventana de 1280 píxeles de ancho, haz zoom al 400 por ciento; eso equivale a 320 píxeles CSS. El criterio 1.4.10 exige que el contenido siga siendo legible sin desplazamiento horizontal, salvo contenidos como tablas o mapas.
- Mide el contraste. Usa un medidor de contraste o el selector de color de DevTools. El texto normal necesita al menos 4,5:1 y el texto grande 3:1 (criterio 1.4.3).
- Escucha con un lector de pantalla. Usa NVDA en Windows o VoiceOver en Mac o iPhone. Recorre los encabezados, abre un formulario y envíalo con un error. ¿Se leen las etiquetas, los campos obligatorios y los mensajes de error?
- Revisa los formularios por separado. ¿Tienen los campos etiquetas visibles, son correctos los valores de autocomplete y aparece un mensaje de error como texto junto al campo correcto? Más sobre esto en formularios y checkout accesibles.
- Anota lo que encuentres. Para cada problema, apunta la página, el criterio, los pasos para reproducirlo y la gravedad. Esa lista también te sirve para redactar una declaración de accesibilidad.
Como primera aproximación, también puedes seguir los Easy Checks del W3C. Ellos mismos advierten de que una página puede superar estas comprobaciones rápidas y aun así tener barreras importantes.
El método WCAG-EM del W3C
WCAG-EM es el método de evaluación del W3C para determinar en qué medida un sitio web o producto digital cumple WCAG. Según la página de resumen del W3C, WCAG-EM 2 se publicó el 23 de julio de 2026 como W3C Group Note. El método no añade requisitos nuevos a WCAG, sino que describe cómo plantear una evaluación. La versión 2 amplía el enfoque de los sitios web a las apps y otros productos digitales.
El método tiene cinco pasos:
- Define el alcance: qué entra en la evaluación, cuál es el objetivo y qué nivel (A, AA o AAA).
- Explora el producto: qué pantallas, funciones, tipos de contenido y tecnologías importantes hay.
- Elige una muestra representativa: una selección estructurada completada con páginas aleatorias, si no puedes probarlo todo.
- Evalúa la muestra: comprueba cada página frente a los criterios de conformidad y documenta cómo has probado.
- Informa de los hallazgos: reúne los resultados y formula tus conclusiones.
El W3C ofrece para ello una herramienta gratuita, WCAG-EM Report Tool. Para una tienda online, el paso 3 es el más importante: incluye en cualquier caso el proceso de compra completo, desde la página de producto hasta la confirmación.
Pruebas con personas con discapacidad
Las pruebas de usuario con personas con discapacidad detectan problemas de usabilidad que una evaluación de conformidad frente a WCAG no saca a la luz. En Involving Users in Evaluating Web Accessibility, el W3C da algunos consejos claros.
- Corrige primero los errores evidentes, para que los participantes no se atasquen en algo que podrías haber encontrado tú.
- Implica a los usuarios ya durante el desarrollo, no solo al final.
- No des por hecho que una persona habla por todas las que tienen la misma discapacidad.
- Combina siempre las pruebas de usuario con una evaluación frente a WCAG, porque las pruebas de usuario por sí solas no determinan si tu sitio cumple.
Para la tienda online de una pyme no hace falta un gran estudio. Tres o cuatro sesiones en las que alguien con lector de pantalla, con un programa de ampliación o solo con teclado compra un producto suelen dar ya puntos de mejora concretos.
¿Con qué frecuencia hay que probar?
La frecuencia depende de cuánto cambie tu sitio, pero un ciclo fijo en tres capas funciona para la mayoría de las empresas.
| Capa | Cuándo | Qué |
|---|---|---|
| Análisis automático | En cada versión o al menos una vez al mes | Todas las plantillas importantes |
| Prueba manual básica | Con plantillas o componentes nuevos o en un rediseño | La rutina descrita arriba |
| Evaluación completa | Una vez al año o con cambios importantes | WCAG-EM con muestra e informe |
Presta especial atención a los cambios que no pasan por tu equipo de desarrollo. Un nuevo widget de chat, otro banner de cookies o un paso de pago de un tercero pueden hacer de golpe que un sitio accesible lo sea menos.
Dónde encaja Flowproof en este proceso
Flowproof es la primera capa automática, no un sustituto de las pruebas manuales. El control de accesibilidad ejecuta axe-core sobre el HTML de tu página y lo evalúa frente a WCAG 2.0, 2.1 y 2.2 en los niveles A y AA. Para cada regla detectada ves el criterio de conformidad, el nivel y la gravedad.
Lo que el análisis no hace a propósito: medir automáticamente el contraste de color. Para eso hace falta una representación real en un navegador, así que Flowproof indica que el contraste debe revisarse manualmente. Si tu página solo genera el contenido con JavaScript, el análisis avisa de que solo se ha probado el HTML base. Además, Flowproof comprueba si tienes un enlace a una declaración de accesibilidad, si hay un enlace para saltar contenido y si se reproduce audio automáticamente. La puntuación de accesibilidad es independiente de la puntuación GEO.
Cómo comprobarlo en tu propio sitio
- Lanza un análisis automático en tu página de inicio, una página de categoría, una página de producto, tu formulario de contacto y cada paso del checkout.
- Corrige primero los errores más graves, como las etiquetas que faltan y los botones sin nombre.
- Haz la rutina manual de este artículo en las mismas páginas: teclado, zoom al 200 por ciento, reajuste al 400 por ciento, contraste y un lector de pantalla.
- Documenta tus hallazgos con página, criterio y gravedad, e incluye los problemas conocidos en tu declaración de accesibilidad.
- Planifica la siguiente ronda: automática en cada versión, manual con componentes nuevos y una evaluación completa según WCAG-EM una vez al año.
El control de accesibilidad de Flowproof está incluido en los planes de pago Pro y Business. Puedes empezar gratis y comparar los planes en la página de precios.