Cómo comprobar la accesibilidad web: herramientas gratis y pruebas

Es una historia que oímos a menudo. Alguien ejecuta Lighthouse, obtiene un 100 en verde en accesibilidad y pasa a otra cosa. Una semana después, un cliente escribe para decir que no ha podido pagar porque al formulario de la tarjeta no se llega con el teclado. Las dos cosas son ciertas. La comprobación automática salió bien y, aun así, la web le falló a una persona real.

Esta guía explica cómo hacer buenas pruebas con poco presupuesto: qué herramientas gratuitas usar, una rutina manual de 15 minutos, un primer contacto con un lector de pantalla y cuándo merece la pena pagar una auditoría.

¿Puede un verificador automático decirme si mi web es accesible?

No. Los verificadores automáticos encuentran algunos problemas rápido, pero muchas cuestiones de accesibilidad necesitan que las responda una persona. Cuando el Government Digital Service británico probó 10 herramientas en una página con 143 fallos conocidos, la mejor encontró el 41 %. El W3C lo dice sin rodeos: las herramientas de evaluación «no pueden determinar la accesibilidad, solo pueden ayudar a hacerlo».

La prueba del GDS (se abre en una pestaña nueva) es de febrero de 2017, y su 41 % (el de Asqatasun) incluía los avisos de la propia herramienta para hacer comprobaciones manuales. Las herramientas han mejorado desde entonces, pero la brecha tiene la misma causa. Un programa puede saber que una imagen no tiene texto alternativo. No puede saber que «vestido rojo» es una descripción equivocada para la foto de un traje azul, ni si el orden del foco tiene sentido.

Así que trate un verificador como un detector de humo, no como una inspección del edificio. Aun así, merece la pena pasarlo: el WebAIM Million 2026 (se abre en una pestaña nueva) encontró fallos detectables en el 95,9 % de las páginas de inicio del millón de webs principales, así que en la mayoría de las webs hay mejoras rápidas al alcance de la mano. Como dice la guía del W3C para elegir herramientas (se abre en una pestaña nueva), «hace falta el juicio humano».

¿Qué herramientas gratuitas de accesibilidad debería usar?

Use uno o dos verificadores automáticos, un verificador de contraste y un lector de pantalla. Cada herramienta aplica reglas distintas y presenta los resultados de otra manera, así que dos verificadores suelen detectar más que uno. Todas las herramientas de abajo tienen una versión gratuita. Revise las condiciones actuales de cada una antes de confiar en ella, porque los nombres, las funciones y los precios cambian.

¿Qué puedo comprobar manualmente en 15 minutos?

Bastante. Las Easy Checks del W3C (se abre en una pestaña nueva) («comprobaciones sencillas») cubren los títulos de página, el texto alternativo, los encabezados, el contraste, los enlaces para saltar contenido, el foco visible del teclado, el idioma de la página, el zoom, los subtítulos y las etiquetas de los formularios. Elija una página importante, como una ficha de producto o su formulario de reserva, y dedique a cada comprobación uno o dos minutos. Encontrará cosas que ningún verificador señala.

El W3C advierte de que estas comprobaciones «abarcan solo unos pocos problemas de accesibilidad», así que no son una evaluación completa. Aun así, es el mejor cuarto de hora que puede dedicar a su web:

1. Título de la página (1 minuto). ¿Dice la pestaña del navegador qué es la página, como «Reservar mesa | Cocina de Rosa», en lugar de «Inicio» en todas partes?
2. Imágenes (2 minutos). Muestre el texto alternativo con WAVE o una herramienta similar. ¿Es preciso? ¿Se saltan las imágenes decorativas?
3. Encabezados (2 minutos). Liste los encabezados y léalos por separado. ¿Funcionan como índice?
4. Contraste (2 minutos). Revise el cuerpo de texto, el texto gris pequeño, el texto de los botones y el texto sobre imágenes.
5. Teclado (4 minutos). Aparte el ratón y recorra la página con Tab (vea el apartado siguiente).
6. Zoom (2 minutos). Al 200 % y después al 400 %, ¿puede seguir leyéndolo todo y usar el menú sin desplazarse en horizontal?
7. Formularios e idioma (2 minutos). Haga clic en la etiqueta de cada campo; en un formulario bien hecho, eso pone el cursor en el campo. Mire en el informe de la herramienta si falta el idioma de la página.

¿Cómo se hace una prueba con el teclado?

