Cómo comprobar la accesibilidad de una web: guía práctica paso a paso

La forma más rápida de comprobar la accesibilidad de una web es combinar un escaneo automático con unas pocas pruebas manuales bien elegidas. Un checker puede detectar en segundos muchos errores técnicos, pero ninguna herramienta automática puede demostrar por sí sola que una página cumple completamente WCAG o que una empresa cumple todas sus obligaciones legales.

La diferencia es importante. Si buscas «test de accesibilidad web», probablemente no necesitas empezar leyendo las WCAG de principio a fin. Lo primero que necesitas es saber qué problemas tiene tu propia web, cuáles puede detectar una máquina y cuáles necesitan una persona.

Esta guía te propone un método práctico: primero escanear; después, revisar teclado, foco, zoom, imágenes, formularios, estructura y recorridos críticos. Al terminar no tendrás una «nota mágica», pero sí una fotografía mucho más útil de la accesibilidad real del sitio y una lista razonable de prioridades.

Respuesta rápida: cómo comprobar la accesibilidad de una web

• Haz un escaneo automático para localizar errores detectables por software.
• Navega solo con teclado y comprueba que puedes alcanzar y utilizar todas las funciones.
• Revisa el foco visible y que el orden de navegación tenga sentido.
• Amplía la página y verifica que el contenido sigue siendo legible y utilizable.
• Comprueba imágenes, encabezados y formularios en su contexto.
• Prueba los procesos importantes completos: registro, compra, contacto, reserva o autenticación.
• No interpretes un 100/100 como una certificación WCAG: hay criterios que requieren evaluación humana.

Empieza por tu propia web Introduce una URL y obtén un primer análisis automático de accesibilidad, rendimiento y sostenibilidad. Es la manera más rápida de pasar de «creo que mi web está bien» a problemas concretos que puedes revisar.

• Accesibilidad: chequeos automáticos relacionados con WCAG 2.2.
• Rendimiento: carga y peso de la página.
• Impacto: estimación de carbono y uso de agua.
• Fricción: gratis, sin registro y con resultado en unos segundos.

Sprout Scan realiza comprobaciones automáticas. No constituye por sí sola una certificación WCAG, una auditoría manual completa ni una conclusión jurídica sobre cumplimiento.

Índice

1. Qué significa realmente comprobar accesibilidad
2. Test automático frente a revisión manual
3. Método práctico paso a paso
4. Comprobar navegación con teclado
5. Revisar el foco visible
6. Comprobar zoom y reflow
7. Revisar imágenes y textos alternativos
8. Revisar títulos, encabezados y estructura
9. Comprobar formularios y errores
10. Revisar contraste y uso del color
11. Comprobar multimedia
12. Cuándo probar con lector de pantalla
13. Probar recorridos críticos
14. Cómo interpretar una puntuación
15. Cómo priorizar los errores
16. Por qué hay que volver a comprobar
17. Preguntas frecuentes

Qué significa realmente comprobar la accesibilidad de una web

Comprobar la accesibilidad de una web significa evaluar si personas con distintas capacidades pueden percibir el contenido, navegar, entender la interfaz y completar las tareas que ofrece el sitio.

No es lo mismo que comprobar si el HTML es válido, si Lighthouse muestra una puntuación alta o si existe texto alternativo en todas las imágenes. Esas comprobaciones pueden formar parte del trabajo, pero la accesibilidad real depende de cómo se comporta la página como conjunto.

Por ejemplo, una tienda online puede tener:

• todas las imágenes con atributo alt;
• un contraste correcto en la mayor parte del sitio;
• formularios técnicamente etiquetados;
• una puntuación automática muy alta;

y aun así impedir que una persona complete la compra porque un modal atrapa el foco, un selector solo funciona con ratón o los mensajes de error no se anuncian correctamente.

Por eso W3C distingue entre las herramientas que ayudan a encontrar barreras y la evaluación necesaria para determinar la accesibilidad de un sitio. La conclusión práctica es sencilla: automatizar es imprescindible para ganar escala, pero no sustituye el juicio humano.

Test automático de accesibilidad vs. revisión manual: qué detecta cada uno

Los dos enfoques no compiten. Se complementan.

