Meilleur endroit pour placer des messages d'erreur sur un formulaire (à la fois générique et spécifique)
Je travaille sur un simple formulaire d'inscription qui, lorsque des données invalides sont saisies, affichera à la fois une erreur générique (par exemple: "Il y a une erreur sur votre formulaire") et également des erreurs spécifiques (par exemple: "Ce n'est pas un vrai email adresse").
Les erreurs spécifiques seront placées à côté du champ de saisie approprié, mais je me demande où placer le message générique le mieux, en haut du formulaire ou en bas à côté du bouton Envoyer.
Ma pensée pour le placer en haut est la suivante ...
- Un contenu large (message générique) descendra jusqu'à un contenu spécifique (messages).
- Les lecteurs d'écran seront informés dès le début du formulaire qu'il y a eu un problème, plutôt que d'avoir à parcourir tout le formulaire à nouveau (s'il est en bas, ils ne sauront pas qu'il y a un message d'erreur jusqu'à ce qu'ils y parviennent) )
- Avoir un message générique en bas semble un peu inutile si l'utilisateur a déjà parcouru le formulaire et agi sur les messages spécifiques (particulièrement pertinent pour les lecteurs d'écran)
- Si la taille de la page augmente (probablement à mesure que d'autres champs peuvent être ajoutés), l'envoi du formulaire déclencherait un rechargement de la page, entraînant la chute du message générique sous le pli.
En revanche, le placer en bas serait ...
- Maintenez la pratique d'avoir l'erreur à proximité de l'entrée pertinente (dans ce cas, la soumission).
- Il pourrait être plus facile pour les utilisateurs visuels de s'orienter, car la dernière chose à laquelle ils seraient attachés aurait été la soumission, donc placer le message à côté nécessiterait moins de numérisation de leur part.
Si l'affichage de votre message d'erreur dépend d'une soumission de page (plutôt qu'en ligne), je vous déconseille fortement de le mettre en bas. La réaction automatique d'un utilisateur en le voyant à côté du bouton "soumettre" sera que ses erreurs n'ont pas encore été résolues et qu'il est donc inutile de cliquer à nouveau sur ce bouton. Le scénario le plus probable est qu'ils seront extrêmement frustrés, changeant des champs parfaitement valides pour essayer de se débarrasser du message.
Le faire en haut dans ce cas le supprime au moins de la pertinence une fois que le ou les champs individuels ont été corrigés.
Bien sûr, il y a maintenant un changement de convention vers la validation en ligne, ce qui est soit une belle surprise soit une attente pour les utilisateurs. Avez-vous une chance de jouer avec ça?
Le message d'erreur devrait être là où l'utilisateur est le plus susceptible de regarder. Si votre conception technique nécessite que la page entière soit rechargée pour afficher l'erreur, il est probable que l'utilisateur regarde en haut, car c'est là que les yeux des utilisateurs vont naturellement lorsqu'ils voient la page clignoter ou disparaître. D'un autre côté, si vous pouvez effectuer des rafraîchissements de page partiels (par exemple, avec AJAX), placez le message par le bouton d'envoi, car c'est là que les yeux seront, surtout si la validation est rapide.
Une troisième option consiste à créer à la volée une page d'erreur qui inclut uniquement le ou les champs contenant des erreurs. Ce sera probablement suffisamment compact pour que vous n'ayez besoin que du ou des messages spécifiques immédiatement au-dessus du champ. Cela évite aux utilisateurs d'avoir à lire deux messages d'erreur et à traquer le champ incriminé dans une forme longue et peut être une expérience émotionnellement plus positive car cela suggère que l'utilisateur progresse et n'est pas "coincé" sur un formulaire.
N'oubliez pas de faire la distinction entre les erreurs cruciales et les erreurs "pas si importantes" et de les placer en fonction de cela. Par exemple, les erreurs que les utilisateurs ne doivent pas manquer devraient être placées là où l'utilisateur est susceptible de regarder, et des erreurs moins cruciales peuvent être placées dans le contexte. C'est une mauvaise conception pour effrayer un utilisateur avec une grosse erreur rouge s'il n'est pas de la même ampleur que le message d'erreur lui-même ...