Un message d’erreur utile nomme le champ, explique le problème et indique comment le corriger. Il reste visible, relié au champ et compréhensible sans couleur seule. Distinguez une erreur de saisie d’une panne d’envoi et conservez les informations non sensibles qui n’ont pas besoin d’être ressaisies.
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.
Repères documentaires pour ce sujet
| Référence | Valeur ou syntaxe | Portée du repère |
|---|---|---|
| WCAG 2.2 · 3.3.7 | A · same process | Dans un même processus, une information déjà fournie doit être préremplie ou disponible à la sélection, sauf exceptions du critère. L’autocomplétion du navigateur seule ne suffit pas ; le site doit proposer la donnée déjà reçue ou éviter de la redemander. |
Les dates indiquent la consultation des références. Ces repères ne constituent ni un audit du site ni une déclaration globale de conformité.
Atelier de vérification : une preuve avant la décision
Exercice proposé sur un périmètre choisi, avec des données fictives si nécessaire. Consignez le résultat observé ; ce scénario ne décrit pas un test déjà réalisé sur votre site.
- Manipulation à essayer
Provoquez une erreur de format sur un formulaire de test. Essayez de comprendre la correction demandée, de retrouver le champ et de réussir avec le clavier.
- Trace à conserver
Gardez texte du message, lien ou association au champ, focus et nouvelle tentative. Vérifiez que les autres valeurs utiles ne disparaissent pas.
- Ce que la preuve ne démontre pas
Une bordure rouge seule ne décrit pas la correction. La présence d’un attribut ARIA ne prouve pas que le message est annoncé dans l’environnement testé.
Documentation complémentaire : W3C WAI — User notifications
Faire reprendre une saisie sans perdre le message
Une personne envoie un formulaire sans adresse valable et avec un champ obligatoire vide. Le site signale chaque problème près du champ, résume les erreurs, garde le texte déjà saisi et rend le focus facile à retrouver. Elle corrige puis reçoit une confirmation explicite.
Testez au clavier et sur téléphone. Un message comme « erreur 400 » ou une couleur seule ne permet pas de comprendre ni de corriger la saisie.
