WCAG A Votre équipe + Prestataire Moyen

Vos formulaires signalent-ils les champs obligatoires et le format attendu avant la saisie — pas uniquement en message d'erreur après ?

Critère officiel 11.10 — Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?

Pourquoi c'est important

Un formulaire qui n'indique le format attendu qu'après erreur oblige l'utilisateur à essuyer un échec avant de comprendre les règles. Pour une personne âgée peu à l'aise avec le numérique, chaque message d'erreur inattendu est décourageant et peut conduire à l'abandon de la démarche en ligne.

Exemples concrets

Ce qui est conforme

Le formulaire de contact indique « * Champ obligatoire » avec une note explicative en haut. Le champ téléphone affiche « Format attendu : 06 12 34 56 78 » sous l'étiquette. Le champ date affiche « JJ/MM/AAAA ». L'utilisateur connaît les règles avant de commencer à saisir.

Ce qui pose problème

Le formulaire affiche uniquement des astérisques sans explication sur les champs obligatoires. Le champ téléphone ne précise aucun format. Après soumission, le message d'erreur indique « Champ invalide » — sans préciser lequel ni pourquoi ni comment corriger.

Comment agir

Trois règles à appliquer à tout formulaire : 1) Signaler les champs obligatoires avec un texte lisible (« obligatoire » ou note en haut de formulaire). 2) Indiquer le format attendu avant la saisie pour tous les champs avec contrainte (téléphone, date, code postal, numéro de dossier). 3) Ne jamais laisser une contrainte invisible — l'utilisateur doit connaître les règles avant de commencer.

Règles clés

  • Chaque champ en erreur doit avoir aria-invalid="true" mis à jour dynamiquement.
  • Le message d'erreur doit être lié au champ via aria-describedby — il sera alors annoncé automatiquement quand l'utilisateur focus le champ.
  • Si les erreurs sont injectées dynamiquement sans rechargement de page, utiliser role="alert" ou aria-live="polite" pour les annoncer automatiquement.
  • Le message d'erreur doit décrire l'erreur ET suggérer la correction : 'Adresse e-mail invalide — vérifiez le format nom@domaine.fr' plutôt que 'Champ invalide'.
  • À la soumission avec erreurs : déplacer le focus sur le premier champ en erreur, ou sur un résumé des erreurs en haut du formulaire.

Erreurs fréquentes

  • Erreur signalée uniquement par couleur (bordure rouge) sans message textuel ni icône
  • Message d'erreur global ('Le formulaire contient des erreurs') sans identification des champs concernés
  • Message d'erreur non lié au champ via aria-describedby — l'utilisateur de lecteur d'écran ne l'entend pas au focus du champ
  • aria-invalid absent ou non mis à jour dynamiquement
  • Message d'erreur injecté dynamiquement sans live region — non annoncé automatiquement
  • Erreur visible uniquement après rechargement de la page sans replacement du focus sur le premier champ en erreur

Exemples de code

erreur par couleur seule, non liée

✗ Non conforme
<!-- Après soumission invalide -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email"
  style="border-color: red;" value="prenom@">
<p style="color: red;">Format invalide</p>

L'erreur est signalée par la couleur rouge (critère 3.1) et par un message non lié au champ. aria-invalid est absent. Le lecteur d'écran au focus du champ n'annonce pas l'erreur.

erreur accessible avec aria-invalid et aria-describedby

✓ Conforme
<!-- Après soumission invalide -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email"
  aria-invalid="true"
  aria-describedby="email-erreur"
  value="prenom@">
<p id="email-erreur" role="alert">
  Adresse e-mail invalide — vérifiez le format :
  nom@domaine.fr
</p>

aria-invalid="true" indique l'état d'erreur. aria-describedby lie le message au champ — le lecteur d'écran l'annonce au focus. role="alert" annonce immédiatement le message à l'injection. La correction est suggérée.

focus sur le premier champ en erreur à la soumission

✓ Conforme
formEl.addEventListener('submit', e => {
  e.preventDefault();
  const erreurs = valider(formEl);
  if (erreurs.length) {
    // Marquer les champs
    erreurs.forEach(({ champ, message, idMsg }) => {
      champ.setAttribute('aria-invalid', 'true');
      champ.setAttribute('aria-describedby', idMsg);
      document.getElementById(idMsg).textContent = message;
    });
    // Déplacer le focus sur le premier champ en erreur
    erreurs[0].champ.focus();
  }
});

À la soumission avec erreurs, le focus est déplacé sur le premier champ invalide. L'utilisateur de lecteur d'écran entend immédiatement : le nom du champ, son état invalide, et le message d'erreur associé via aria-describedby.

Référence WCAG : 3.3.1, 3.3.2

La lettre de l'Atelier A11Y

Ressources pédagogiques, critères RGAA commentés et retours de terrain : une lettre mensuelle pour progresser sur l'accessibilité numérique, sans jargon.

  • Nouveaux articles et ressources pédagogiques
  • Critères RGAA décortiqués avec des exemples concrets
  • Bonnes pratiques et retours d'expérience terrain
S'abonner à la newsletter (s'ouvre dans un nouvel onglet)

Gratuit. Désabonnement possible à tout moment.