Cómo probar la accesibilidad de tu web, paso a paso

Los escáneres automáticos no bastan por sí solos: con este plan de pruebas en 7 pasos revisas tu web de forma sistemática, del teclado al lector de pantalla.

Por qué un plan de pruebas es mejor que una sola herramienta

Muchos responsables de webs lanzan un escaneo automático, ven unos cuantos mensajes de error y dan el tema por zanjado. Eso se queda corto: la accesibilidad solo se puede comprobar de forma automática en parte. Si una página se puede manejar de verdad con el teclado, si un lector de pantalla lee los contenidos con sentido o si los mensajes de error de los formularios se entienden, eso tienes que probarlo por ti mismo.

Por eso, el siguiente plan combina herramientas automáticas con comprobaciones manuales. No necesitas equipamiento especial: un navegador actual, un teclado y el lector de pantalla que ya viene instalado en tu sistema operativo bastan para empezar. Como referencia sirven las WCAG 2.2, el estándar internacional para contenidos web accesibles.

Paso 1: los escáneres automáticos como punto de partida

Las herramientas automáticas encuentran los errores técnicos típicos con rapidez y fiabilidad: atributos alt ausentes, contrastes insuficientes, campos de formulario sin etiqueta, atributos ARIA incorrectos. Tres herramientas gratuitas y contrastadas:

• Lighthouse: integrado en Chrome y Edge. Abre las herramientas de desarrollo (F12), ve a la pestaña «Lighthouse», selecciona la categoría «Accessibility» y genera el informe.
• axe DevTools: extensión de navegador de Deque. Tras la instalación encontrarás en las herramientas de desarrollo una pestaña propia que marca los hallazgos directamente en el código.
• WAVE: una herramienta de comprobación de la organización estadounidense WebAIM (sin relación con Wave Tools: la similitud del nombre es casualidad). Superpone símbolos directamente sobre tu página y hace los problemas muy visibles.

No compruebes solo la página de inicio, sino cada tipo de página: inicio, página de contenido, página con formulario, página de producto o de entrada, resultados de búsqueda.

Paso 2: la prueba de teclado

Aparta el ratón y maneja tu web solo con el teclado. Con la tecla Tab avanzas por todos los elementos interactivos, con Mayús+Tab retrocedes, y con Intro o la barra espaciadora los activas. Fíjate en tres cosas:

1. Orden: el foco debería moverse en un orden lógico, por regla general de arriba a la izquierda hacia abajo a la derecha, siguiendo la estructura visible. Si salta de un lado a otro sin sentido, algo falla en la estructura del documento.
2. Visibilidad: debes poder reconocer en todo momento qué elemento tiene el foco. Si falta el marco de foco (a menudo eliminado por CSS con outline), quienes navegan con teclado están perdidos.
3. Sin trampas: tienes que poder salir de cada elemento. Las trampas clásicas son los widgets incrustados, los avisos de cookies y los diálogos modales que no se pueden cerrar con Escape.

Prueba también los menús, los acordeones, los sliders y los selectores de fecha: justo ahí fracasan muchas webs.

Paso 3: prueba básica con lector de pantalla

Un lector de pantalla lee la página en voz alta tal como la perciben las personas ciegas o con baja visión grave. Para una prueba básica no necesitas comprar nada:

• Windows: NVDA es gratuito y está muy extendido. Tras iniciarlo lee automáticamente en voz alta; con la tecla H saltas de encabezado en encabezado, con Tab recorres los elementos interactivos.
• macOS e iOS: VoiceOver viene integrado. En el Mac lo inicias con Cmd+F5; en el iPhone, desde los ajustes de accesibilidad.

Mientras escuchas, hazte tres preguntas: ¿tiene sentido la página también sin pantalla? ¿Se anuncian las imágenes con textos alternativos útiles o solo con nombres de archivo? ¿Sabes en los botones y enlaces qué pasará al activarlos, o solo oyes «enlace» y «haz clic aquí»? Ya diez minutos con un lector de pantalla te enseñan más sobre tu web que cualquier informe.

