Qu'est-ce que les formulaires accessibles ?

Qu'est-ce que les formulaires accessibles ?

Un formulaire accessible peut être compris, parcouru et rempli par tout le monde, y compris par les personnes qui utilisent un clavier, un lecteur d'écran, la commande vocale, le zoom ou un contacteur. Concrètement : chaque champ a une étiquette programmatique, les champs liés sont regroupés, les erreurs sont identifiées par du texte avec une suggestion de correction, et tout fonctionne sans souris.

Ce qu'il faut soigner

• Étiquettes. Utilisez un vrai élément label, relié au champ par for et id. Le critère WCAG 3.3.2 (niveau A) exige des étiquettes ou des instructions dès que le contenu accepte une saisie, et 1.3.1 (niveau A) exige que la relation soit déterminable par programme. Un placeholder n'est pas une étiquette : il disparaît dès que l'on tape.
• Regroupement. Regroupez les contrôles liés, comme les boutons radio, dans un fieldset avec un legend, comme le décrivent les techniques du W3C pour 1.3.1.
• Finalité de la saisie. Ajoutez la bonne valeur autocomplete (given-name, email, tel) pour que navigateurs et technologies d'assistance sachent ce que demande un champ (1.3.5, niveau AA).
• Erreurs. Identifiez le champ en erreur et décrivez le problème par du texte (3.3.1, niveau A), puis proposez une suggestion quand elle est connue (3.3.3, niveau AA). La couleur seule ne suffit pas.
• Ne faites pas ressaisir. Les informations déjà saisies dans le même processus doivent être préremplies ou sélectionnables (3.3.7 Saisie redondante, niveau A, nouveauté des WCAG 2.2).
• Connexion. Ne bloquez ni le collage ni les gestionnaires de mots de passe : le critère 3.3.8 Authentification accessible (niveau AA) considère comme un obstacle d'imposer de mémoriser ou de recopier un mot de passe sans alternative.
• Nom, rôle, valeur. Les contrôles personnalisés doivent exposer la même chose aux technologies d'assistance (4.1.2, niveau A). Voir les composants de saisie personnalisés et ARIA, en privilégiant d'abord les éléments natifs.

Exemple

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email"
       autocomplete="email" aria-describedby="email-err">
<p id="email-err">Saisissez une adresse comme nom@exemple.fr</p>

L'étiquette est annoncée avec le champ, l'aide est lue grâce à aria-describedby et le navigateur peut remplir automatiquement. Vérifiez que chaque contrôle est atteignable et dans un ordre logique : voir l'ordre de navigation au clavier.

Erreurs fréquentes

• Le texte du placeholder comme seule étiquette.
• Un message du type « Saisie invalide » qui n'indique ni le champ ni la correction, ou une bordure rouge sans texte.
• Des champs obligatoires signalés uniquement par la couleur.
• Le collage désactivé dans les champs de mot de passe ou de confirmation d'e-mail.
• Des listes déroulantes et sélecteurs de date faits de div sans gestion du clavier ni rôle.

Tester et surveiller

Les tests d'accessibilité automatisés repèrent de façon fiable les étiquettes et noms manquants, ce qui en fait un bon contrôle de non-régression pour les formulaires. Ils ne peuvent pas juger si un message d'erreur est compréhensible ou si l'ordre de tabulation est logique : parcourez aussi le formulaire à la touche Tab et avec un lecteur d'écran. Le cadre général est WCAG. La surveillance de la vitesse des pages de LoadFocus enregistre à intervalles planifiés la catégorie Accessibilité de Lighthouse des pages qui contiennent vos formulaires, afin qu'une baisse apparaisse comme une tendance. C'est un suivi, pas un audit d'accessibilité. Pour les outils, voir ce panorama des outils de test d'accessibilité.

Questions fréquentes : formulaires accessibles

Un placeholder suffit-il comme étiquette ?

Non. Les placeholders disparaissent à la saisie, ont souvent un contraste faible et ne sont pas un nom accessible fiable. Utilisez un élément label visible.

Quels critères WCAG concernent les formulaires ?

Surtout 1.3.1, 1.3.5, 3.3.1, 3.3.2, 3.3.3, 3.3.7, 3.3.8 et 4.1.2, ainsi que l'utilisation au clavier (2.1.1) et la visibilité du focus.

Faut-il utiliser ARIA dans les formulaires ?

Seulement quand le HTML natif ne suffit pas. Un label, un fieldset et un input natifs donnent déjà le bon nom, le bon rôle et le bon état. ARIA sert pour les widgets personnalisés et pour relier aides et erreurs aux champs.

Comment afficher les erreurs ?

Indiquez par du texte quel champ pose problème et comment le corriger, placez le message près du champ et, après un envoi échoué, déplacez le focus vers un récapitulatif des erreurs ou vers le premier champ invalide.

Un outil peut-il vérifier l'accessibilité d'un formulaire ?

Il repère les étiquettes et noms manquants, mais pas un texte peu clair ni un ordre confus. Associez-le à des tests manuels au clavier et au lecteur d'écran.