Décrire la correction attendue
Associez chaque message au champ concerné et dites quelle donnée est attendue. « Adresse électronique incomplète » aide davantage qu’un code technique. N’attribuez pas à l’utilisateur une panne de serveur ou un service indisponible.
Écrivez les règles avant la saisie lorsque c’est possible : format, longueur, pièces admises ou informations facultatives. Le guide du formulaire de contact aide à limiter les champs et clarifier les attentes.
- Champ et problème identifiables.
- Action de correction explicite.
- Contraintes annoncées assez tôt.
Rendre le retour perceptible
Après soumission, affichez un résumé près du début du formulaire et un message auprès de chaque champ fautif. Placez le focus de manière prévisible et reliez chaque champ à son erreur pour les technologies d’assistance. La couleur seule ne suffit pas.
Le tutoriel W3C sur les notifications donne des exemples de messages locaux et globaux. Testez clavier, lecteur d’écran, zoom et petit écran.
- Résumé et messages proches des champs.
- Association accessible des erreurs.
- Focus et contraste testés.
Préserver la saisie et l’intention
Conservez les valeurs déjà saisies après une erreur, sauf donnée sensible qui ne doit pas être réaffichée. Un formulaire long doit permettre de reprendre au bon endroit. Une pièce refusée exige une explication de format ou de taille.
Distinguez erreur de validation, délai réseau et double envoi. Évitez que des clics répétés créent plusieurs demandes ou commandes. La confirmation doit dire clairement si l’action a réellement été enregistrée.
- Champs valides conservés.
- Échecs réseau traités sans ambiguïté.
- Double soumission contrôlée.
Tester des cas réels
Essayez champ vide, caractère accentué, adresse mal saisie, fichier trop lourd, session expirée et serveur indisponible. Demandez à une personne extérieure de corriger le formulaire sans aide et observez les hésitations.
Après correction, contrôlez l’email ou l’étape suivante, pas seulement le message à l’écran. Les contenus de confirmation et d’erreur doivent aussi être revus dans chaque langue publiée.
- Cas d’erreur représentatifs couverts.
- Parcours complet vérifié.
- Messages traduits et relus.
