Quelle est la meilleure pratique pour concevoir des messages d'erreur de formulaire?
J'ai vu beaucoup de recherches sur la conception de formulaires, mais jusqu'à présent, je n'ai trouvé aucune étude sur les meilleures pratiques de conception de messages d'erreur. Le seul conseil semble être que chaque erreur doit clairement être associée au champ de formulaire invalide qu'elle vise à corriger. Y a-t-il eu des recherches à ce sujet?
J'ai des problèmes spécifiques que j'essaie de résoudre et j'apprécierais toute idée ou ressource.
Emplacement du message d'erreur
Lorsque vous avez une validation de formulaire en direct, où un message d'erreur (ou de réussite) doit-il apparaître par rapport à l'élément de formulaire?
Quelques options:
À droite de l'entrée
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
À droite de l'étiquette
Au-dessus de l'étiquette
Sous l'étiquette
Sous l'entrée
Il y a quelques problèmes épineux qui doivent également être pris en compte concernant l'emplacement:
- Comment les erreurs s'affichent-elles pour les groupes de radio ou de cases à cocher?
- Quelle est la largeur du message d'erreur?
- Le message d'erreur est-il sur plusieurs lignes?
Visibilité des messages d'erreur
Outre l'emplacement, je suis également intéressé par la façon dont la visibilité du message d'erreur affecte sa convivialité. Est-ce important ou est-ce strictement une décision esthétique? Considérez les 3 options suivantes:
Edit : Il y a eu jusqu'à présent d'excellents points sur l'accessibilité dans certaines des réponses, ainsi que quelques exemples intéressants. Cependant, j'aimerais vraiment voir des données de des études réelles, si possible. De plus, jusqu'à présent, aucune des réponses n'a vraiment répondu aux deux questions que j'avais posées ci-dessus:
- Où l'erreur doit-elle être localisée par rapport à l'entrée et à l'étiquette?
- Comment la conception et la visibilité du message d'erreur lui-même affectent-elles sa convivialité?
Concernant l'accessibilité des formulaires, il me semble qu'il pourrait y avoir deux cas d'utilisation potentiellement conflictuels, la validation en direct et la validation côté serveur (ce qui nécessiterait de recharger la page). Si la page est rechargée et que l'utilisateur recommence en haut du formulaire, un résumé d'erreur est logique, en particulier du point de vue de l'accessibilité. Cependant, dans le cas de la validation en direct, le résumé d'erreur en haut est beaucoup moins logique, à la fois pour la conception du formulaire et à des fins d'accessibilité.
Considérez comment un utilisateur utiliserait réellement un formulaire avec validation en direct:
La validation se produit sur l'événement de flou. Habituellement, l'accent sera mis sur l'élément de formulaire suivant, pas sur la liste en haut. Si je comprends bien les lecteurs d'écran, il n'y aurait aucune raison de retourner en haut du formulaire pour lire la liste des erreurs. Pour les utilisateurs n'utilisant pas de lecteurs d'écran, la liste d'erreurs en haut pousse le formulaire entier vers le bas, d'autant plus si l'erreur occupe également un espace vertical près du champ du formulaire. Dans les formulaires plus longs, il s'agit d'un problème d'utilisation car le résumé des erreurs peut ne pas être visible. Dans les formulaires plus courts qui comportent des erreurs par champ, comme une connexion, le résumé des erreurs ressemble simplement à un excès. Pour tous les formulaires, l'interface serait poussée vers le bas, rendant l'expérience utilisateur médiocre.
Pour la validation en direct, si vous voulez vraiment rendre les erreurs de formulaire accessibles, je pense que l'utilisation de ARIA Live Regions pourrait être la solution préférée.
Les indicateurs encapsulés sont la seule solution que j'ai trouvée qui atteigne tous les cas Edge. Le fait de pointer le drapeau sur l'étiquette plutôt que sur l'entrée permet la cohérence avec les boutons radio et les groupes de coches ou les entrées étranges comme les curseurs ou les trieurs.
Surligner le champ avec du rouge est également utile, mais pas toujours possible. Exemples d'utilisations ci-dessous.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
En lisant la réponse de @ jonW, je ne pouvais pas être plus d'accord avec ses réflexions sur les lecteurs d'écran, et ma solution peut être tout aussi efficace selon la mise en œuvre. Vous pouvez placer les drapeaux juste au nord sur les entrées du balisage et utiliser aria pour obtenir la même accessibilité
La section "Validation en ligne et événements de validation" sur cette page semble idéale: http://semantic-ui.com/modules/form.html
Il semble que vous soyez déjà marquant les champs de formulaire facultatifs au lieu de ceux obligatoires . Il ne semble pas y avoir d'indicateurs "obligatoires", mais pas d'indicateurs "facultatifs" aussi, donc je tenais à le mentionner.
Ce que j'aime faire sur les formulaires, c'est de les "micro-gamifier": pour chaque champ du formulaire prévoir un "indicateur de validation". Pour simplifier, disons que ce n'est qu'un petit cercle. Cela commence sur une position neutre: un cercle gris avec un point d'interrogation. Pour les champs facultatifs, c'est un cercle gris avec une coche. Chaque fois que l'utilisateur quitte un champ de formulaire, il est validé en direct et les choses suivantes se produisent:
l'indicateur passe à "succès", par ex. cercle vert + coche ou "erreur" (par exemple, cercle rouge + point d'exclamation)
en cas d'erreur, le champ est mis en surbrillance
s'il y a une erreur, le bouton d'envoi sera grisé (cliquer dessus fonctionnera toujours, mais cela amènera seulement l'utilisateur à la première erreur) et un message d'information générale sera affiché au-dessus.
Si vous écrivez de bons indices, il suffit de mettre en surbrillance le champ et l'indice. Si vous sentez que vous avez besoin d'un message d'erreur distinct, il est probable que vos conseils pourraient utiliser du travail. D'après mon expérience, il est presque toujours possible de couvrir les erreurs de saisie utilisateur avec de bons conseils.
L'utilisateur n'aime pas revenir mentalement dans un formulaire. Elle est traitée champ par champ, l'utilisateur se concentre sur elle champ par champ et passe par une check-list mentale. En signalant les erreurs lorsqu'elles se produisent, nous prenons en charge ce mode et ne faisons pas revenir l'utilisateur "plus tard". C'est une rupture dans le flux de l'utilisateur et une gêne à cliquer sur "soumettre" puis à être "bloqué" et "renvoyé". C'est une expérience beaucoup plus fluide si les problèmes sont simplement mis en évidence et peuvent donc être corrigés à mesure qu'ils surviennent.
Le message d'erreur doit apparaître avant le champ de formulaire lui-même (au moins dans le balisage lui-même, mais idéalement affiché visuellement de cette façon à l'écran également) de sorte que lorsque quelqu'un lit le formulaire, il lit que le champ a commis une erreur avant de lire ensuite le champ en question - de cette façon, l'utilisateur est préparé mentalement que "le contenu de ce champ que je suis sur le point de lire est incorrect et je dois donc le modifier".
Ceci est encore plus important pour créer des formulaires accessibles . Si quelqu'un lit le formulaire via le lecteur d'écran, il faut lui présenter l'erreur avant de lire le champ du formulaire pour la même raison que celle décrite ci-dessus. (Ils ne veulent pas avoir à revenir en arrière après avoir entendu le contenu d'un champ et alors se faire dire que ce champ avait une erreur). C'est pourquoi c'est l'étiquette du formulaire lui-même qui doit contenir le texte d'erreur, et pas seulement une alerte contextuelle ou scriptée car vous ne pouvez pas garantir que les lecteurs d'écran ou les navigateurs plus anciens seront capable de détecter ce texte.
De plus, s'il s'agit d'un formulaire long, ou si l'utilisateur navigue via le clavier et utilise le bouton Tab, plusieurs des champs peuvent exister sous le pli, donc si vous tabulez le formulaire, vous ne remarquerez peut-être pas qu'un champ est en erreur jusqu'à ce que vous ont ensuite tabulé dans le suivant (le champ défilera dans la vue mais si le message d'erreur est en dessous, l'erreur peut s'afficher hors écran).
Enfin, il existe un itinéraire supplémentaire que vous devriez probablement prendre pour vos messages d'erreur:
Vous devez résumer les erreurs dès le début du formulaire afin que l'utilisateur sache combien il y a des erreurs, et quoi ces erreurs sont. Vraiment, ces liens devraient vous rediriger vers les champs erronés en question (encore une autre raison pour laquelle le message d'erreur contre ces champs devrait être avant le champ lui-même)
Une grande partie de ces informations se trouvent dans le article WebAIM: validation de formulaire utilisable et accessible et récupération des erreurs
Voici un exemple. Les erreurs sont affichées au début du formulaire et sont également des liens pour que l'utilisateur puisse facilement naviguer vers les champs en question, où le texte de l'erreur est également affiché:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Il existe un vieux livre blanc (2007) présenté par Human Factors International qui contient des données sur les messages d'erreur. La conclusion qu'ils ont alors formulée était:
... la plupart des utilisateurs passent par une phase d'achèvement - dans laquelle l'objectif est l'achèvement du formulaire - suivie d'une phase de correction ou de révision, dans laquelle les erreurs sont corrigées ... les erreurs immédiates ont été largement ignorées jusqu'à ce que le formulaire soit rempli.
Ainsi, sur les six façons possibles de présenter les messages d'erreur, ces trois se sont avérées plus efficaces que les autres.
- Présentez les erreurs par la suite, intégrées dans le formulaire, d'un seul coup
- Présentez les erreurs par la suite, intégrées dans le formulaire, une par une
- Présentez les erreurs par la suite, dans les dialogues, une par une
Évidemment, nous ne ferions plus le numéro 3. Le livre blanc s'intitule "Ce que nous avons appris: regard sur 2007." Vous pouvez le télécharger depuis leur site, après avoir rempli un formulaire . :)
Il ne parle pas vraiment du placement des messages d'erreur, à l'exception de la boîte de dialogue intégrée, donc vous ne savez pas si cela est vraiment utile.
Ce que je suis sur le point de suggérer est simplement ce qui m'est venu à l'esprit comme une solution que j'utiliserais lorsque je lirais votre question.
Je m'adresse spécifiquement à la question "Lorsque vous avez une validation de formulaire en direct, où un message d'erreur (ou de réussite) devrait-il apparaître par rapport à l'élément de formulaire?"
Et si nous montrions le message au lieu de l'étiquette elle-même quelque chose comme
Au fur et à mesure que les erreurs sont résolues (considérant qu'il s'agit des validations côté client au niveau du formulaire), vous pouvez revenir à la vue d'origine des étiquettes pour aider l'utilisateur à garder une trace des autres.
Pour que cette approche fonctionne, vous voudrez peut-être rédiger soigneusement vos messages afin de transmettre complètement ce que l'utilisateur doit faire dans le moins de mots possible. Si les messages sont longs, vous pouvez les encapsuler sur la longueur des champs.
Juste au-dessus du bouton d'envoi, il pourrait y avoir une liste d'éléments obligatoires sous forme de balises. Chaque balise doit être liée par un lien hypertexte au champ respectif. Au fur et à mesure que l'utilisateur commence à remplir le formulaire depuis le haut, les balises continuent de disparaître. Avant que l'utilisateur n'appuie sur le bouton Soumettre, il peut vérifier si tous les champs obligatoires ont été remplis ou non. S'il a manqué un élément, il peut facilement revenir au champ en appuyant sur la balise appropriée.
Comme la question concerne les résultats d'études réelles, voici un lien vers un étude 2009 sur les différentes variantes des messages de validation par Luke Wroblewski (auteur de Fill in the Blanks).
Il fournit des informations très intéressantes sur la meilleure façon d'afficher des messages de validation, dont certains pourraient vous intéresser. Par exemple,
[SUR LE FLOU] LA MÉTHODE AIDE LES UTILISATEURS À REMPLIR LES FORMULAIRES PLUS RAPIDEMENT Lorsque nous avons utilisé la méthode "après" ([sur le flou]) ..., les participants ont rempli le formulaire de sept à dix secondes plus rapidement que lorsque nous avons utilisé le "pendant" ([sur touches]) et "avant et pendant" respectivement.
En ce qui concerne la position du message d'erreur, l'étude révèle que
PAS FAY LOIN - GARDER LES MESSAGES DE SUCCÈS PROMINENTS À L'EXTÉRIEUR DES CHAMPS DE FORMULAIRES L'affichage de la validation à l'intérieur des champs de formulaires n'a pas apporté d'avantages substantiels. Le positionnement de ces messages était - nécessairement - incohérent. (Bien qu'il soit possible de faire apparaître les messages de validation à l'intérieur des champs du formulaire, il est beaucoup plus difficile de les afficher dans des listes déroulantes standard, nous les avons donc affichés en dehors de ces éléments.) La validation sur le terrain n'était pas plus visible que les messages affichés à l'extérieur les champs.
2- Concernant la visibilité des messages (couleur, etc.), voici n autre article suggérant aux concepteurs UX d'atténuer la gravité de ces messages et de faire en sorte que les utilisateurs se sentent bien dans leur progression (et ne soient pas frustrés par leur pas de progrès)
Entre autres choses, il dit essentiellement que nous devrions utiliser la couleur orange/orange pour les messages d'erreur de formulaire: suffisamment alarmant lorsque les utilisateurs le voient mais moins stimulant physiquement comme rouge (ce qui les fait probablement paniquer).
Je n'ai parcouru aucune étude sur le meilleur endroit pour placer des messages de validation. Cependant, d'un point de vue pratique, je pense que les directives de l'interface utilisateur sont suffisamment proches. Microsoft est bien connu pour avoir effectué de nombreuses recherches de première main dans ses laboratoires d'utilisation des informations contenues dans ses directives. Autant que nous aimons tous faire appel à Microsoft pour certaines mauvaises pratiques d'interface utilisateur, ces pratiques n'ont généralement pas suivi leurs directives de conception d'interface utilisateur :)
Donc ... Microsoft Windows User Experience Interaction Guidelines choisit essentiellement un astérisque à gauche de l'étiquette et une info-bulle avec le message :
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Les lignes directrices font également ressortir certains points intéressants, que j'ai résumés ci-dessous:
- Si la plupart des contrôles sont facultatifs, n'indiquez rien (Manipulez l'entrée requise manquante avec des messages d'erreur. Cette approche réduit l'encombrement.)
- Si la plupart des commandes nécessitent une entrée, indiquez les entrées facultatives avec "(facultatif)" après l'étiquette.
- Si tous les contrôles nécessitent une entrée, placez "Toutes les entrées requises" en haut de la zone de contenu.
- Validez l'entrée tôt, affichez les erreurs près du point d'entrée.
- Utilisez des bulles contextuelles pour les erreurs de saisie utilisateur qui peuvent être détectées immédiatement . * Les bulles ne nécessitent pas d'espace d'écran disponible ni la disposition dynamique requise pour afficher les messages sur place.
- N'afficher qu'un seul ballon à la fois.
- Utilisez des erreurs sur place pour la détection d'erreur retardée (par exemple après avoir soumis un formulaire).
Fait intéressant, il n'y a pas beaucoup de détails dans les Apple Human Interface Guidelines sur ce sujet, mais voici un résumé des points pertinents que j'ai trouvés:
- Validez l'entrée tôt
- Évitez de valider l'entrée après chaque frappe. Une validation fréquente est ennuyeuse.
Encore une fois, même si je me rends compte que ce ne sont pas des "études sur les meilleures pratiques de conception de messages d'erreur", je suis sûr que la recherche a porté sur la formation de ces lignes directrices et en tant qu'outil pratique, elles constituent un excellent point de référence pour ce sujet.
Marquer les champs obligatoires avec * ou marquer quels champs sont facultatifs avec (facultatif) - ce qui dépend le mieux du point de basculement dans le formulaire.
Si vous avez un formulaire long - disons 40 champs (pour exagérer -Je ne suggère pas qu'un formulaire devrait avoir 40 champs sur un écran) et que sur ces 40, 36 sont obligatoires, alors le marquage 36 avec * est à la fois bruyant et devient redondant.
Il est beaucoup plus simple de déclarer en haut que "tous les champs sont obligatoires sauf lorsqu'ils sont indiqués comme facultatifs". Inversement, un formulaire avec relativement peu de champs obligatoires devrait indiquer ceux requis.
En d'autres termes, quels sont ceux que nous devons souligner comme exceptions.
La tendance vers les formulaires Web destinés au public est de demander uniquement les informations requises pour réduire les taux de décrochage, d'où le mouvement vers le marquage facultatif plutôt que obligatoire car ils ont tous tendance à être requis. Ce n'est pas toujours le cas sur les systèmes d'entreprise/d'entreprise, bien qu'il y ait des formulaires approfondis légitimes contenant des champs facultatifs et obligatoires légitimes.
En ce qui concerne la question principale du placement du message d'erreur:
Cela dépend de la disposition de conception du formulaire en ce qui concerne les champs label->.
En supposant que l'étiquette se trouve au-dessus du champ, je placerais le message d'erreur à droite du champ et fournirais autant d'indices visuels que possible, comme mettre en surbrillance la bordure du champ en rouge ainsi que "ce champ est requis" dans rouge.
Les raisons:
1) placement proximal du message d'erreur dans le champ
2) ne rompt pas la proximité et l'association de l'étiquette (ce qui mettrait l'erreur entre l'étiquette et le champ)
3) votre message d'erreur agit comme un panneau indiquant ce qui doit être corrigé (le texte indique comment). En ce sens, vous voulez que votre panneau soit une flèche pointant vers la chose réelle sur laquelle l'utilisateur doit agir, c'est-à-dire le champ, pas l'étiquette.
4) La messagerie de type info-bulle n'est pas une convention bien établie et, comme quelqu'un l'a souligné, court le risque ou couvre des éléments (peu probable que je sois une info-bulle réelle où l'utilisateur prend une action pour ce faire) - c'est aussi peu susceptible d'être bon pour l'accessibilité.
Mon impression initiale des icônes de style de visage + mise en évidence + message est que sa surcharge sensorielle. Je ne sais pas où mon œil devrait se concentrer pour obtenir l'information. Le champ est ce qui doit être corrigé au milieu, mais il y a des informations visuelles en lice pour mon attention avant et après cela, ce qui signifie beaucoup de mouvements oculaires et d'efforts pour que l'utilisateur digère le sens (hypothèse pure, je n'ai jamais exécuté de test utilisateur sur une configuration de formulaire tout à fait la même)
Après avoir lu Web Form Design: Filling in the Blanks et recherché à ce sujet sur le Web, j'ai découvert que les meilleurs sont sous l'entrée ou à droite de l'entrée.
De plus, la présomption que * = Obligatoire n'est pas toujours correcte, certaines personnes ne le savent pas. La façon la plus courante de procéder consiste à expliquer ce qui est * en haut du formulaire. Ou mon préféré est de se débarrasser de tous les champs non obligatoires et d'avoir "tous les champs requis" ou quelque chose de similaire en haut du formulaire.
De bonnes suggestions ont été faites concernant le résumé des champs obligatoires au-dessus du formulaire pour rappel.
Je dirais que le tout premier exemple montré ici est plutôt bon (message d'erreur à côté du fichier lui-même). Vous voudrez peut-être également mettre en évidence le champ en rouge, mais il n'est pas prouvé qu'il soit plus efficace.
En ce qui concerne le problème des boutons radio, je dirais que si vous avez besoin d'un tel message d'erreur pour un bouton radio, cela signifie que le bouton radio n'est pas la bonne option de conception à première vue: en effet, par essence, un le bouton radio DOIT avoir et DEVRAIT SEULEMENT avoir une seule option sélectionnée par défaut. Cela signifie qu'un bouton radio doit toujours présenter une option par défaut sélectionnée, que ce soit une option "aucune". Dans tous les autres cas, vous devriez envisager d'utiliser toute autre option de conception qui correspond à vos besoins (par exemple: cases à cocher si plusieurs options peuvent être sélectionnées, ou menu déroulant ou autre).
Des messages d'erreur alarmants peuvent inquiéter les utilisateurs. L'anxiété des utilisateurs peut amener les utilisateurs à abandonner votre formulaire. Vous n'avez pas besoin de souligner à quel point l'utilisateur a foiré pour le faire réparer.
Messages d'erreur rassurants rendra les utilisateurs plus à l'aise pour corriger leurs erreurs. Le but est d'attirer leur attention et de les guider pour corriger leurs erreurs, et non de leur faire comprendre qu'ils ont fait une énorme erreur.
Malheureusement, il ne semble pas y avoir de moyen "standard" d'afficher une erreur pour un from, ce qui était la question d'origine.
J'ai essayé de chercher une réponse plus détaillée, mais je pense qu'il n'y a pas de solution définitive car il y a tellement de styles de formulaires différents. Les formulaires affichés sur un bureau auront généralement plus d'espace pour le texte d'erreur qu'un formulaire sur un appareil mobile. Récemment, vous devez même penser au système d'exploitation que vous concevez pour l'instant, car le style moderne de Windows 8 (officiellement Metro) a des directives de style spécifiques pour IE. Ajoutez au fait que chaque navigateur moderne a son propre style pour la validation de formulaire HTML5, et standardiser cela devient un gâchis.
Le plus que j'ai pu trouver était un ensemble de directives de Jakob Nielsen ( http://www.useit.com/alertbox/20010624.html ). Ces directives sont très larges, la seule règle explicite étant que vous ne pouvez pas seulement vous fier à la couleur (tourner le texte pour le champ en rouge) car cela peut rendre la lecture difficile pour les utilisateurs handicapés. Les utilisateurs daltoniens ou ceux utilisant des lecteurs d'écran ne pourraient pas différencier le texte.
C'est la seule réservation que j'ai avec la solution de légende également affichée ici. Les utilisateurs handicapés pourraient-ils le lire?
Une solution pourrait être d'adapter un style utilisé par la majorité de vos utilisateurs ciblés (Microsoft, Google ou Apple) et de les suivre.
partageant l'une des approches que j'ai conçues pour un projet très intensif sur les formulaires et qui a été appréciée par l'équipe mais en raison de certaines contraintes, nous n'avons pas pu la construire.
Interaction - au moment où vous déplacez votre curseur, l'interface utilisateur vous montrera un message d'instructions côté client pour le corriger avant de déclencher le bouton de soumission.
Je pense que Google a une solution simple pour les messages d'erreur sur leur formulaire d'inscription; changer la bordure en rouge pour mettre en évidence le champ et un simple message en dessous avec un message en rouge.
Ceci est facile lors de la mise à l'échelle d'une conception sur un petit appareil et est clair et concis.
Je pense que la façon dont Facebook affiche les messages d'erreur est la plus efficace et la plus conviviale. Vérifiez la capture d'écran. Celui-ci ne consomme pas d'espace supplémentaire. L'utilisateur obtient ce qui ne va pas et aussi pour savoir plus en détail, il peut simplement survoler le champ pour savoir pourquoi le champ est obligatoire . 
Je conviens avec d'autres qu'il devrait y avoir un résumé. Qu'il s'agisse d'un compte spécifique ou "Quelque chose s'est mal passé ici. Veuillez examiner toutes les entrées en surbrillance, apporter les modifications nécessaires et soumettre de nouveau le formulaire. Merci."
Ce message peut être en haut ou en bas du formulaire de soumission, mais il doit simplement être visible et se démarquer immédiatement par l'utilisateur, sans défilement. Donc, si la magie javascript peut garder la page vers le bas par le bouton soumettre, tant mieux. C'est là que l'utilisateur était, donc il y a moins de déplacement/clignotement de page.
Ensuite, je pense que la convention la plus simple sera la version "Sous l'étiquette", à partir de vos exemples. L'étiquette est la façon dont l'utilisateur va d'abord s'orienter, et avoir le texte d'erreur juste en dessous est logique, avec un endroit exploitable (le champ), juste en dessous.
J'aime les exemples de "boîte rouge" et les bulles de survol, mais mon interface utilisateur préférée pour cela serait celle où les champs en question sont:
- Marqué avec un texte d'erreur différent de la couleur. L'italique ou le gras avec la couleur est meilleur que la couleur. La couleur unique (avec le rouge en standard) est bonne, mais nous connaissons tous les utilisateurs de daltoniens, non?
- Se démarquer des autres champs d'une manière qui dépasse le texte et la couleur du texte. Il serait très cool que tous les champs "ok" soient grisés un peu, de sorte que l'on puisse voir ceux qui ont besoin d'être modifiés ressortir avec un contraste plus net. Cependant, si l'on voulait éditer l'un de ces champs "ok", un clic devrait quand même les "ouvrir" pour une édition "lumineuse".
Je veux appuyer ce que JonW a dit avec une légère modification. Pour les utilisateurs de lecteurs d'écran, vous souhaiterez résumer les erreurs en haut du formulaire. Ensuite, une fois dans le formulaire, vous souhaitez informer les lecteurs d'écran des erreurs individuelles avant les champs.
Je me suis heurté à ce problème au travail et je voulais trouver une méthode à la fois utilisable et accessible. J'ai trouvé cet article de blog http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ qui a énormément aidé. Étant donné que je travaille dans le développement d'applications pour une université, ce genre de choses est très important.
Il existe des meilleures pratiques - des méthodes qui ont fait leurs preuves - mais rien ne vaut les tests utilisateurs réels. C'est inestimable.
L'exemple repose sur jQuery et le plugin de validation.
Résumer:
- Regroupez toutes les erreurs afin que les utilisateurs de technologie d'assistance (AT) comprennent ce qui ne va pas du point de vue de l'oiseau.
- Placez les erreurs individuelles au-dessus de chaque champ de formulaire afin que AT alerte les utilisateurs de l'erreur avant de remplir le champ.
- Si possible, liez les erreurs résumées aux champs individuels en question, comme dans l'exemple.
Enfin, si vous avez besoin d'un certain format, assurez-vous de mentionner le format dans l'étiquette pour réduire le nombre d'erreurs (et pour rendre la vie plus facile à ceux qui ne voient pas bien ou pas du tout).
Il vaut toujours mieux
- Afficher les messages d'erreur en ligne
- Et définissez le focus sur le premier champ de mandat laissé vide ou le champ contenant des données non valides après la soumission du formulaire.
En cas de validation des données en temps réel/en direct
- Concentrer le champ en rouge et afficher un message d'erreur en ligne
En cas de validation côté serveur, par exemple lorsque js est désactivé -
- Toujours afficher un message d'erreur en ligne avec le focus sur le champ vide ou le champ avec des données non valides
pratique habituelle -
- La validation des données doit être en temps réel (infobulle suggérant le bon format lorsque l'utilisateur entre des données invalides)
- La vérification du champ de mandat doit avoir lieu lors de la soumission du formulaire - Cela permet d'éviter une trop grande intervention du système sur la saisie des données utilisateur)
La façon traditionnelle de marquer les champs de mandat avec "*" est toujours la meilleure