Una persona quiere hacer una consulta, rellena el formulario de contacto y pulsa Enviar. No sucede nada. O aparece un borde rojo que no explica qué ha fallado. Para el equipo responsable de la web, el formulario quizá esté terminado: los campos existen, la validación funciona y los mensajes se procesan. Para esta persona, en cambio, el camino para contactar se ha interrumpido.
La accesibilidad se comprueba siguiendo todo el recorrido, desde el primer campo hasta la confirmación de que el mensaje se ha recibido. Estas siete comprobaciones ayudan a diseñadores, desarrolladores y equipos de producto a evaluar la experiencia completa. Son una guía práctica inicial, no una auditoría WCAG exhaustiva.
Empieza por los datos que realmente necesitas
Piensa en una consulta sencilla. ¿Bastan el nombre, el correo electrónico y el mensaje? Cada campo adicional exige tiempo y puede convertirse en una barrera. El W3C recomienda solicitar únicamente la información necesaria para realizar la tarea.
Esa es la primera comprobación: pedir solo lo imprescindible e indicar los campos obligatorios antes de empezar. La segunda es que cada campo tenga una etiqueta visible, comprensible y vinculada técnicamente al control. Un texto de ejemplo como «Correo electrónico» desaparece al escribir y no sustituye a una etiqueta persistente.
¿Qué ocurre si no utilizas el ratón?
La persona llega al primer campo y usa únicamente Tab, Mayús+Tab y el teclado. ¿Sigue el foco un orden lógico? ¿Se distingue el elemento activo? ¿Es posible cambiar una opción y enviar el formulario? Esta es la tercera comprobación.
No limites la prueba a los campos. Un aviso de cookies, una protección antispam o un componente personalizado pueden bloquear el proceso. Y una interfaz que se ve bien en un monitor grande puede resultar difícil en un móvil con texto ampliado. La cuarta comprobación consiste en repetir el recorrido en una pantalla estrecha y con ampliación, comprobando que las etiquetas, instrucciones y botones sigan siendo utilizables.
El mensaje de error también es interfaz
Imagina ahora que la persona escribe mal su correo. «Dato no válido» apenas ayuda. «Introduce una dirección de correo válida, por ejemplo nombre@organizacion.es» explica qué debe corregir.
Quinta comprobación: describir el error con texto claro, asociarlo al campo correspondiente y explicar cómo continuar. No dependas únicamente de un borde rojo. Las recomendaciones del W3C señalan que los errores detectados deben identificarse y explicarse en texto. Conserva los datos correctamente introducidos si el envío falla.
Para implementar etiquetas, errores y gestión del foco, consulta el tutorial de Dogteam sobre validación accesible.
Enviado no siempre significa recibido
La persona corrige el correo y vuelve a intentarlo. Aparece una animación de carga. ¿Ha llegado el mensaje? No necesariamente. El servidor puede rechazar la solicitud, una integración puede fallar o una notificación puede retrasarse.
La sexta comprobación es confirmar correctamente lo sucedido: muestra un mensaje de éxito solo cuando el sistema haya aceptado el envío. Distingue entre recibido, procesado y respondido. No prometas un plazo que la organización no pueda cumplir. En una prueba de principio a fin, verifica que la consulta llegue al sistema previsto.
Prueba especialmente los casos que pueden fallar
La séptima comprobación abarca las excepciones: un formulario vacío, una dirección incorrecta, un mensaje largo y un fallo temporal del servidor. Repite las tareas esenciales con teclado y lector de pantalla. Anota navegador, dispositivo, tecnologías de apoyo y problemas pendientes.
Los análisis automáticos de accesibilidad ayudan, pero no demuestran por sí solos que una persona pueda enviar su consulta sin asistencia. Siempre que sea posible, incluye a personas con distintas discapacidades en las pruebas de uso.
Convierte el recorrido completo en un criterio de entrega
Un formulario no está terminado solo porque diseño, frontend y backend hayan completado sus partes. Está terminado cuando funciona toda la experiencia: preguntas claras, etiquetas asociadas, navegación por teclado, errores corregibles y confirmación fiable del envío.
Incluye estas condiciones en los criterios de aceptación y repite las pruebas después de modificar formularios, plugins, antispam o integraciones. La pregunta central no es si funciona el botón Enviar, sino si cualquier visitante puede completar el proceso de contacto de forma autónoma.
Si los mensajes deben enviarse a un CRM u otro sistema, también hay que verificar la entrega. Nuestro patrocinador BlazeForce explica sus servicios de integración y automatización; la integración no sustituye las pruebas de accesibilidad.
Fuentes
- W3C WAI — Forms Tutorial
- W3C WAI — Labeling Controls
- W3C WAI — User Notifications
- W3C WAI — Validating Input
- WCAG 2.2 — Error Identification
Contacta con nosotros
Cuéntanos cómo podemos ayudarte; responderemos en un plazo de dos días laborables.
