6.6. Prévoir des messages d’erreur explicites et des suggestions de correction
Chaque fois qu’un formulaire est susceptible de renvoyer des erreurs, les éléments suivants doivent être prévus :
- Des messages d’erreur explicites.
- Des suggestions de correction, si nécessaire.
Les messages d’erreur doivent être explicites. C’est-à-dire qu’à la lecture du seul message d’erreur :
- Le champ concerné doit être identifiable.
- La cause de l’erreur doit être compréhensible.
- Des suggestions de correction doivent être prévues dès lors qu’une erreur est due à un format de saisie incorrect.
Attention
Les messages d’erreur ne doivent pas disparaître automatiquement.
Ces derniers doivent disparaître seulement sur action manuelle (croix de fermeture, affichage d’une nouvelle page, nouvel envoi du formulaire, etc.).
7 commentaires
-
Petite question concernant la rédaction des messages d’erreurs.
Dans le cas ou un champ obligatoire n’as pas été remplis par l’utilisateur, le libellé de l’erreur peut-il être générique ?
exemple :
pour un champ nom et un champ de numéro de téléphone non remplit, est ce qu’un libellé sous chaque champ générique de type « ce champ est obligatoire » est-il accessible ?-
Bonjour Mickael,
Oui, c’est tout à fait possible d’avoir une erreur générique lorsqu’un champ n’a pas été rempli.
Cependant, le message d’erreur devra bien être lié à son champ pour être accessible, c’est-à-dire soit directement positionné dans la balise
labeldu champ, soit via l’utilisation des attributsaria-describedbyetid(voir la fiche AcceDe Web associée pour un exemple de code).Belle journée,
Romain
-
-
Merci pour ces précisions.
-
Bonjour,
Dans le cas où l’on affiche les erreurs directement en dessous des champs, chaque erreur doit-elle être considérée comme « message de statut » (point 7.5 du RGAA) ?
Cela implique l’ajout du role alert sur tous les messages.-
Bonjour Baptiste,
Cela va dépendre si les erreurs sont affichées dynamiquement sur la page ou si elles apparaissent lors d’un rechargement de page (après avoir actionné le bouton de soumission du formulaire par exemple).
Dans le cas où les erreurs sont affichées dynamiquement (lorsque le focus sort du champ et que l’erreur apparaît directement, ou lors d’une soumission de formulaire sans rechargement de page), ces erreurs sont bien à considérer comme des messages de statut. Le glossaire mentionne d’ailleurs bien ce cas (« Existence de message d’erreur ») dans la définition d’un message de statut.
Je pense que nous allons modifier cette fiche pour ajouter ce cas particulier qui devient de plus en plus fréquent dans les formulaires, merci pour cette remarque !
Bien à vous,
Romain
-
-
Bonjour, vos messages d’erreur ne me semblent pas accessibles puisqu’ils sont uniquement indiqués par la couleur
-
Bonjour Raphaelle,
Il n’y a pas de problème à utiliser de la couleur pour les messages d’erreur, tant que le message est présent, suffisamment contrasté et indique qu’une erreur est présente et doit être corrigée dans le champ. La couleur n’est donc pas l’unique façon de comprendre l’information, on pourrait s’en passer, le texte serait toujours présent.
Si en revanche, il n’y a pas de texte d’erreur mais simplement un changement de couleur sur le champ en erreur, alors effectivement seule la couleur permettrait de comprendre l’information, ce qui génèrerait un problème d’accessibilité.
Bien à toi,
Romain
-
