Les personnes ne devraient pas avoir à résoudre l’interface
Imaginez un formulaire de demande pour un projet de site. Un visiteur décrit la tâche, ajoute un contact et appuie sur Envoyer, pour ne voir qu’un contour rouge. Manque-t-il un numéro de téléphone, la connexion a-t-elle échoué ou la demande a-t-elle déjà été envoyée ? Cette incertitude est un problème de conception, pas un défaut d’attention. Une maquette utile doit couvrir la saisie inachevée, plusieurs erreurs, l’attente et la réussite, pas seulement un formulaire parfaitement rempli. Ces petits états déterminent si le parcours entier a du sens.
Expliquez ce que demande le champ
Chaque champ a besoin d’un libellé compréhensible ; WAI recommande de l’associer à sa commande. Un exemple de format ne remplace pas le libellé. Dans notre brief imaginaire, le numéro de téléphone pourrait être facultatif lorsque l’adresse e-mail suffit. Une adresse professionnelle complète ne devrait pas être exigée par habitude lorsqu’elle n’a aucune utilité dans le premier échange. Avant de dessiner le formulaire, listez ses champs et expliquez pourquoi chacun existe. Si un champ n’a pas de rôle clair, reconsidérez-le. W3C WAI : étiqueter les commandes
Nommez le problème réel
Les erreurs détectées nécessitent une description textuelle identifiant le champ concerné ; la couleur seule ne suffit pas. Au lieu d’un vague message de données invalides, un champ de contact manquant pourrait indiquer « Ajoutez votre adresse e-mail ». Pour notre formulaire, préparez des formulations distinctes pour un contact vide, une description incomplète et un service indisponible. Les réunir dans un seul bandeau rouge masque une distinction importante : corriger la saisie et remédier à un échec d’envoi demandent des actions différentes. W3C : identification des erreurs
Proposez un moyen de corriger
Lorsqu’une correction est connue et peut être suggérée sans risque, expliquez-la. Si un champ a une limite de longueur précise, décrivez-la plutôt que de demander de réessayer. Dans un formulaire long, un récapitulatif des erreurs avec des liens vers les champs concernés peut compléter les indications locales. Évitez les messages qui recouvrent le texte saisi. Parcourez le processus au clavier : la personne doit pouvoir trouver le problème, le corriger et poursuivre sans réécrire tout le brief du projet. W3C : suggestions après une erreur
La validation n’est pas la livraison
La validation dans le navigateur ne remplace pas la validation sur le serveur. Une adresse au bon format ne prouve pas non plus qu’un message a été livré. Le texte de résultat doit correspondre à la réponse réelle du système. Dans notre exemple, une demande enregistrée diffère d’un envoi échoué. Ne promettez pas de rappel dans cinq minutes si ce processus n’existe pas réellement. Envisagez les clics répétés, une connexion lente et la réouverture de la page comme des situations distinctes au lieu de supposer que chaque demande suit le scénario idéal. MDN : validation des formulaires côté client
Testez autre chose que la réussite
WAI recommande un retour pour les envois réussis comme pour les échecs. Avant la mise en ligne, essayez un formulaire vide, un contact incorrect, une longue description, une correction, une réussite et une panne du service. Vérifiez le texte agrandi, le téléphone et la navigation au clavier ; l’accessibilité demande aussi des tests avec des technologies d’assistance. Cette courte liste n’est pas une certification. C’est une manière pratique de découvrir si le formulaire aide à avancer plutôt que de laisser chacun interpréter une bordure rouge inexpliquée. W3C WAI : notifications aux utilisateurs