Bonnes pratiques
Formulaire accessible : étiquettes, erreurs et saisie automatique (RGAA 11)
Étiquettes, champs obligatoires, messages d’erreur, regroupements, autocomplete : rendre un formulaire accessible selon le RGAA, exemples HTML à l’appui.
Par un auditeur RGAA d’AraspeedPublié le 3 min de lecture
Un formulaire inaccessible, c’est une commande qui n’aboutit pas, un contact qui n’arrive jamais, une démarche abandonnée. C’est aussi l’un des thèmes les plus lourds du RGAA : 13 critères, du simple libellé jusqu’à la gestion des erreurs. Bonne nouvelle, l’essentiel tient en quelques règles de HTML.
1. Chaque champ a une étiquette (critère 11.1)
C’est la règle de base : un champ sans étiquette est annoncé « zone de saisie » par un lecteur d’écran, sans dire quoi écrire. L’étiquette se relie au champ par for et id :
<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email">
Le placeholder ne remplace pas l’étiquette : il disparaît dès qu’on tape, il est souvent trop pâle, et tous les lecteurs d’écran ne le lisent pas.
Si le design impose un champ sans étiquette visible (une barre de recherche avec une loupe), utilisez aria-label, ou une étiquette masquée visuellement mais présente dans le code.
2. L’étiquette est claire et proche du champ (critères 11.2 et 11.4)
« Champ 1 » ou « Valeur » ne disent rien. L’étiquette doit permettre de remplir le champ sans contexte : « Date de naissance », « Numéro de commande ». Elle doit aussi être accolée au champ, pour qu’une personne qui utilise un zoom important la voie en même temps que le champ.
Si l’étiquette visible et le nom accessible diffèrent (aria-label), le nom accessible doit contenir le texte visible : une personne qui pilote son ordinateur à la voix dit ce qu’elle voit.
3. Les champs liés sont regroupés (critères 11.5 à 11.7)
Des boutons radio, des cases à cocher sur une même question, ou les champs d’une adresse forment un groupe. On les regroupe avec fieldset, et la question devient la legend :
<fieldset>
<legend>Mode de livraison</legend>
<input type="radio" id="domicile" name="livraison" value="domicile">
<label for="domicile">À domicile</label>
<input type="radio" id="relais" name="livraison" value="relais">
<label for="relais">En point relais</label>
</fieldset>
Sans legend, le lecteur d’écran annonce « À domicile, bouton radio » sans dire à quelle question il répond.
4. Les champs obligatoires et les formats sont indiqués (critère 11.10)
Avant la saisie, l’utilisateur doit savoir :
- quels champs sont obligatoires, avec une mention explicite (un astérisque expliqué en haut du formulaire, ou le mot « obligatoire ») ;
- quel format est attendu pour les champs contraints : date, téléphone, code postal.
<p>Les champs marqués d’un * sont obligatoires.</p>
<label for="naissance">Date de naissance *</label>
<input id="naissance" name="naissance" required aria-describedby="naissance-format">
<p id="naissance-format">Format attendu : JJ/MM/AAAA</p>
aria-describedby fait lire l’indication de format en même temps que l’étiquette.
5. Les erreurs sont claires et corrigibles (critères 11.10 et 11.11)
Un message d’erreur accessible :
- est en texte, pas seulement une bordure rouge (la couleur seule ne suffit pas) ;
- est relié au champ par
aria-describedby, avecaria-invalid="true"sur le champ ; - explique comment corriger : « Saisissez une adresse e-mail valide, par exemple nom@domaine.fr » plutôt que « Champ invalide ».
<label for="email">Adresse e-mail *</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-erreur">
<p id="email-erreur">Saisissez une adresse e-mail valide, par exemple nom@domaine.fr.</p>
Sur un formulaire long, ajoutez en haut un récapitulatif des erreurs, avec un lien vers chaque champ, et mettez « Erreur » au début du titre de la page : c’est la première chose qu’entend un utilisateur de lecteur d’écran quand la page se recharge.
6. La saisie automatique est possible (critère 11.13)
Pour les champs qui concernent l’utilisateur (nom, e-mail, téléphone, adresse), l’attribut autocomplete permet au navigateur de les remplir. C’est un gain pour tout le monde, et une aide décisive pour les personnes qui ont des troubles moteurs ou cognitifs :
<input id="nom" name="nom" autocomplete="name">
<input id="email" name="email" type="email" autocomplete="email">
<input id="cp" name="cp" autocomplete="postal-code">
7. Le bouton dit ce qu’il fait (critère 11.9)
« Envoyer » ou « Valider » passent, mais « Envoyer le message » ou « Payer 49 € » sont plus clairs, surtout quand la page compte plusieurs formulaires.
Ce qu’il faut retenir
| À faire | Critère |
|---|---|
| Une étiquette reliée à chaque champ | 11.1 |
| Une étiquette claire et accolée | 11.2, 11.4 |
fieldset et legend pour les groupes |
11.5, 11.6, 11.7 |
| Champs obligatoires et formats annoncés | 11.10 |
| Erreurs en texte, reliées, avec une solution | 11.10, 11.11 |
autocomplete sur les données personnelles |
11.13 |
| Un intitulé de bouton explicite | 11.9 |
Tester vos formulaires
Araspeed vérifie gratuitement les étiquettes manquantes (11.1), les regroupements sans légende (11.5, 11.6) et l’attribut autocomplete des champs personnels (11.13) sur la page rendue. La pertinence des étiquettes et des intitulés de boutons est jugée par l’analyse approfondie de l’offre Pro. Pour le reste du thème, voir les critères du thème Formulaires. Pensez aussi au contraste du texte d’aide et des placeholders : c’est l’objet de notre article sur la règle du 4,5:1.