Comprobación	Automatizable	Necesita revisión humana	Por qué
Ausencia de atributo alt	Sí	A veces	La máquina detecta que falta; una persona decide si el texto existente es adecuado al contexto.
Contraste de colores	En muchos casos	A veces	Puede medirse matemáticamente, pero hay estados, fondos, imágenes y componentes que requieren contexto.
Labels de formularios	Parcialmente	Sí	Puede existir una asociación técnica y seguir siendo confusa para el usuario.
Jerarquía de encabezados	Parcialmente	Sí	El código se puede inspeccionar; el sentido de la estructura depende del contenido.
Uso completo con teclado	Parcialmente	Sí	Hay que recorrer la interfaz y comprobar orden, foco, bloqueos y funcionamiento real.
Calidad del texto alternativo	No de forma fiable	Sí	La utilidad depende de la función y el contexto de la imagen.
Comprensión de mensajes de error	Parcialmente	Sí	No basta con que exista un mensaje: debe ayudar a entender y corregir el problema.
Recorrido completo de compra o registro	Parcialmente	Sí	La accesibilidad se juega en la secuencia completa, no solo en elementos aislados.
Experiencia con lector de pantalla	No de forma completa	Sí	Requiere comprobar el orden, los nombres accesibles, estados y feedback tal como los recibe la persona.

Esta es una de las razones por las que una herramienta seria debe explicar sus límites. Si un checker afirma que una web es «100% accesible» solo porque ha pasado un conjunto de reglas automáticas, está simplificando en exceso lo que significa conformidad WCAG.

Cómo comprobar la accesibilidad de una web paso a paso

Para una primera evaluación no necesitas convertirte en especialista WCAG antes de abrir el navegador. Necesitas un proceso ordenado.

1. Escanea una página representativa. Empieza por la home o por la página que concentra más negocio. Utiliza un checker para localizar incidencias técnicas rápidamente.
2. Repite el análisis en diferentes tipos de página. Una home no representa un ecommerce entero. Comprueba también una ficha de producto, un formulario, una página de contenido y cualquier área privada o proceso crítico.
3. Navega solo con teclado. Guarda el ratón. Recorre menús, enlaces, botones, formularios, modales y controles con Tab, Shift+Tab, Enter, Espacio y las teclas necesarias.
4. Comprueba el foco. Debes saber en todo momento dónde estás. El foco debe ser visible, seguir un orden comprensible y no quedar oculto bajo banners o modales.
5. Amplía el contenido. Haz zoom y revisa que textos, botones, menús y formularios sigan siendo legibles y utilizables sin perder información.
6. Revisa estructura, imágenes y formularios. Comprueba títulos, encabezados, texto alternativo, labels, instrucciones y mensajes de error.
7. Prueba el proceso real. No audites solo componentes. Intenta comprar, registrarte, reservar, buscar, iniciar sesión o contactar exactamente como lo haría un usuario.
8. Completa la evaluación con pruebas humanas especializadas cuando el riesgo lo requiera. Si necesitas evaluar conformidad, cumplir una obligación normativa o publicar una declaración formal, una revisión preliminar no es suficiente.

Regla práctica: si el sitio tiene muchas páginas, no empieces intentando revisar cada URL manualmente. Busca primero plantillas, componentes y recorridos representativos. Un error en el componente correcto puede estar repetido en cientos de páginas.

1. Cómo comprobar si una web funciona solo con teclado

Esta es una de las pruebas manuales con mejor relación entre tiempo y valor.

Cierra o aparta el ratón y recorre la página con Tab. Utiliza Shift+Tab para volver atrás. Activa enlaces y botones con las teclas habituales del navegador y comprueba que puedes realizar las mismas tareas esenciales que con un ratón.

Qué deberías observar:

• todos los elementos interactivos importantes reciben foco;
• el orden del foco resulta lógico;
• los menús pueden abrirse y cerrarse;
• los desplegables pueden utilizarse;
• los modales no te dejan atrapado;
• puedes cerrar un modal sin utilizar el ratón;
• ninguna función depende exclusivamente de pasar el cursor por encima;
• puedes completar formularios y activar sus botones.

Una trampa de teclado es especialmente grave: el usuario entra en un componente pero no puede salir utilizando el teclado. Si ocurre, la página puede dejar de ser utilizable para esa persona.

