Formulaires accessibles : étiquettes, erreurs, aide
Le formulaire est l'endroit où un service en ligne réussit ou échoue. C'est aussi là que se concentrent les obstacles pour les personnes handicapées. Trois sujets règlent l'essentiel : les étiquettes, les erreurs et l'aide.
Dans les audits d’accessibilité, les formulaires reviennent presque toujours parmi les principales sources de non-conformité. Ce n’est pas un hasard : c’est là que l’usager doit agir, comprendre ce qu’on lui demande, corriger ses erreurs. Un champ sans étiquette lisible par un lecteur d’écran, une erreur signalée seulement en rouge, un code de vérification qu’il faut recopier en trente secondes, et la démarche s’arrête. Des formulaires accessibles reposent sur trois choses : des étiquettes, des erreurs utiles et une aide au bon moment.
Les étiquettes : nommer chaque champ
Chaque champ doit avoir une étiquette visible, placée à proximité, et reliée au champ dans le code. Cette liaison permet au lecteur d’écran d’annoncer « Date de naissance, zone de saisie » quand l’utilisateur arrive sur le champ, et elle agrandit la zone cliquable, ce qui aide aussi les personnes qui ont du mal à viser.
<label for="naissance">Date de naissance (jj/mm/aaaa)</label>
<input id="naissance" name="naissance" autocomplete="bday">Quelques règles complètent ce principe :
Le texte indicatif ne remplace pas l’étiquette. Il disparaît à la saisie, et la personne qui revient sur le champ ne sait plus ce qu’elle devait y mettre.
Les groupes de champs ont un titre. Pour des boutons radio (« Situation familiale ») ou un ensemble de champs liés (une adresse), l’élément fieldset et sa légende donnent le contexte que l’étiquette de chaque option ne porte pas.
Le nom accessible contient le texte visible. Si un bouton affiche « Envoyer », son nom pour les technologies d’assistance doit contenir « Envoyer » : un utilisateur de commande vocale dira « cliquer sur Envoyer » et doit être compris (critère 2.5.3 des WCAG).
Les champs courants déclarent leur finalité. L’attribut autocomplete (nom, courriel, téléphone, adresse) permet au navigateur de proposer les valeurs déjà connues. C’est une exigence des WCAG (critère 1.3.5), et un gain considérable pour les personnes qui ont des difficultés motrices ou cognitives.
Les erreurs : dire quoi, où, et comment corriger
Un message « Le formulaire contient des erreurs », affiché en haut de la page en rouge, n’aide personne. Un utilisateur aveugle ne voit pas le rouge, un utilisateur daltonien peut ne pas le distinguer, et aucun ne sait quel champ corriger.
Une erreur bien signalée remplit quatre conditions. Elle est indiquée en texte, pas seulement par la couleur ou une icône. Elle est placée près du champ concerné et reliée à lui dans le code, pour que le lecteur d’écran la lise en même temps que l’étiquette. Elle explique comment corriger : « Saisissez la date au format jj/mm/aaaa, par exemple 04/09/1987 » plutôt que « Format invalide ». Et elle est annoncée : à l’envoi, un récapitulatif en haut du formulaire, qui reçoit le focus et liste les erreurs avec des liens vers chaque champ.
<label for="courriel">Adresse électronique</label>
<input id="courriel" type="email" aria-invalid="true" aria-describedby="err-courriel">
<p id="err-courriel">L'adresse doit contenir @, par exemple [email protected]</p>Effacer tout le formulaire après une erreur. La personne qui a mis dix minutes à le remplir, avec un lecteur d’écran ou une commande vocale, doit tout recommencer. Les valeurs saisies doivent être conservées, sauf les mots de passe.
Pour les démarches qui engagent l’usager (juridiques, financières, ou qui modifient des données), les WCAG demandent en outre de pouvoir vérifier, corriger ou annuler avant l’envoi définitif : une page de récapitulatif fait l’affaire (critère 3.3.4).
L’aide : prévenir plutôt que corriger
La meilleure erreur est celle qui n’arrive pas. L’aide doit être disponible avant la saisie, pas seulement après l’échec.
Annoncer le format attendu dans l’étiquette ou juste en dessous, avec un exemple. Mieux : accepter plusieurs formats (avec ou sans espaces pour un numéro de téléphone) plutôt que de rejeter ce qui est compréhensible.
Indiquer les champs obligatoires clairement et au début, et marquer les champs dans le code avec l’attribut required.
Ne pas faire ressaisir. Une information déjà donnée dans le même parcours (adresse de livraison identique à celle de facturation) doit être reprise automatiquement ou proposée à la sélection. C’est l’un des critères ajoutés par les WCAG 2.2 en 2023 (critère 3.3.7).
Ne pas imposer d’épreuve cognitive pour se connecter. Recopier un code déformé, résoudre une énigme ou mémoriser un mot de passe sans pouvoir le coller sont des obstacles majeurs pour beaucoup de personnes. Les WCAG 2.2 demandent qu’une alternative existe : autoriser le copier-coller et les gestionnaires de mots de passe, proposer un lien de connexion par courriel ou une autre méthode (critère 3.3.8).
Laisser le temps. Une session qui expire au bout de dix minutes sans avertissement pénalise ceux qui saisissent lentement. Prévenir avant l’expiration et permettre de prolonger.
Écrire simplement. Une étiquette en langage administratif (« Qualité du déclarant ») est un obstacle pour tout le monde. Le langage clair est la première des aides.
Les critères concernés
| Sujet | Critères WCAG 2.2 | Thème RGAA 4.1.2 |
|---|---|---|
| Étiquettes et regroupements | 1.3.1, 2.4.6, 2.5.3, 3.3.2, 4.1.2 | Thème 11 (formulaires) |
| Finalité des champs | 1.3.5 | Thème 11 |
| Identification et suggestion d’erreurs | 3.3.1, 3.3.3 | Thème 11 |
| Prévention des erreurs pour les démarches engageantes | 3.3.4 | Thème 11 |
| Messages de statut | 4.1.3 | Thème 7 (scripts) |
| Saisie redondante et authentification | 3.3.7, 3.3.8 (nouveaux en 2.2) | Non encore repris dans le RGAA 4.1.2 |
Tester en un quart d’heure
Avant tout audit, trois tests simples révèlent l’essentiel des problèmes d’un formulaire. Le remplir entièrement au clavier, sans souris, en vérifiant que l’on voit toujours où se trouve le focus. Le soumettre vide, puis avec des erreurs volontaires, et lire les messages : disent-ils quoi corriger ? Enfin, l’écouter avec un lecteur d’écran (NVDA sous Windows, VoiceOver sur Mac et iPhone, tous deux gratuits) : chaque champ est-il annoncé avec son étiquette et ses consignes ? Notre guide pour tester la navigation au clavier détaille la première étape.
Pour corriger un parc de formulaires existants, ou former une équipe de développement à ces pratiques, voir notre offre Accessibilité et inclusion.
Questions fréquentes
Le texte indicatif dans le champ (placeholder) peut-il remplacer l'étiquette ?
Non. Il disparaît dès que l'on commence à taper, il est souvent trop peu contrasté, et certains lecteurs d'écran ne le restituent pas de façon fiable. Il peut compléter une étiquette visible, jamais la remplacer.
Faut-il valider les champs pendant la saisie ou à l'envoi ?
Les deux sont possibles. La validation à l'envoi, avec un récapitulatif des erreurs en haut du formulaire et un message près de chaque champ, est la plus robuste. La validation en direct doit attendre que la personne ait quitté le champ, pour ne pas annoncer des erreurs pendant qu'elle tape.
Le signe astérisque suffit-il à indiquer un champ obligatoire ?
Seulement si sa signification est expliquée au début du formulaire et si le champ porte aussi l'attribut required ou aria-required. Mieux vaut encore écrire « obligatoire » dans l'étiquette, ou n'indiquer que les champs facultatifs quand ils sont peu nombreux.