Formulaires accessibles : labels & erreurs

Les formulaires sont souvent le point de rupture : si l'utilisateur ne comprend pas l'erreur ou ne sait pas où corriger, il abandonne. Cette checklist vous aide à passer les validations RGAA les plus fréquentes.

1) Labels explicites : toujours visibles pour l'utilisateur

  • Chaque champ doit avoir un label associé (via for / id ou élément englobant).
  • Le label ne doit pas être remplacé uniquement par un placeholder (placeholder ≠ label).
  • Les labels doivent décrire l'attendu (“Email professionnel”, “Nom de famille”, etc.).

2) Types d'entrée et attributs d'aide

  • Utilisez des types adaptés (email, tel, password, etc.).
  • Préférez les attributs d'aide (par exemple autocomplete) pour réduire la friction.
  • Les instructions doivent être associées au champ (via aria-describedby quand pertinent).

3) Erreurs : compréhensibles, localisées, actionnables

Une bonne erreur répond à 3 questions : “Qu'est-ce qui ne va pas ?”, “Où ?”, “Que faire ?”.

  • Les messages d'erreur sont liés au champ concerné.
  • L'erreur ne dépend pas uniquement de la couleur (icône/texte + lien vers le champ).
  • La correction est indiquée (ex : format attendu, exemple, contrainte).

4) Feedback : immédiat et lisible au clavier

  • Après validation, le focus et/ou l'annonce amène l'utilisateur à la zone d'erreur.
  • Les contrôles d'action (boutons “Valider”, “Continuer”) restent atteignables.
  • Les messages sont annoncés de façon appropriée (ex : régions aria-live selon le cas).

5) UX : éviter les pièges classiques

  • Les champs requis doivent être explicites.
  • Les choix (radios/checkboxes) doivent être groupés avec une légende / contexte clair.
  • Les messages “globales” (résumé d'erreurs) complètent les messages “par champ”.

Checklist rapide (à valider avant publication)

  • Tous les champs ont un label explicite.
  • Les instructions sont associées au bon champ.
  • Les erreurs indiquent le champ concerné + la correction attendue.
  • Le focus n'est pas “perdu” après soumission.
  • Tout fonctionne au clavier (labels, navigation, validation).

FAQ rapide

Placeholder seul suffit-il pour un champ ?

En général non. Le placeholder peut aider, mais il ne remplace pas un label associé (le label doit rester compréhensible pendant la saisie).

Faut-il mettre aria-invalid ?

Souvent oui, quand c'est pertinent pour annoncer l'état d'erreur. Le plus important reste : message lié au champ + feedback compréhensible.

Comment tester simplement un formulaire accessible ?

Test clavier : Tab=>focus sur chaque champ, soumission volontairement invalide, vérification que l'erreur est annoncée et que le focus pointe vers la correction.

Si vous voulez un parcours complet : commencez par la checklist RGAA avant publication, puis détaillez chaque thématique (images, clavier, formulaires).