Un message d'erreur doit dire ce qui bloque et comment corriger le champ. « Saisie invalide » ou un cadre rouge sans texte ne suffisent pas, surtout pour une personne qui utilise le clavier ou un lecteur d'écran.
Donner une instruction liée au champ
Écrivez « Indiquez une adresse e-mail contenant @ » plutôt que « Erreur 42 ». Placez le texte près du champ et associez-le techniquement à celui-ci. Le W3C recommande des notifications claires, avec un retour global après l'envoi et un retour près du contrôle concerné.
Prévenir plutôt que surprendre
Précisez avant saisie les formats et informations obligatoires : longueur d'un identifiant, format de date ou taille maximale d'un fichier. N'affichez pas une contrainte connue seulement après plusieurs tentatives. Les exemples doivent correspondre aux formats réellement acceptés et éviter d'exiger des données non nécessaires à la tâche.
Conserver les réponses et guider le retour
Après une erreur serveur ou de validation, gardez les champs déjà saisis lorsque c'est possible. Affichez un résumé des erreurs en haut du formulaire et des indications locales. Placez le focus à un endroit logique pour reprendre la correction, puis laissez l'utilisateur vérifier les changements avant un nouvel envoi.
Distinguer correction, panne et réussite
Un champ mal rempli n'est pas une indisponibilité du service. Si l'envoi échoue pour une raison technique, annoncez-le sans prétendre que la demande a été reçue et donnez un autre moyen de contact si possible. À l'inverse, un envoi réussi doit fournir une confirmation explicite et indiquer la suite attendue.
Tester avec de vraies erreurs
Essayez un champ vide, un format plausible mais refusé, un fichier trop lourd et une perte de connexion. Testez au clavier, sur téléphone et avec une technologie d'assistance si disponible. Le guide du formulaire aide à réduire les champs avant même d'écrire leurs erreurs.