Formulaires accessibles : étiquettes, aides et erreurs

Six critères de succès pour les formulaires

Les WCAG 2.2 sont la recommandation actuelle du W3C pour des contenus web accessibles. Pour les textes d’un formulaire, six de leurs critères de succès comptent le plus :

• 1.3.1 Information et relations (niveau A) : ce que montre la mise en page, par exemple quelle étiquette appartient à quel champ, est aussi disponible dans le code ou sous forme de texte.
• 1.3.5 Identifier la finalité des champs (niveau AA) : les champs qui demandent des informations sur l’utilisateur, comme le nom ou l’e-mail, exposent leur finalité dans le code.
• 3.3.1 Identification des erreurs (niveau A) : si une erreur de saisie est détectée automatiquement, le champ est nommé et l’erreur est décrite sous forme de texte.
• 3.3.2 Étiquettes ou instructions (niveau A) : des étiquettes ou des instructions sont fournies lorsque le contenu demande une saisie de l’utilisateur.
• 3.3.3 Suggestion après une erreur (niveau AA) : si une erreur est détectée et qu’une correction est connue, elle est proposée, sauf si cela compromet la sécurité ou la finalité du contenu.
• 4.1.2 Nom, rôle et valeur (niveau A) : chaque composant a un nom et un rôle que les logiciels peuvent lire.

Chaque champ a besoin d’une étiquette visible

Une étiquette dit ce qui doit figurer dans le champ, et elle reste visible pendant que l’utilisateur tape. En HTML, relie l’élément label au champ : l’attribut for de l’étiquette a exactement la même valeur que l’id du champ. Les lecteurs d’écran lisent alors l’étiquette avec le champ, et un clic sur l’étiquette place le curseur dans le champ. Un bouton tire son étiquette de son texte, et « Envoyer le message » en dit plus que « Valider ». Les étiquettes se placent en général à droite des boutons radio et des cases à cocher, et à gauche ou au-dessus des autres champs ; les étiquettes au-dessus des champs prennent moins de place en largeur.

Un placeholder n’est pas une étiquette

Le texte gris dans un champ vide ressemble à une étiquette, mais ce n’en est pas une. Le W3C cite les problèmes :

• Il disparaît dès qu’on tape, ce qui rend plus difficile la vérification des saisies avant l’envoi.
• Les navigateurs l’affichent souvent dans une couleur claire avec trop peu de contraste.
• Les lecteurs d’écran ne le traitent pas comme une étiquette, et la prise en charge varie.

Utilise un placeholder tout au plus pour un exemple, et mets tout ce qui est important dans l’étiquette ou dans une aide.

Aides et champs obligatoires

• Mets les règles dans une aide : le format de date, la longueur d’un numéro client, ce qu’exige un mot de passe. En HTML, tu peux relier l’aide au champ avec aria-describedby, pour que les lecteurs d’écran la lisent après l’étiquette.
• Indique quels champs sont obligatoires et lesquels sont facultatifs. Si tu utilises un astérisque, explique-le une fois au début du formulaire.
• Place les instructions qui concernent tout le formulaire avant celui-ci, par exemple sur une limite de temps.
• Garde les aides courtes. Trop d’instructions rendent un formulaire plus difficile, pas plus simple.

Regrouper les champs liés

Les boutons radio et les cases à cocher qui vont ensemble sont regroupés avec l’élément fieldset, et l’élément legend nomme le groupe, par exemple « Comment devons-nous te contacter ? ». Le W3C indique que les groupes de boutons radio devraient toujours être regroupés ainsi. Garde la légende courte, car certains lecteurs d’écran la lisent avec chaque champ. Les groupes aident aussi pour les champs qui ont la même étiquette, comme la rue dans une adresse de livraison et dans une adresse de facturation.

autocomplete : laisse le navigateur aider

Pour les champs qui demandent des informations sur l’utilisateur, le critère 1.3.5 demande que leur finalité puisse être déterminée dans le code. Les WCAG 2.2 contiennent une liste de ces finalités, fondée sur la section autofill de la spécification HTML, comme name, given-name, family-name, email, tel, street-address et postal-code. En HTML, tu les définis avec l’attribut autocomplete, par exemple autocomplete="email". Les navigateurs peuvent alors remplir les valeurs enregistrées, ce qui évite de taper. Les champs qui ne concernent pas l’utilisateur n’ont pas besoin de finalité.

Des messages d’erreur qui aident

Un message d’erreur a trois missions : nommer le champ, dire ce qui ne va pas et dire comment corriger. Le critère 3.3.1 demande les deux premières, sous forme de texte : une bordure rouge ou une icône seule ne suffit donc pas. Le critère 3.3.3 demande la correction lorsqu’elle est connue.

• Affiche le message à côté du champ et relie-le avec aria-describedby, pour que les lecteurs d’écran le lisent avec le champ.
• Après l’envoi, affiche une liste de toutes les erreurs en haut, avant le formulaire, sous un titre clair. Chaque entrée nomme le champ, le problème et la correction, et renvoie vers le champ.
• Mets aussi à jour le titre de la page, par exemple « 2 erreurs – Formulaire de contact », et place le focus sur le premier champ en erreur.
• Conserve ce que l’utilisateur a déjà saisi. C’est notre conseil, pas une règle des WCAG : tout retaper après une seule erreur pousse les gens à abandonner.

Vérifier ton formulaire avec Do4U

L’outil Textes de formulaire vérifie les textes d’un formulaire web. Tu colles le HTML du formulaire ou tu indiques l’adresse de la page, et tu peux ajouter les messages d’erreur que ton formulaire affiche. Le code lit chaque champ : son étiquette et d’où elle vient, les aides, les placeholders, les champs obligatoires, les valeurs autocomplete et les groupes de boutons radio ou de cases à cocher. Il trouve des problèmes comme un champ sans étiquette, un placeholder comme seule étiquette, des champs obligatoires que le texte ne mentionne pas, des valeurs autocomplete manquantes et des messages d’erreur vagues, chacun avec son critère de succès. L’IA propose une étiquette claire, une aide courte et un message d’erreur qui nomme le champ et dit comment corriger la saisie. Le code vérifie chaque suggestion et construit à partir de ton formulaire un brouillon HTML amélioré.

Do4U trouve des indices et prépare un brouillon, toi tu vérifies et tu décides. L’outil vérifie le balisage, pas tes styles, tes scripts ni l’utilisation au clavier, et il ne te dit pas si ton formulaire est accessible. Teste le formulaire amélioré avec un clavier et un lecteur d’écran.