Las personas no deberían tener que descifrar la interfaz
Imagina un formulario de consulta para un proyecto web. Un visitante describe la tarea, añade un contacto y pulsa enviar, pero solo ve un contorno rojo. ¿Falta un teléfono, ha fallado la conexión o la consulta ya se ha enviado? Esa incertidumbre es un problema de diseño, no una falta de atención. Una maqueta útil debe contemplar datos incompletos, varios errores, espera y éxito, no solo un formulario perfectamente rellenado. Estos pequeños estados determinan si todo el recorrido tiene sentido.
Explica qué necesita el campo
Cada campo necesita una etiqueta comprensible; WAI recomienda asociarla con su control. Un ejemplo de formato no sustituye la etiqueta. En nuestro encargo imaginario, el teléfono podría marcarse como opcional si basta el correo electrónico. No debería exigirse una dirección comercial completa por costumbre cuando no cumple ninguna función en la primera conversación. Antes de dibujar el formulario, enumera sus campos y explica por qué existe cada uno. Si un campo no tiene un propósito claro, reconsidéralo. W3C WAI: etiquetado de controles
Nombra el problema real
Los errores detectados necesitan una descripción textual que identifique el campo afectado; el color por sí solo no basta. En lugar de un mensaje vago sobre datos no válidos, un campo de contacto vacío podría decir «Añade tu dirección de correo electrónico». Para nuestro formulario, prepara textos distintos para un contacto vacío, una descripción incompleta y un servicio no disponible. Reunirlos en un solo aviso rojo oculta una distinción importante: corregir datos y recuperarse de un fallo de envío requieren acciones diferentes. W3C: identificación de errores
Ofrece una vía para continuar
Cuando se conoce una corrección y es seguro sugerirla, explícala. Si un campo tiene una restricción de longitud concreta, describe esa restricción en vez de pedir que se vuelva a intentar. En un formulario largo, un resumen de errores con enlaces a los campos afectados puede complementar las indicaciones cercanas. Evita mensajes que tapen el texto introducido. Recorre el proceso con un teclado: una persona debería poder encontrar el problema, corregirlo y continuar sin reescribir todo el encargo del proyecto. W3C: sugerencias ante errores
Validar no es entregar
La validación en el navegador no sustituye la validación en el servidor. Una dirección con formato correcto tampoco demuestra que el mensaje se haya entregado. El texto del resultado debe corresponder a la respuesta real del sistema. En nuestro ejemplo, que una consulta se guarde es distinto de que falle el envío. No prometas una llamada en cinco minutos si ese proceso no existe realmente. Considera los clics repetidos, una conexión lenta y volver a abrir la página como situaciones independientes, en lugar de asumir que toda solicitud sigue el camino ideal. MDN: validación de formularios del lado del cliente
Prueba algo más que el éxito
WAI recomienda informar tanto de los envíos correctos como de los fallidos. Antes del lanzamiento, prueba un formulario vacío, un contacto incorrecto, una descripción larga, la corrección, el éxito y un fallo del servicio. Comprueba el texto ampliado, un teléfono y la navegación con teclado; la accesibilidad también requiere pruebas con tecnología de asistencia. Esta breve lista no es una certificación. Es una forma práctica de descubrir si el formulario ayuda a avanzar en lugar de obligar a interpretar un borde rojo sin explicación. W3C WAI: notificaciones al usuario