Probar la accesibilidad de una web: así se hace

¿Cómo pruebo la accesibilidad de una web?

Una prueba tiene tres niveles: un análisis automático, una revisión manual hecha por ti o por especialistas y, en los recorridos importantes, las opiniones de personas con discapacidad. Ningún nivel sustituye a los demás.

Define antes con qué vas a medir. Para la mayoría de los proyectos, WCAG 2.2 en el nivel AA es un objetivo razonable. Con WCAG-EM, el W3C describe un método en cinco pasos: definir el alcance, explorar la web, elegir una muestra representativa, evaluarla e informar de los resultados. También para equipos pequeños este orden es una buena guía. La primera ronda no tiene que ser perfecta. Lo importante es que puedas repetirla: las mismas páginas, los mismos recorridos, las mismas notas.

¿Qué páginas deberías revisar?

No revises cien páginas de producto parecidas, sino cada plantilla una vez. Una buena muestra incluye la página de inicio, la navegación, la búsqueda, una página de contenido, una página de producto o de servicio, el formulario de contacto, el inicio de sesión, el carrito y el proceso de pago, además de una página de error.

Piensa también en los estados: menú abierto, formulario con mensajes de error, diálogo, banner de cookies y mensaje de confirmación. También cuentan las descargas PDF importantes y las áreas tras el inicio de sesión, a las que no llega un análisis público. Anota para cada página qué tarea se realiza en ella. Así, más adelante no valorarás solo errores aislados, sino si el recorrido funciona en su conjunto.

¿Qué encuentra una prueba automática y qué no?

Un escáner encuentra rápidamente errores técnicos: textos alternativos que faltan, contrastes demasiado bajos, campos de formulario sin nombre o estructuras de encabezados incorrectas. No detecta si un texto alternativo describe lo correcto, si el orden del foco es lógico o si unas instrucciones son comprensibles.

El análisis de Accessonaut usa axe-core, clasifica cada aviso por importancia y explica cómo solucionar el problema. Según el W3C, ninguna herramienta automática puede determinar por sí sola si una web cumple los estándares de accesibilidad. Por eso, un análisis es un punto de partida para tu trabajo, no una certificación. Usa los resultados como lista de tareas con hallazgos concretos.

¿Cómo se hace una prueba manual?

• Título de la página: Comprueba en la pestaña del navegador si cada página tiene un título único y adecuado.
• Teclado: Deja el ratón a un lado y usa la navegación, los diálogos y los formularios con Tab, Mayús+Tab, Intro y Escape. El foco debe verse en todo momento.
• Zoom: Amplía la página al 200 % y comprueba si los contenidos y las funciones siguen siendo accesibles.
• Contraste: Mide los colores del texto y del fondo con una herramienta de contraste. El texto normal necesita al menos 4,5:1.
• Color: Comprueba si la información se reconoce también sin color, por ejemplo los campos obligatorios, los errores o los enlaces dentro del texto.
• Encabezados: Comprueba si los encabezados estructuran la página y siguen una jerarquía lógica.
• Formularios: Envía datos erróneos a propósito y comprueba si los errores se indican de forma comprensible.
• Movimiento y multimedia: Comprueba si los carruseles y las animaciones se pueden detener y si los vídeos tienen subtítulos.
• Móvil: Repite los pasos más importantes en un smartphone, también en horizontal.
• Lenguaje: Lee en voz alta las instrucciones y los textos de los botones. ¿Entiendes sin conocimientos previos qué pasará a continuación?

¿Cómo pruebas con un lector de pantalla?

Para una primera prueba bastan los lectores de pantalla gratuitos o integrados: NVDA en Windows, VoiceOver en Mac y iPhone, TalkBack en Android. Reserva algo de tiempo para familiarizarte, porque el manejo es muy distinto al del ratón. Prueba con un navegador para el que esté pensado el lector de pantalla, por ejemplo VoiceOver con Safari.

Escucha si los enlaces, los botones y los campos se anuncian de forma comprensible. Salta por la página mediante la lista de encabezados y rellena un formulario. Fíjate en si se leen los mensajes de error y los cambios de estado como «Artículo añadido al carrito». Hallazgos típicos son botones que solo se llaman «botón», imágenes de las que se lee el nombre del archivo y diálogos que no se anuncian como tales. Encontrarás una guía detallada en el artículo sobre la prueba con lector de pantalla.

¿Por qué deberías implicar a personas con discapacidad?

Quien trabaja a diario con lector de pantalla, ampliación o control por voz detecta obstáculos que pasan desapercibidos en una prueba rápida. Entre ellos están los procesos engorrosos, los términos poco claros o un manejo que funciona, pero que lleva demasiado tiempo.

Ten en cuenta estas opiniones sobre todo en los recorridos centrales, como el pedido, la reserva o el registro. Anota las observaciones sin generalizarlas a la ligera: una persona no habla por todas las personas con la misma discapacidad. Reserva tiempo y una remuneración justa y prepara tareas concretas, por ejemplo «Pide este producto en la talla M».

¿En qué orden corriges los hallazgos?

Un botón que no se puede usar puede bloquear un recorrido completo. Un campo de formulario sin nombre dificulta la entrada de datos con un lector de pantalla. Empieza por estos obstáculos, sigue con los problemas que aparecen en muchas páginas y deja para el final los casos aislados.

En cada hallazgo, lee la explicación, la ubicación y la referencia WCAG asignada. Si la causa está en un componente compartido, como la cabecera o la tarjeta de producto, lo corriges allí una sola vez para todas las páginas. Ayuda una clasificación sencilla: bloquea, dificulta o molesta. Anota para cada punto quién lo corrige y para cuándo.

¿Cómo documentas los resultados y vuelves a revisar?

Anota el hallazgo, la URL afectada, el cambio y el resultado de la nueva revisión. Después de publicaciones importantes, revisa los mismos recorridos. Una revisión periódica hace visibles los avances y los problemas nuevos.

Define ocasiones fijas para una nueva revisión: una plantilla nueva, un plugin nuevo, una actualización del tema o un cambio en el proceso de pago. Los análisis automáticos puedes repetirlos a menudo para ver pronto los nuevos errores técnicos. Las pruebas manuales de los recorridos más importantes las repites tras cambios importantes.