Un formulaire semble être l’élément le plus simple d’un site : quelques champs, un bouton, un message de confirmation. C’est pourtant l’une des zones où l’accessibilité se joue le plus souvent, et où les erreurs passent le plus facilement inaperçues en test visuel classique. Le RGAA lui consacre à lui seul dix-huit critères de contrôle, plus que n’importe quelle autre thématique du référentiel.
Voici la méthode suivie pour auditer et corriger un formulaire WordPress, du champ le plus simple au message d’erreur le plus complexe, avec les corrections qui reviennent le plus souvent en pratique.
Étape 1 : un label pour chaque champ, jamais un placeholder seul
Le piège le plus fréquent consiste à remplacer l’étiquette d’un champ par un simple placeholder, un texte qui disparaît dès que l’utilisateur commence à saisir. Ce choix, souvent motivé par un souhait d’épuration visuelle, prive l’utilisateur de lecteur d’écran de tout repère une fois le champ rempli, et prive tout le monde du rappel de ce qui était attendu en cas de doute.
<label for="email-contact">Adresse e-mail</label>
<input type="email" id="email-contact" name="email" required>
L’association entre <label> et <input> se fait via l’attribut for, qui doit correspondre exactement à l’id du champ. Cette association a un effet pratique immédiat, même pour un utilisateur sans technologie d’assistance : cliquer sur le texte du label active le champ associé, ce qui agrandit la zone cliquable, un bénéfice concret sur mobile.
Étape 2 : indiquer les champs obligatoires sans se fier à la seule couleur
Marquer un champ obligatoire d’un simple astérisque rouge pose deux problèmes : la couleur seule ne transmet rien à un utilisateur de lecteur d’écran, et un astérisque isolé, sans légende expliquant sa signification, reste ambigu pour tout le monde. La solution consiste à coupler l’attribut HTML required, qui informe nativement les technologies d’assistance, à un texte visible et explicite.
- Utiliser l’attribut natif
requiredsur chaque champ obligatoire - Ajouter un texte « (obligatoire) » ou une légende générale en haut du formulaire
- Ne jamais indiquer le caractère obligatoire par la seule couleur d’un astérisque
- Préférer, si possible, marquer plutôt les champs facultatifs quand ils sont minoritaires
Étape 3 : des messages d’erreur qui s’annoncent et se voient
Un message d’erreur affiché en rouge sous un champ, sans autre mécanisme, échappe totalement à un utilisateur de lecteur d’écran resté positionné plus bas dans le formulaire au moment de la soumission. Deux techniques corrigent ce problème : associer le message au champ via aria-describedby, et regrouper la liste des erreurs dans un conteneur annoncé automatiquement grâce à aria-live ou au rôle alert.
<input type="email" id="email-contact" aria-describedby="erreur-email" aria-invalid="true">
<p id="erreur-email" role="alert">
Veuillez saisir une adresse e-mail valide.
</p>
Étape 4 : déplacer le focus vers la première erreur
À la soumission d’un formulaire invalide, la plupart des sites se contentent de réafficher la page avec les erreurs en évidence visuelle, sans déplacer le focus clavier. Un utilisateur au clavier ou au lecteur d’écran reste alors positionné là où il se trouvait, souvent sur le bouton d’envoi, sans indice sur l’endroit où intervenir. Déplacer le focus, via JavaScript, vers le premier champ en erreur (ou vers un résumé des erreurs en haut du formulaire) évite cette perte de repère complète.
Étape 5 : tester avec les extensions de formulaire réellement utilisées
Les recommandations ci-dessus s’appliquent aussi bien à un formulaire codé à la main qu’à un formulaire généré par une extension comme Gravity Forms, WPForms ou Contact Form 7. La différence tient à la marge de manœuvre : certaines extensions gèrent nativement les labels et les messages d’erreur accessibles, d’autres nécessitent un réglage ou un filtre PHP pour corriger un balisage par défaut imparfait. Tester le formulaire final, tel qu’il sera réellement publié, reste indispensable : les démonstrations en ligne d’une extension ne reflètent pas toujours sa configuration réelle sur un projet donné.
Un formulaire de contact qui fonctionne parfaitement à la souris et qui reste muet pour un lecteur d’écran n’est pas un petit défaut cosmétique. C’est souvent l’unique point de contact du site avec ses visiteurs, et il doit rester ouvert à tous sans exception.
En résumé
Un formulaire accessible ne demande ni extension supplémentaire ni compétence rare : des labels correctement associés, des champs obligatoires signalés sans dépendre de la couleur, des erreurs annoncées et non seulement affichées, et un focus qui accompagne l’utilisateur plutôt que de l’abandonner. Ces cinq vérifications, appliquées systématiquement, éliminent la grande majorité des défauts constatés sur les formulaires WordPress en production.