Paso 4: zoom al 200 por ciento y reflow

Muchas personas con baja visión amplían los contenidos en el navegador. Las WCAG exigen que el texto siga siendo utilizable con un zoom del 200 por ciento, sin pérdida de contenido ni de funciones. Así lo pruebas:

1. Amplía la página con Ctrl y más (Mac: Cmd y más) de forma gradual hasta el 200 por ciento.
2. Comprueba si los textos quedan cortados, se superponen o si los controles se salen del área visible.
3. Reduce además la ventana del navegador a unos 320 píxeles de ancho o haz zoom al 400 por ciento: ahora el contenido debería reorganizarse en una sola columna (reflow), sin que tengas que hacer scroll horizontal.

Si tu web está construida de forma responsiva y limpia, suele superar esta prueba sin retoques; si no, verás de inmediato dónde falla.

Paso 5: comprobar los contrastes

Los contrastes demasiado débiles están entre las barreras más frecuentes de todas. Las WCAG exigen para el texto normal una relación de contraste de al menos 4,5:1 con el fondo, y para el texto grande (a partir de unos 24 píxeles, o 19 en negrita) al menos 3:1. Los controles y los símbolos gráficos también necesitan al menos 3:1.

Para medir sirven el Contrast Checker de WebAIM, el cuentagotas de las herramientas de desarrollo del navegador o programas de escritorio como el Colour Contrast Analyser. Revisa a propósito los candidatos críticos: texto gris claro sobre blanco, textos de marcador de posición en campos de formulario, texto sobre fotos y botones en los colores de la marca. No te fíes de tu impresión en tu propio monitor bien calibrado: mídelo.

Paso 6: formularios y mensajes de error

Los formularios son el lugar donde las barreras salen más caras: ahí se pierden pedidos y solicitudes. Rellena cada formulario importante una vez por completo, una vez con errores a propósito y una vez solo con el teclado. Fíjate en esto:

• Cada campo tiene una etiqueta visible y vinculada de forma programática: un texto de marcador de posición dentro del campo no sustituye a la etiqueta, porque desaparece al escribir.
• Los campos obligatorios están señalados como tales, y no solo mediante el color.
• Los mensajes de error aparecen en forma de texto junto al campo afectado y explican en concreto qué está mal y cómo corregirlo: «Entrada no válida» a secas no ayuda a nadie.
• Tras enviar con errores, lo ya introducido se conserva.
• Los límites de tiempo, por ejemplo en procesos de reserva, se pueden ampliar o desactivar.

Paso 7: revisar los contenidos: textos alternativos, encabezados, textos de enlace

Para terminar toca el plano editorial, que ninguna herramienta puede evaluar:

• Textos alternativos: ¿describe el texto alternativo lo que se ve en la imagen y qué función tiene? ¿Llevan las imágenes puramente decorativas un atributo alt vacío? Cómo se escriben buenos textos alternativos te lo enseña nuestro artículo Cómo escribir buenos textos alternativos.
• Jerarquía de encabezados: exactamente un H1 por página y, a continuación, una estructura sin saltos (H2 y, debajo, H3). Los encabezados son estructura, no un recurso de diseño: quien elige un H4 porque queda bonito de pequeño sabotea la navegación con lector de pantalla.
• Textos de enlace: cada enlace debería entenderse por sí solo. «Más información» y «aquí» no lo hacen; «Descargar la lista de precios en PDF», sí.

Priorizar, documentar y no aflojar

Tras los siete pasos tienes una lista de hallazgos. Ordénala por impacto: primero van los bloqueos que impiden el uso por completo (trampas de teclado, formularios sin etiquetar, navegación inutilizable), después los grandes obstáculos, como textos alternativos ausentes en páginas centrales y contrastes débiles, y al final los detalles de acabado.

Documenta cada hallazgo con la página, la descripción, el criterio WCAG afectado y la solución prevista. Esta documentación rinde por partida doble: es la base de trabajo para tu equipo y aporta los datos para tu declaración de accesibilidad, en la que de todos modos tienes que mencionar las limitaciones conocidas y las medidas previstas.