2. Cómo revisar el foco visible

Mientras navegas con Tab deberías poder responder siempre a una pregunta: «¿dónde estoy ahora?»

El elemento con foco necesita un indicador perceptible. Puede ser un borde, un cambio de fondo u otra señal visual suficientemente clara. Quitar el outline por motivos estéticos sin proporcionar una alternativa es un error clásico.

También debes comprobar que el elemento enfocado no queda tapado por:

• banners de cookies;
• cabeceras fijas;
• chats flotantes;
• popups;
• otros componentes superpuestos.

WCAG 2.2 incorporó nuevos criterios relacionados precisamente con la visibilidad del foco. Por eso, una página evaluada hace años puede necesitar una nueva revisión si el objetivo técnico actual es WCAG 2.2.

3. Cómo comprobar zoom, ampliación y reflow

Una persona con baja visión puede necesitar ampliar significativamente el contenido. La prueba sencilla consiste en aumentar el zoom del navegador y comprobar que el sitio sigue siendo utilizable.

No te limites a preguntar si «se ve más grande». Comprueba:

• si desaparece contenido;
• si los textos quedan cortados;
• si botones y campos se solapan;
• si aparecen bloques imposibles de leer;
• si es necesario desplazarse en dos dimensiones para tareas que no deberían requerirlo;
• si menús y componentes mantienen su funcionalidad.

La accesibilidad responsive no consiste solo en que la web «quepa» en móvil. También debe soportar que una persona modifique la escala y el tamaño del contenido.

4. Cómo comprobar imágenes y texto alternativo

Una herramienta automática puede detectar con bastante facilidad una imagen sin atributo alt. La parte difícil es decidir qué debería decir ese texto alternativo.

La pregunta no es «¿cómo describo esta imagen?». La pregunta es: ¿qué información o función perdería una persona si no pudiera verla?

Una imagen decorativa puede necesitar un alt="" vacío para que un lector de pantalla la ignore. Una gráfica que contiene información necesita una alternativa que comunique el dato relevante. Un icono utilizado como botón necesita un nombre que explique su función, no su apariencia.

Caso	Enfoque pobre	Enfoque más útil
Botón con lupa	”Lupa"	"Buscar”
Foto puramente decorativa	Descripción larga sin valor	alt="" si realmente es decorativa
Gráfica de ventas	”Gráfica”	Comunicar el dato o tendencia que la gráfica aporta
Logo enlazado a inicio	”Imagen logo”	Nombre de la organización, según el contexto del enlace

Este es un buen ejemplo de por qué «tener alt» y «ser accesible» no son equivalentes.

5. Cómo revisar títulos, encabezados y estructura de la página

Los encabezados no son simplemente texto grande. Comunican la estructura del contenido y permiten que algunas personas naveguen rápidamente entre secciones.

Comprueba que:

• la página tiene un título <title> descriptivo y diferente al de otras páginas;
• el contenido utiliza encabezados reales h1, h2, h3, etc.;
• los encabezados describen realmente las secciones;
• la jerarquía tiene sentido;
• no se utiliza un encabezado solo para conseguir un tamaño de fuente;
• la página identifica correctamente su idioma principal.

Una estructura semántica clara ayuda a tecnologías de asistencia y, además, hace que el contenido sea más fácil de interpretar por navegadores, buscadores y otros sistemas que procesan el documento. No convierte la accesibilidad en «un truco SEO»; simplemente demuestra que una buena arquitectura HTML sirve a más de un objetivo.

6. Cómo comprobar la accesibilidad de formularios

Los formularios concentran algunos de los problemas más costosos porque suelen estar vinculados a conversión: contacto, alta, checkout, presupuesto, login o recuperación de contraseña.

Comprueba al menos estos puntos:

• cada campo tiene una etiqueta comprensible y correctamente asociada;
• el placeholder no sustituye a una label necesaria;
• los campos obligatorios se identifican de una forma que no depende solo del color;
• las instrucciones aparecen antes de que el usuario las necesite;
• los errores indican qué ha ocurrido y cómo corregirlo;
• el foco se gestiona de forma comprensible después de un error;
• los mensajes importantes pueden ser percibidos por tecnologías de asistencia;
• el formulario completo se puede operar con teclado.