Guarde el ratón. Pulse Tab para avanzar, Mayús+Tab para retroceder, Intro para seguir enlaces, la barra espaciadora o Intro para pulsar botones, y las flechas dentro de los menús y los botones de opción. Debe poder llegar a todos los elementos interactivos, ver siempre dónde está y no quedarse nunca atascado.

En un Mac, Safari se salta los enlaces al pulsar Tab hasta que se activa en sus ajustes avanzados la opción de resaltar cada elemento de la página web con la tecla Tab. Después, compruebe:

• ¿Ve siempre dónde está? Si el contorno del foco desaparece, quien usa el teclado está perdido.
• ¿El orden es lógico? El foco debe seguir el orden de lectura.
• ¿Queda algo tapado? Una cabecera fija o un banner de cookies que oculta el elemento con foco incumple el criterio Foco no oculto de las WCAG 2.2.
• ¿Puede volver a salir? Abra cada menú, ventana emergente y selector de fecha e intente salir. Escape debería cerrar los cuadros de diálogo.
• ¿Funciona el recorrido completo? Añada un producto, cambie la cantidad, aplique un cupón y llegue al pago sin el ratón.

Anote cada fallo con precisión: «El selector de talla de la ficha de producto no se abre con Intro ni con la barra espaciadora» se corrige mucho antes que «el teclado no funciona».

¿Cómo se prueba con un lector de pantalla por primera vez?

Empiece con el lector de pantalla que ya trae su dispositivo, o con NVDA en Windows, y escuche una sola página. No se trata de usarlo como un experto, sino de comprobar que los encabezados, los enlaces, los botones, las imágenes y los campos de formulario se anuncian con nombres que tienen sentido, y que nada importante se queda en silencio.

• Mac: Comando+F5 activa y desactiva VoiceOver; Control+Opción+U abre el rotor, una lista de encabezados, enlaces y controles de formulario.
• Windows: en NVDA, pulse H para saltar entre encabezados e Insert+F7 para listar enlaces y encabezados.
• Móvil: active VoiceOver (iPhone) o TalkBack (Android) y deslice hacia la derecha para pasar de un elemento a otro. Aprenda antes cómo desactivarlo.

Preste atención a lo que más importa. En la encuesta de WebAIM de 2024 a usuarios de lectores de pantalla (se abre en una pestaña nueva), el 71,6 % dijo que recorre primero una página larga por sus encabezados, así que empiece por ahí. Después abra la lista de enlaces: cinco enlaces llamados «Leer más» no le dicen nada a nadie. «Añadir a la cesta, jersey azul marino» es un botón útil; «botón», no. Por último, rellene un formulario y compruebe que se leen todos los campos y todos los errores.

Sea prudente con las conclusiones. Si a usted le parece que falla, probablemente falle; si le parece que va bien, eso no lo demuestra. Para saber cómo trabajan de verdad los usuarios con experiencia, lea cómo usan la web las personas con discapacidad.

¿Cómo se comprueban el zoom, el reajuste y el espaciado del texto?

Amplíe el navegador al 200 % y compruebe que el texto crece sin cortarse ni solaparse. Después pruebe el reajuste del contenido (reflow): al 400 % de zoom en una ventana de 1280 píxeles de ancho, el contenido debe caber sin desplazamiento horizontal. Por último, aumente el espacio entre letras, palabras, líneas y párrafos, y compruebe que nada se rompe ni desaparece.

Estas pruebas corresponden a los criterios de las WCAG Cambio de tamaño del texto (1.4.4), Reajuste del contenido (1.4.10) (se abre en una pestaña nueva) y Espaciado del texto (1.4.12) (se abre en una pestaña nueva). El reajuste usa un ancho de 320 píxeles CSS, que según el W3C «equivale a un ancho inicial de ventana de 1280 píxeles CSS con un zoom del 400 %». El espaciado del texto exige que no se pierda nada cuando el lector fija el interlineado en 1,5 veces el tamaño de la fuente, el espacio entre párrafos en 2 veces, el espacio entre letras en 0,12 veces y el espacio entre palabras en 0,16 veces.

Un bookmarklet de espaciado de texto, un pequeño script guardado como marcador, aplica los cuatro valores con un clic. Busque texto que se sale de los botones y etiquetas cortadas en el borde. Al 400 % de zoom, un portátil muestra más o menos lo mismo que un móvil pequeño, así que una web adaptable bien construida ya supera buena parte de esto.

¿Cómo se comprueban los formularios, los errores y el proceso de pago?

Rellene cada formulario importante tres veces: una correctamente, otra con todos los campos vacíos y otra con errores a propósito. Cada campo debe tener una etiqueta visible, cada error debe explicarse con palabras junto a su campo, y debe poder pegar en los campos de contraseña y de código de verificación.

