Les formulaires sont l'endroit où votre site cesse de parler et se met à écouter : demandes de contact, commandes, inscriptions, recherches. C'est aussi là que l'accessibilité échoue le plus souvent. L'étude WebAIM Million, qui analyse chaque année le million de pages d'accueil les plus visitées, y trouve systématiquement des labels de champs manquants sur près de la moitié d'entre elles, ce qui en fait l'un des défauts d'accessibilité les plus répandus du web. Le plus frustrant : des formulaires accessibles, ce n'est pas difficile. Une poignée d'attributs HTML, correctement employés, décide si une personne aveugle peut vous envoyer un message ou renonce en silence, et si votre formulaire respecte les WCAG, que l'European Accessibility Act a transformées en obligation légale pour de nombreuses entreprises. Ce guide parcourt les cinq points qui comptent, avec du balisage prêt à copier, et se termine par un regard honnête sur les extensions de formulaires WordPress.
Pourquoi les formulaires sont-ils le plus gros problème d'accessibilité ?
Une personne voyante qui utilise une souris lit un formulaire comme un tout visuel : le texte à côté d'une case lui appartient de toute évidence, la bordure rouge signifie de toute évidence une erreur. Les technologies d'assistance n'ont rien de ce contexte. Une personne utilisant un lecteur d'écran passe d'un contrôle à l'autre avec la tabulation et n'entend que ce que le balisage relie explicitement à chaque champ. Si le lien manque, elle entend zone de saisie, vide, et doit deviner ce que le champ attend. Les utilisateurs du contrôle vocal font face au même problème : dire cliquer sur e-mail ne fonctionne que si le champ est nommé e-mail au niveau du programme.
C'est le principe central derrière chacune des règles de ce guide : toute relation visuelle dans un formulaire doit également exister dans le balisage. Label vers champ, indication vers champ, erreur vers champ, groupe vers options. Les critères de succès WCAG concernés (1.3.1 Info and Relationships, 3.3.1 Error Identification, 3.3.2 Labels or Instructions) se ramènent tous à cette idée unique.
Comment étiqueter correctement les champs de formulaire
Le fondement de tout formulaire accessible est l'élément label, relié à son champ par l'attribut for qui pointe vers l'id du champ :
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Indication supplémentaire, reliée via aria-describedby -->
<label for="password">Mot de passe</label>
<input type="password" id="password" name="password" aria-describedby="password-hint">
<p id="password-hint">Au moins douze caractères.</p>Cela vous rapporte trois choses d'un coup : les lecteurs d'écran annoncent le label quand le champ reçoit le focus, un clic sur le label place le focus dans le champ (une cible tactile plus grande sur mobile, pour tout le monde), et le contrôle vocal peut désigner le champ par son nom. Indications et consignes de format vont dans un élément séparé référencé par aria-describedby, afin d'être annoncées après le label sans l'encombrer. L'attribut autocomplete est un bonus discret : pour les champs qui collectent des données personnelles, WCAG 1.3.5 le réclame, et il permet aux navigateurs de remplir le champ correctement, ce qui aide avant tout les personnes ayant des limitations motrices et cognitives. Le tutoriel du W3C sur les formulaires couvre toutes les variantes de ces modèles.
Pourquoi un placeholder n'est pas un label
Le champ réduit à un simple placeholder est l'erreur qui a l'air la plus accessible du web. Cela paraît épuré, et cela échoue de quatre façons à la fois :
- Le texte disparaît à la saisie. La description s'évanouit exactement au moment où l'utilisateur travaille avec le champ. Quiconque a déjà oublié ce qu'un champ à moitié rempli demandait a vécu la chose.
- Le gris par défaut échoue au contraste. Le style habituel des placeholders n'atteint pas le rapport de contraste de 4,5:1 que les WCAG exigent pour le texte.
- La prise en charge par les technologies d'assistance est inégale. Certaines combinaisons de lecteur d'écran et de navigateur annoncent les placeholders, d'autres non. Un label, lui, est annoncé par toutes.
- Les champs remplis paraissent vides, les champs vides paraissent remplis. Les personnes qui balaient le formulaire pour voir ce qu'il reste à compléter comprennent l'inverse.
Les placeholders sont très bien en complément, par exemple pour montrer un format comme nom@example.com dans un champ correctement étiqueté. Comme unique description d'un champ, ce sont des échecs au critère WCAG 3.3.2 avec une belle typographie.
Comment signaler les champs obligatoires de façon accessible
Deux canaux, toujours ensemble. Le canal machine est l'attribut HTML required, qui fait annoncer le champ comme obligatoire par les navigateurs et les lecteurs d'écran et active la validation native. Le canal humain est du texte visible : le mot obligatoire (ou son contraire, facultatif) dans le label. Le populaire astérisque rouge seul échoue sur les deux tableaux : la couleur seule ne doit pas porter d'information (WCAG 1.4.1), et la convention de l'astérisque, si vous l'utilisez malgré tout, doit au minimum être expliquée au-dessus du formulaire et intégrée au label pour être annoncée.
<label for="name">Nom (obligatoire)</label>
<input type="text" id="name" name="name" required>Une inversion pragmatique produit souvent les formulaires les plus propres : si presque tous les champs sont obligatoires, ne signalez que les facultatifs et dites-le au-dessus du formulaire. Et le meilleur champ obligatoire reste celui que vous supprimez ; tout champ qu'un formulaire ne demande pas est un champ qui ne peut pas être mal rempli.
Comment rendre les messages d'erreur accessibles
La gestion des erreurs est l'endroit où les formulaires perdent les utilisateurs qu'ils n'avaient pas encore perdus. WCAG 3.3.1 exige que les erreurs soient identifiées sous forme de texte et décrites à l'utilisateur. Le modèle robuste, champ par champ :
<label for="email">Adresse e-mail (obligatoire)</label>
<input type="email" id="email" name="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">
Veuillez saisir une adresse e-mail, par exemple nom@example.com.
</p>Les pièces du puzzle : aria-invalid="true" marque le champ comme fautif pour que les lecteurs d'écran annoncent une saisie invalide à la prise de focus, le message est du vrai texte (pas seulement une bordure rouge, pas seulement une icône) et il est relié au champ par aria-describedby, et la formulation dit comment corriger le problème, pas seulement qu'il y en a un. Erreur, veuillez corriger n'aide personne ; Veuillez saisir une date au format JJ.MM.AAAA, si.
Pour la validation qui se déclenche à l'envoi, une étape de plus compte : après un envoi échoué, déplacez le focus clavier vers le premier champ fautif, ou affichez en haut un récapitulatif d'erreurs avec role="alert" et des liens vers les champs concernés. Une personne utilisant un lecteur d'écran qui envoie et n'entend rien suppose que le formulaire a fonctionné. Le silence après un envoi échoué est le bug de formulaire le plus cruel qui soit.
Fieldset et legend : grouper boutons radio et cases à cocher
Les groupes de boutons radio et de cases à cocher ont une structure à deux niveaux : le groupe porte une question, chaque option porte un label. Les deux niveaux doivent figurer dans le balisage, et les éléments natifs pour le niveau du groupe sont fieldset et legend :
<fieldset>
<legend>Moyen de contact préféré (obligatoire)</legend>
<input type="radio" id="contact-email" name="contact" value="email">
<label for="contact-email">E-mail</label>
<input type="radio" id="contact-phone" name="contact" value="phone">
<label for="contact-phone">Téléphone</label>
</fieldset>Sans le fieldset, une personne utilisant un lecteur d'écran qui entre dans le groupe à la tabulation n'entend que E-mail, bouton radio, un sur deux, et n'a aucune idée de la question à laquelle les options répondent. Avec lui, la legend est annoncée en premier. La même structure sert aux groupes de cases à cocher et mérite d'être conservée même quand un design system restyle les éléments au point de les rendre méconnaissables ; la sémantique ne coûte rien et porte tout.
Les extensions de formulaires WordPress sont-elles accessibles ?
Elles peuvent l'être, pour l'essentiel, et aucune ne le garantit. Le tableau honnête, extension par extension : Contact Form 7 restitue ce que vous écrivez dans son modèle de formulaire, labels, fieldsets et câblage des erreurs sont donc entièrement entre vos mains ; la souplesse qui fait sa popularité rend aussi très facile la mise en ligne de formulaires sans labels. Gravity Forms a refondu son balisage avec l'accessibilité comme objectif explicite il y a quelques années et produit un résultat solide dans ses versions actuelles. WPForms a de même investi dans des réglages par défaut accessibles. Dans tous les cas, trois choses peuvent encore casser une extension accessible : les styles de votre thème (contours de focus supprimés, contraste détruit), les CAPTCHA (une barrière totalement inaccessible, les approches à base de honeypot évitent le problème) et les types de champs personnalisés ajoutés par-dessus.
Testez donc le résultat rendu, pas la page marketing. La version en deux minutes : débranchez votre souris et remplissez le formulaire au clavier seul, en vérifiant que vous voyez le focus à chaque étape, puis envoyez-le vide et vérifiez si les messages d'erreur sont annoncés et atteignables. Les vérificateurs automatiques comme WAVE attrapent la moitié structurelle du problème, labels manquants compris, en quelques secondes.
Comment InspectWP vous aide à repérer les problèmes de formulaires
Le rapport InspectWP examine votre site WordPress tel qu'un navigateur le voit, et plusieurs contrôles portent directement sur les formulaires. Il signale les formulaires dont l'action envoie vers une adresse HTTP non sécurisée, un problème que les navigateurs sanctionnent par des avertissements exactement au moment où un visiteur s'apprête à vous confier des données. Au-delà, le rapport couvre les fondamentaux d'accessibilité autour de vos formulaires : les images sans attribut alt, la hiérarchie des titres qui sert de repère aux personnes utilisant un lecteur d'écran, et les erreurs de console qui révèlent souvent des scripts de validation cassés. Un rapport gratuit est un premier passage rapide sur la page où vit votre formulaire.