Accesibilidad de la web: las comprobaciones que ayudan a las personas a usarla

El modo más rápido de saber si una web se puede usar es intentar rellenar la solicitud de presupuesto sin tocar el ratón. Si no se consigue —porque el cursor desaparece, porque no se llega a un campo, porque el botón no responde— entonces hay quien no consigue escribirte, y nunca lo sabrás: quien no lo consigue no manda un aviso, cierra la página.

La accesibilidad se verifica en los recorridos, no en las páginas en abstracto. Los recorridos que importan son dos o tres: encontrar el servicio, entender si se ajusta al propio caso, preguntar. Esta guía sirve para comprobarlos con tus propias manos y transformar lo que se encuentra en correcciones asignadas.

Cuatro comprobaciones que se hacen en diez minutos, sin herramientas

1. El teclado. Desde la primera línea de la página, con la tecla de tabulación, se tiene que poder llegar a cada enlace, cada campo y cada botón, en un orden que sigue la lectura. Prueba a abrir el menú, a cerrar una ventana que aparece sola, a enviar el formulario.
2. El foco activo. Mientras te mueves con el teclado se tiene que ver siempre dónde estás: un contorno, un color, algo. Muchos temas gráficos lo quitan porque se considera poco estético: es el defecto más frecuente y a la vez el más fácil de corregir.
3. El contraste. Texto gris claro sobre blanco, letras sobre una fotografía, botones con etiqueta casi del mismo tono que el fondo. Son los puntos donde se pierde quien lee desde una pantalla al sol o con la vista cansada, es decir, casi todo el mundo tarde o temprano.
4. La jerarquía de los títulos. Un título principal por página, luego secciones y subsecciones en orden, sin saltos y sin títulos usados solo para hacer el texto más grande. Así es como se recorre una página cuando no se ve entera de una vez.

Imágenes, formularios y mensajes de error

La segunda ronda se refiere a lo que una página comunica cuando no se mira entera.

• Textos alternativos: describen para qué sirve la imagen en ese punto, no lo que se ve. El logotipo se describe con el nombre de la empresa; una fotografía decorativa no necesita descripción; un esquema que aporta una información hay que describirlo por completo, o esa información hay que escribirla también en el texto.
• Etiquetas de los campos: cada campo tiene su etiqueta, visible y asociada al campo. El texto gris dentro de la casilla no es una etiqueta: desaparece en cuanto se escribe, y quien se distrae ya no sabe qué estaba rellenando.
• Mensajes de error: tienen que decir qué campo y qué corregir, permanecer visibles y no depender solo del color. Un borde rojo no es un mensaje.
• Campos obligatorios: se indican antes, no después del intento de envío. Y el formulario no debe borrar lo que ya se había escrito.

Herramientas automáticas y pruebas manuales

Las herramientas automáticas son útiles y no bastan: encuentran lo que se puede contar, no lo que tiene sentido. Hacen falta las dos, y conviene saber qué esperar de cada una.

La regla práctica: lo automático se pasa una vez para limpiar lo grueso y luego en cada publicación; lo manual se repite en cada modificación de los recorridos principales, porque es lo único que dice si una persona llega hasta el final.

Un protocolo de prueba para la solicitud de presupuesto

Escrito una vez, se repite igual cada vez que la web cambia. Lo ejecuta una sola persona, en media hora, anotando dónde se ha detenido y qué ha tenido que adivinar.

1. Abrir la home y llegar a la página del servicio usando solo el teclado. Anotar cuántos pasos hacen falta y si se ve siempre dónde se está.
2. Ampliar el texto con el comando del navegador hasta el doble. Comprobar que no desaparezca nada, que el menú se pueda seguir abriendo y que no aparezca una barra de desplazamiento horizontal.
3. Rellenar el formulario con el teclado dejando a propósito vacío un campo obligatorio y escribiendo mal la dirección de correo. Verificar que el error esté escrito, sea accesible y comprensible sin mirar el color.
4. Corregir y enviar. Verificar que la confirmación sea un texto que se pueda leer y volver a encontrar, no solo un cambio de color o un icono.
5. Repetir el recorrido desde el móvil, con una sola mano, y luego con la pantalla en horizontal.
6. Repetir el primer paso con el lector de pantalla activado, aunque sea solo el que ya trae el sistema operativo. No hace falta ser experto para darse cuenta de que un botón se anuncia como «botón» y nada más.

Asignar las correcciones y volver a verificar

Una lista de problemas sin un nombre al lado no produce correcciones. Cada punto hay que escribirlo con cuatro datos: dónde ocurre, qué impide hacer, quién lo corrige, cómo se verifica que esté resuelto. El orden no es el que se siguió al encontrar los problemas.

• Primero lo que impide completar un recorrido: un formulario que no se puede enviar va antes que un contraste un poco escaso.
• Luego lo que se repite en toda la web: el foco activo invisible o las etiquetas ausentes se corrigen una vez en la plantilla de página y valen en todas partes.
• Al final los casos individuales, página por página, que a menudo son contenido y no código: una descripción por reescribir, un título usado en el lugar equivocado.
• Después de cada corrección se repite el protocolo entero en los recorridos afectados. Las correcciones de accesibilidad se deshacen con facilidad en el primer cambio de diseño o en el primer componente añadido.

Lo que esta guía no cubre

Aquí se verifica si la web se puede usar, no si cumple una obligación legal: la aplicabilidad de las normas, las verificaciones formales y las eventuales declaraciones requieren competencias específicas y hay que evaluarlas por separado. Tampoco se aborda qué preguntas incluir en un formulario de contacto, que es una cuestión de contenido y no de accesibilidad, ni las pruebas generales antes del lanzamiento, que incluyen muchas otras verificaciones además de estas.