• Errores. «Entrada no válida» en rojo no basta. «Introduzca la fecha de caducidad con el formato MM/AA», junto al campo, sí. Tras enviar, el foco debe pasar al resumen de errores o al primer campo con problemas.
• Inicios de sesión y códigos. Según el criterio de autenticación accesible (se abre en una pestaña nueva) de las WCAG 2.2, bloquear el pegado o los gestores de contraseñas incumple, salvo que haya otra forma de entrar.
• CAPTCHA y límites de tiempo. En la encuesta de WebAIM, los usuarios de lectores de pantalla situaron el CAPTCHA como el elemento más problemático de la web. Compruebe que hay una alternativa accesible y que los límites de tiempo se pueden ampliar.

Nuestra lista de comprobación de accesibilidad web tiene una lista más completa para tiendas, que incluye banners de cookies y ventanas emergentes.

¿Qué incluye una auditoría de accesibilidad profesional y cuándo la necesito?

Una auditoría de accesibilidad es una revisión estructurada que hace un especialista con una norma concreta, normalmente las WCAG 2.1 o 2.2 nivel AA. Combina análisis automáticos con pruebas manuales y con productos de apoyo de sus plantillas y recorridos clave, y termina con un informe priorizado. La necesita cuando la ley se le aplica, antes de un lanzamiento importante o cuando sus clientes le piden pruebas.

Antes de cerrar un precio, pregunte:

• ¿Con qué norma, versión y nivel van a evaluar?
• ¿Qué plantillas y recorridos entran en el alcance? Para una tienda: inicio, categoría, producto, cesta, pago, páginas de la cuenta y formularios.
• ¿Prueban manualmente con lectores de pantalla, teclado y zoom, y en qué navegadores y dispositivos?
• ¿Clasifica el informe los problemas por gravedad, los localiza y propone soluciones?
• ¿Está incluida una nueva prueba tras las correcciones?

Los precios varían mucho según el proveedor, el país y el alcance, así que compare qué incluye cada oferta. Si le afecta la Ley Europea de Accesibilidad, una auditoría también respalda su declaración pública; nuestra guía sobre la EAA explica a quién se aplica.

¿Por qué hacer pruebas con personas con discapacidad?

Porque cumplir una norma y ser fácil de usar no son lo mismo. Un proceso de pago puede cumplir todos los criterios de las WCAG y aun así costarle veinte minutos a un usuario de lector de pantalla. El W3C dice que evaluar con usuarios con discapacidad «identifica problemas de usabilidad que no se descubren solo con la evaluación de la conformidad», y además le muestra a su equipo cómo usa la gente realmente la web.

No necesita un laboratorio. Unas pocas sesiones sobre su tarea más importante, como encontrar un producto y pagarlo, le enseñarán más que otra ronda de análisis. Busque participantes a través de organizaciones de personas con discapacidad, agencias de investigación o sus propios clientes, y pague a la gente por su tiempo. Deje que usen sus propios dispositivos y ajustes. La guía del W3C sobre cómo implicar a los usuarios en la evaluación (se abre en una pestaña nueva) cubre la parte práctica.

¿Qué hago con los resultados?

Ordene los problemas según lo mucho que bloquean a la gente y dónde aparecen, corríjalos en el código y el contenido de la propia web, vuelva a probar y deje constancia de lo pendiente. Un campo sin etiqueta en el proceso de pago importa más que un descuido de contraste en el pie de página, y una corrección en una plantilla compartida arregla todas las páginas que la usan.

1. Priorice. Primero los bloqueos en los recorridos clave (pago, reserva, registro), después las plantillas compartidas y por último las páginas sueltas.
2. Corrija en el origen. Cambie la plantilla, el componente o el contenido, no solo el síntoma.
3. Vuelva a probar. Repita las mismas comprobaciones, manualmente además de con herramientas.
4. Documente. Enumere los problemas conocidos, con fechas, en su declaración de accesibilidad. Nuestra guía de las WCAG 2.2 explica los criterios más recientes.
5. Repita. Añada una comprobación con teclado y un análisis automático a cada versión que publique.

Si usa un widget de accesibilidad, incluido el nuestro, haga las pruebas con el panel cerrado. Un panel como SiteAccessible da a los visitantes más formas de ajustar la página, pero las WCAG evalúan si la página funciona en su estado por defecto. Algunos sistemas de auditoría no evalúan páginas que ejecutan un script de tipo overlay, así que consúltelo antes con su auditor.