Hay un test muy humano y bastante revelador: rellena mal el formulario a propósito. Deja campos vacíos, introduce un email incorrecto o provoca el error más común. Muchas webs parecen accesibles hasta que algo sale mal.

7. Cómo comprobar contraste y uso del color

El contraste puede medirse con herramientas, pero conviene revisar más que el cuerpo de texto.

Incluye:

• texto normal y texto pequeño;
• enlaces;
• labels y placeholders;
• botones en todos sus estados;
• indicadores de foco;
• iconos e información gráfica relevante;
• mensajes de error y éxito;
• contenido sobre imágenes o gradientes.

Y recuerda otra regla importante: el color no debería ser el único canal para transmitir información. Un campo con error no debería distinguirse únicamente porque el borde pasa de gris a rojo. Debe existir otra señal que permita entender qué ha ocurrido.

8. Cómo comprobar vídeo, audio y contenido multimedia

Si el sitio utiliza vídeo o audio, la evaluación debe considerar que parte de la información puede no estar disponible para una persona que no puede oírla o verla.

Según el tipo de contenido y los requisitos aplicables, puede ser necesario revisar elementos como:

• subtítulos;
• transcripciones;
• audiodescripción;
• controles accesibles;
• reproducción automática;
• contenido que parpadea o se mueve;
• alternativas a información exclusivamente visual o sonora.

No todo vídeo requiere exactamente la misma solución. El contenido, la información que transmite y el contexto importan.

9. Cuándo necesitas probar una web con lector de pantalla

Un lector de pantalla permite escuchar y navegar la información expuesta por la interfaz. Probar con uno puede descubrir problemas que son casi invisibles en una revisión visual.

Por ejemplo:

• botones que se anuncian como “button” sin un nombre útil;
• cambios de estado que visualmente aparecen pero no se comunican;
• orden de lectura diferente al orden visual;
• modales que se abren sin trasladar correctamente el contexto;
• campos de formulario ambiguos;
• componentes personalizados con semántica incorrecta.

Ahora bien, abrir un lector de pantalla durante cinco minutos no convierte automáticamente una evaluación en una auditoría experta. Estas herramientas tienen modelos de interacción propios y conviene conocerlos para interpretar lo que está ocurriendo.

Para una primera revisión interna puede aportar información. Para una evaluación de conformidad o un proceso de alto riesgo, necesitas una metodología y personas que sepan utilizar tecnologías de asistencia correctamente.

10. La prueba que muchas auditorías rápidas olvidan: completar el recorrido real

Las personas no utilizan «criterios WCAG». Utilizan webs para conseguir algo.

Por eso, después de comprobar elementos individuales, escoge las tareas que sostienen el negocio:

• comprar un producto;
• reservar una cita;
• solicitar información;
• registrarse;
• iniciar sesión;
• recuperar una contraseña;
• buscar contenido;
• descargar un documento;
• cancelar o modificar un servicio.

Completa el recorrido con teclado y, cuando proceda, con tecnologías de asistencia. Comprueba no solo si «se puede», sino si la secuencia es comprensible.

Para ecommerce: ficha de producto, variantes, carrito, identificación, dirección, validación de errores y pago forman parte de una misma experiencia. Auditar la home y declarar que «la web pasa» no dice gran cosa sobre el proceso que genera ingresos.

Haz primero lo que una máquina puede hacer por ti No tiene sentido revisar a mano errores que pueden localizarse automáticamente en segundos. Utiliza Sprout Scan para obtener una primera fotografía y dedica la revisión humana a lo que realmente necesita contexto.

Un buen escaneo reduce trabajo manual; no elimina la necesidad de evaluación humana cuando se quiere determinar conformidad completa.

Qué significa una puntuación de accesibilidad y por qué un 100 no equivale a cumplir WCAG

Los scores son útiles porque convierten una gran cantidad de datos en una señal rápida. También son peligrosos si se interpretan como una certificación.

Una puntuación responde a la metodología de la herramienta que la calcula. WCAG, en cambio, define criterios de conformidad. Son dos cosas diferentes.

W3C explica que la evaluación de los criterios de éxito combina pruebas automáticas y evaluación humana. Además, la conformidad de nivel AA exige satisfacer los criterios A y AA aplicables a la página completa; no se expresa como «hemos obtenido 92 puntos».

