Des messages d'erreur qui aident vraiment

« Saisie invalide » est un haussement d'épaules, pas un message

Quelque part dans le code de votre formulaire, un contrôle vient de s'exécuter. Il sait quel champ a échoué, quelle règle a été enfreinte, et généralement ce que le visiteur voulait probablement dire. Puis le formulaire se tourne vers le visiteur et résume tout ce savoir en « Saisie invalide ». Ou une bordure rouge sans un mot. Ou le classique : « Une erreur s'est produite ».

Le visiteur est laissé à faire le diagnostic lui-même : relire chaque champ, deviner des règles tues, découvrir peut-être par essais et erreurs que le champ téléphone refuse secrètement les parenthèses. Chaque tour de ce jeu de devinettes vous coûte un pourcentage de ceux qui y jouent. Et ceux qui abandonnent ne déposent pas de plainte sur votre validation. Ils s'en vont, et les statistiques du formulaire enregistrent un envoi abandonné de plus sans explication.

Ce qui est frustrant, c'est que le texte des erreurs est presque gratuit. Ce n'est pas un projet d'ingénierie ; c'est une tâche d'écriture que l'ingénierie a déjà rendue possible. Le formulaire connaît la réponse. Quelqu'un doit juste décider qu'elle vaut la peine d'être dite.

Une erreur utile répond à trois questions

Quel champ. Ce qui cloche. À quoi ressemble le juste. « Numéro de téléphone : il faut un indicatif régional, comme 555-012-3456 ». Tout ce qui répond aux trois permet au visiteur de corriger l'erreur en un seul mouvement, ce qui est toute la tâche. Tout ce qui répond à moins de trois délègue la partie manquante à la patience du visiteur.

Le ton travaille aussi. Le visiteur a fait une erreur sur votre formulaire, ce qui est différent d'avoir mal agi. « Veuillez saisir une adresse e-mail valide » se lit comme une contravention ; « Il nous faut un e-mail comme nom@exemple.org pour vous répondre » s'explique et donne une raison d'obtempérer. Les meilleurs messages d'erreur se remarquent à peine comme des erreurs. Ils se lisent comme un collègue pointant la ligne qui mérite un second regard.

Il y a aussi une catégorie d'erreur qui n'est pas du tout la faute du visiteur : le serveur a échoué, la connexion a lâché, quelque chose de votre côté a cassé. Ces messages ont besoin de l'accent inverse : « Quelque chose a échoué de notre côté ; votre message est toujours là, veuillez réessayer ». La pire chose qu'un formulaire puisse faire est de formuler sa propre défaillance comme celle du visiteur.

Mettez l'erreur là où les yeux sont déjà

Un message d'erreur affiché loin de son champ est une chasse au trésor. La place naturelle de chaque message est juste à côté du champ qu'il concerne. Les yeux du visiteur y sont déjà, et la correction est à une largeur de main de l'explication. Un bandeau rouge en haut de page qui dit « il y a eu 3 erreurs » pendant que les erreurs elles-mêmes se cachent sous la ligne de flottaison réussit à être alarmant et inutile en même temps.

Les longs formulaires méritent une seconde couche : un récapitulatif en haut listant chaque problème, chaque élément menant directement à son champ. Ce n'est pas une contradiction de la règle du à-côté-du-champ. C'est en plus, et cela existe surtout pour la situation où un visiteur envoie depuis le bas d'une longue page et où les échecs sont éparpillés au-dessus. Le focus doit se poser sur ce récapitulatif quand il apparaît, pour que la prochaine action du visiteur soit de le lire, pas de le chercher.

Et sous tout cela, la règle vue plus tôt dans cette série gouverne toujours : une erreur ne doit jamais coûter au visiteur son travail. Un formulaire qui répond à une faute de frappe dans le champ téléphone en vidant le champ message a puni le mauvais crime.

Quand se manifester

Le moment est une décision à part entière. Un formulaire qui valide à chaque frappe gronde les gens pour des phrases qu'ils n'ont pas finies : l'adresse e-mail est « invalide » pendant tout le temps où elle est tapée, ce qui est à la fois techniquement vrai et complètement inutile. La réponse à moitié formée du visiteur n'est pas encore fausse ; elle est en cours.

Le schéma calme vérifie quand le visiteur quitte un champ (le moment où sa réponse est censée être complète) et de nouveau à l'envoi, ce qui attrape ce qui a été sauté. Et une fois qu'un champ a été marqué faux, la courtoisie s'inverse : revalidez alors pendant la frappe, pour que l'erreur s'évapore à l'instant où la correction atterrit plutôt que de traîner jusqu'au prochain envoi. Lent à accuser, prompt à pardonner.

Des erreurs que tout le monde peut percevoir

Une part significative des visiteurs ne verra jamais votre rouge. Les visiteurs daltoniens peuvent voir la bordure d'erreur comme une bordure de plus ; les utilisateurs de lecteurs d'écran ne la voient pas du tout. La couleur peut souligner une erreur, mais elle ne peut pas être l'erreur. Chaque échec a besoin de mots, attachés au champ dans le balisage, pour que les technologies d'assistance annoncent le problème quand le champ reçoit le focus. Une erreur qui n'existe que comme une teinte est, pour une partie de votre public, une erreur qui n'existe pas.

Cela pèse le plus sur le public que cette série garde en vue : les institutions publiques, dont les formulaires sont souvent le moyen légalement prévu d'atteindre un service et dont les obligations d'accessibilité ne sont pas de simples aspirations. Mais le cadrage de la conformité sous-estime l'enjeu. Le visiteur qui a le plus besoin que le message d'erreur soit explicite est, de façon disproportionnée, celui pour qui les formulaires du secteur public existent : plus âgé, moins à l'aise en ligne, sur une technologie empruntée, dans une seconde langue.

La suite de cette série : le même soin passe aux petits écrans. Zones tactiles et claviers mobiles, et pourquoi le téléphone dans la main de votre visiteur est le relecteur le plus strict que votre formulaire affrontera jamais.