Critères en pratique
Formulaires accessibles : étiquettes, erreurs et aide à la saisie
Le formulaire concentre les critères RGAA les plus exigeants. Étiquetage, regroupement, messages d'erreur, champs obligatoires : la check-list qui évite les non-conformités.
Le point de passage obligé
Un formulaire est l'endroit où l'utilisateur agit : commander, contacter, s'inscrire, payer. C'est aussi la zone où une non-conformité ne dégrade pas l'expérience, elle la bloque. Le RGAA y consacre une thématique entière.
L'étiquetage
Chaque champ doit avoir une étiquette visible et reliée programmatiquement — un label avec for pointant vers l'id du champ. Le placeholder ne remplace pas l'étiquette : il disparaît à la saisie, et son contraste est presque toujours insuffisant.
Les champs de même nature doivent être regroupés : fieldset et legend pour un groupe de boutons radio ou de cases à cocher.
Les erreurs de saisie
- le message d'erreur doit être textuel — pas seulement une bordure rouge ;
- il doit identifier le champ concerné et dire comment corriger ;
- il doit être annoncé aux technologies d'assistance, pas seulement affiché ;
- le focus doit être amené sur la première erreur, ou le résumé d'erreurs doit être atteignable.
> « Champ invalide » ne suffit pas — Un message utile dit ce qui est attendu : « La date doit être au format JJ/MM/AAAA ». C'est autant un critère RGAA qu'une bonne pratique de conversion.
Les champs obligatoires
L'astérisque seul ne fait pas l'affaire : il doit être expliqué en début de formulaire, et l'obligation doit être portée dans le code (required), pas uniquement par un symbole visuel.
L'aide à la saisie
Format attendu, exemple, contraintes de mot de passe : ces indications doivent être reliées au champ et disponibles avant la saisie, pas seulement après l'erreur. Et pour les données personnelles, l'attribut autocomplete évite une ressaisie pénible.
---
À lire aussi