Por tanto:

• un score bajo es una señal clara de que hay trabajo pendiente;
• un score alto significa que la herramienta ha encontrado pocos problemas dentro de lo que sabe comprobar;
• un 100 automático no demuestra que todas las interacciones sean accesibles;
• dos herramientas pueden asignar puntuaciones distintas porque utilizan reglas y ponderaciones diferentes.

La mejor forma de utilizar un score es como instrumento de priorización y seguimiento, no como sustituto de una evaluación de conformidad.

Cómo priorizar los errores de accesibilidad después del test

Un informe con 147 incidencias puede paralizar a un equipo. No todas tienen el mismo impacto ni el mismo coste de corrección.

Prioriza utilizando cuatro preguntas:

1. ¿Bloquea una tarea? Un error que impide comprar, iniciar sesión o enviar un formulario va primero.
2. ¿Cuántas páginas afecta? Un componente defectuoso repetido en 500 páginas tiene más alcance que una incidencia aislada.
3. ¿A cuántas personas puede afectar? Prioriza barreras graves y frecuentes antes que detalles cosméticos.
4. ¿Puede corregirse en el sistema? Arreglar una plantilla, un componente o el CMS evita solucionar el mismo problema una y otra vez.

Prioridad	Ejemplo	Acción
Crítica	No se puede completar el checkout con teclado	Corregir antes de cualquier mejora menor
Alta	Componente de formulario sin labels correctas en todo el sitio	Corregir el componente base
Media	Jerarquía de encabezados confusa en una plantilla secundaria	Planificar dentro del siguiente ciclo
Baja	Incidencia aislada con impacto reducido y alternativa funcional	Registrar y corregir sin desplazar bloqueos reales

La accesibilidad madura no consiste en perseguir una cifra perfecta. Consiste en reducir barreras reales de forma sistemática.

Por qué una web accesible hoy puede dejar de serlo mañana

Una de las trampas más comunes es tratar la accesibilidad como un proyecto cerrado: auditoría → corrección → informe → fin.

Pero una web viva cambia. Marketing publica una landing. Producto modifica el menú. Un proveedor añade un widget. Se cambia el checkout. Un nuevo editor sube imágenes. Aparece un banner. Se instala un chat.

Cada cambio puede introducir una barrera nueva.

Por eso W3C recomienda evaluar la accesibilidad desde etapas tempranas y durante todo el proceso de desarrollo. En empresas con varias webs, equipos o agencias, esto deja de ser solamente testing y se convierte en una cuestión de proceso y gobernanza.

Si tu empresa está además dentro del ámbito de la Ley 11/2023 y los requisitos de accesibilidad aplicables a determinados servicios, la necesidad de mantener la conformidad a lo largo del tiempo cobra todavía más importancia.

El siguiente nivel, por tanto, no es «hacer más auditorías». Es conseguir que la accesibilidad forme parte de:

• los componentes de diseño;
• el desarrollo;
• el CMS;
• la revisión editorial;
• los despliegues;
• la monitorización;
• la relación con agencias y proveedores.

Cuando esto ocurre, el equipo deja de corregir siempre los mismos errores después de publicar.

Qué papel tiene WCAG 2.2 cuando compruebas accesibilidad

WCAG 2.2 es el estándar técnico internacional del W3C para hacer el contenido web más accesible. Organiza sus criterios alrededor de cuatro principios: perceptible, operable, comprensible y robusto.

Los criterios se distribuyen en niveles A, AA y AAA. Para declarar conformidad AA, una página debe satisfacer los criterios A y AA aplicables y cumplir los demás requisitos de conformidad definidos por WCAG.

No necesitas memorizar todos los criterios para hacer una primera revisión. Pero si vas a evaluar formalmente un sitio, necesitas trabajar criterio por criterio y entender también los requisitos de conformidad.

Cuándo basta un checker y cuándo necesitas una auditoría de accesibilidad

Depende de la decisión que quieras tomar.

