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.
Capture d'un formulaire, champ "Votre nom" suivi de la mention "Veuillez renseigner votre nom", champ "Votre courriel" suivi de la mention "Veuillez respecter le format du couriel (exemple@domaine.fr)"
Formulaire précédé d'une liste indiquant "Veuillez renseigner votre nom" et "Veuillez respecter le format du courriel (exemple@domaine.fr).
Dans les deux exemples ci-dessus, les messages d’erreur sont explicites et accompagnés de suggestions de correction (format de courriel).

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

  • Par Mickael, le 10 octobre 2024 à 15h57.

    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 ?

    Répondre

    • Par Romain Desjardins (Atalan), le 11 octobre 2024 à 4h27.

      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 label du champ, soit via l’utilisation des attributs aria-describedby et id (voir la fiche AcceDe Web associée pour un exemple de code).

      Belle journée,
      Romain

      Répondre

  • Par Baptiste, le 28 juin 2024 à 15h33.

    Merci pour ces précisions.

    Répondre

  • Par Baptiste, le 19 juin 2024 à 10h59.

    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.

    Répondre

    • Par Romain Desjardins (Atalan), le 25 juin 2024 à 18h25.

      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

      Répondre

  • Par Raphaelle, le 25 avril 2024 à 14h27.

    Bonjour, vos messages d’erreur ne me semblent pas accessibles puisqu’ils sont uniquement indiqués par la couleur

    Répondre

    • Par Romain Desjardins (Atalan), le 26 avril 2024 à 2h55.

      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

      Répondre

Ajouter un commentaire

Tous les champs sont obligatoires.

Haut de page