« Chaque champ de formulaire doit avoir une étiquette » : le critère 11.1 du Référentiel général d’amélioration de l’accessibilité (RGAA 4.1) semble d’une évidence absolue. Pourtant, c’est l’un des points d’échec les plus fréquents sur les formulaires de saisine construits pour des sites de mairies, d’intercommunalités ou d’établissements publics. Un placeholder n’est pas un label. Un texte flottant au-dessus du champ qui disparaît à la saisie n’est pas un label. Un module de formulaire conçu pour ce type de client doit traiter ces critères comme des contraintes de conception, pas comme une passe de retouche a posteriori.
Le RGAA s’impose légalement aux sites de l’État, des collectivités territoriales, des établissements publics et, depuis les évolutions récentes de la réglementation, à un périmètre plus large d’organismes chargés d’une mission de service public. Un module de formulaire livré à ce type de client sans être pensé nativement pour ce référentiel expose l’organisme commanditaire à un constat de non-conformité publié, avec les conséquences d’image que cela implique.
Structurer le formulaire avec les bonnes balises sémantiques
Le point de départ n’est pas visuel, il est structurel. Chaque champ doit être associé à un <label> explicite via l’attribut for, et les groupes de champs liés (une adresse complète, un choix de créneau) doivent être regroupés dans un <fieldset> avec une <legend> qui décrit le groupe :
<fieldset>
<legend>Coordonnées du demandeur</legend>
<label for="nom">Nom</label>
<input type="text" id="nom" name="nom" required aria-required="true">
</fieldset>
Cette structure n’est pas cosmétique : un lecteur d’écran annonce la légende du fieldset avant chaque champ qu’il contient, ce qui donne un contexte indispensable à un utilisateur qui navigue au clavier sans repère visuel de mise en page.
Rendre les erreurs de validation perceptibles par tous
Le second point d’échec classique concerne la gestion des erreurs. Un champ obligatoire non rempli qui se contente de passer en bordure rouge ne communique rien à un utilisateur non-voyant ni à un utilisateur en situation de daltonisme sévère. Le message d’erreur doit être un texte explicite, associé au champ via aria-describedby, et annoncé dynamiquement via une zone aria-live :
<input type="email" id="email" name="email" aria-describedby="erreur-email" aria-invalid="true">
<span id="erreur-email" role="alert">
L'adresse e-mail saisie n'est pas valide.
</span>
L’attribut role="alert" déclenche une annonce immédiate par les technologies d’assistance dès que le contenu de l’élément change, sans nécessiter un changement de focus qui perturberait la navigation en cours.
Le cas des champs conditionnels
Un formulaire de saisine de collectivité comporte souvent des champs qui n’apparaissent que selon une réponse précédente (par exemple : « Avez-vous un numéro d’allocataire ? »). Ce type de logique conditionnelle, si elle est gérée uniquement en JavaScript côté client sans annonce ARIA, rend l’apparition du nouveau champ invisible pour un utilisateur de lecteur d’écran qui ne revient pas systématiquement en haut du document après chaque interaction.
Une checklist avant publication
Voici les points à vérifier systématiquement avant de livrer un module de formulaire à un client du secteur public :
- Chaque champ possède un label visible et associé, jamais un simple placeholder en guise d’étiquette.
- La navigation complète du formulaire est possible au clavier seul, dans un ordre de tabulation logique.
- Les messages d’erreur sont explicites, associés au champ concerné, et annoncés dynamiquement.
- Le contraste des textes et des bordures de champs respecte un ratio minimal de 4,5:1.
- Le bouton de soumission a un intitulé clair (« Envoyer ma demande », pas « Valider » sans contexte).
Documenter la conformité, pas seulement l’appliquer
Le RGAA impose également une obligation documentaire : une déclaration d’accessibilité publiée sur le site, mentionnant le taux de conformité et un schéma pluriannuel d’amélioration. Un module de formulaire ne peut pas répondre seul à cette exigence, mais il doit fournir la matière nécessaire : la liste des critères RGAA qu’il respecte nativement, à intégrer telle quelle dans l’audit global du site commandé par la collectivité.
Sur ce type de projet, on livre systématiquement, en plus du module, un tableau des critères RGAA couverts par le formulaire. Ça évite au client de repayer un audit complet juste pour vérifier ce qu’on a déjà validé nous-mêmes.
Pour aller plus loin
Un formulaire accessible pour un site de collectivité n’est pas un formulaire standard auquel on ajoute quelques attributs ARIA en fin de projet. C’est une structure HTML pensée dès la maquette pour respecter les critères du RGAA : labels explicites, regroupements sémantiques, gestion perceptible des erreurs, navigation clavier complète. Ces contraintes, une fois intégrées comme réflexes de développement, ne ralentissent pas significativement la livraison — elles évitent surtout un audit d’accessibilité qui reviendrait, sinon, comme un boomerang coûteux.