Necesidad	Checker automático	Revisión manual	Auditoría formal
Quiero una primera fotografía	Sí	Recomendable	No necesariamente
Quiero encontrar errores repetidos a escala	Sí	Para validar patrones	Depende del objetivo
Voy a rediseñar la web	Sí	Sí	Según riesgo y obligaciones
Necesito afirmar conformidad WCAG	Insuficiente por sí solo	Sí	Recomendable
Necesito una conclusión jurídica	No	No por sí sola	Evaluación técnica más análisis jurídico cuando proceda
Quiero monitorizar cambios frecuentes	Sí	Muestreo periódico	En hitos definidos

La herramienta adecuada depende de la pregunta. El error es utilizar un checker para responder una pregunta que exige una auditoría, o pagar una auditoría completa cada vez que una comprobación automática podría avisarte antes.

Preguntas frecuentes sobre cómo comprobar la accesibilidad web

¿Cómo puedo comprobar gratis la accesibilidad de mi web? Puedes empezar con un checker automático como Sprout Scan para detectar incidencias técnicas y después completar el análisis con pruebas manuales de teclado, foco, zoom, formularios, estructura y recorridos importantes.

¿Un test automático puede saber si mi web cumple WCAG? No por sí solo. W3C indica que hay aspectos que no pueden comprobarse automáticamente y requieren evaluación humana. Un test ayuda a detectar barreras y priorizar, pero no demuestra por sí mismo conformidad completa.

¿Qué es lo primero que debería probar manualmente? La navegación con teclado es una de las pruebas más rentables. Recorre toda la página con Tab y Shift+Tab, comprueba el foco visible y verifica que menús, botones, modales y formularios pueden utilizarse sin ratón.

¿Una puntuación de 100 significa que mi web es accesible? No necesariamente. Una puntuación resume las reglas que una herramienta ha podido evaluar. WCAG utiliza criterios y requisitos de conformidad, no una puntuación universal sobre 100.

¿Qué diferencia hay entre test de accesibilidad y auditoría? Un test suele referirse a comprobaciones automáticas o preliminares. Una auditoría completa combina metodología, revisión de criterios, pruebas manuales y, cuando procede, tecnologías de asistencia y muestras representativas del sitio.

¿Hay que comprobar todas las páginas de una web? No siempre manualmente una por una. En sitios grandes conviene seleccionar tipos de página, plantillas, componentes y recorridos representativos, y utilizar automatización para ampliar la cobertura y localizar patrones repetidos.

¿Qué versión de WCAG debería utilizar? W3C recomienda utilizar WCAG 2.2 como objetivo técnico actualizado. Si la comprobación tiene una finalidad jurídica o contractual, también debes verificar qué versión, norma o estándar concreto resulta aplicable al caso.

¿Comprobar accesibilidad una vez es suficiente? No para una web que cambia. Nuevos contenidos, componentes y proveedores pueden introducir barreras. La accesibilidad debe incorporarse al desarrollo, publicación y mantenimiento, con comprobaciones continuas y revisiones manuales periódicas.

¿Sprout Scan certifica que una web cumple la ley? No. Sprout Scan ofrece un diagnóstico automático que ayuda a encontrar incidencias y entender el estado de la página. No sustituye una evaluación humana completa ni una conclusión jurídica sobre la normativa aplicable.

La mejor comprobación de accesibilidad no termina en un score

Un buen test te dice dónde mirar. Una buena evaluación te ayuda a entender qué barreras existen. Y una estrategia madura evita que esas barreras reaparezcan cada vez que cambia la web.

Por eso el orden importa: automatiza lo automatizable, revisa manualmente lo que necesita contexto y convierte los errores repetidos en mejoras del sistema.

La accesibilidad deja entonces de ser una lista interminable de incidencias y empieza a formar parte de la calidad con la que una organización construye y mantiene sus sitios.

No empieces por 86 criterios. Empieza por tu URL. Haz una primera comprobación con Sprout Scan, identifica qué puede corregirse automáticamente o a escala y reserva la revisión humana para los problemas que realmente necesitan contexto.

Fuentes y referencias

• W3C WAI — Evaluating Web Accessibility Overview.
• W3C WAI — Selecting Web Accessibility Evaluation Tools.
• W3C WAI — Easy Checks, A First Review of Web Accessibility.
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2.
• W3C WAI — Understanding Conformance.
• Sprout — Website Sustainability Checker / Sprout Scan.

Este contenido es informativo. La evaluación de conformidad WCAG y la aplicación de requisitos legales dependen del alcance, la metodología y el contexto concreto.