# Formulaires accessibles : labels, messages d’erreur et gestion du focus

> Un formulaire de contact mal balisé exclut une partie des visiteurs sans que personne ne s'en aperçoive. Cinq points à vérifier pour rendre un formulaire WordPress réellement utilisable.

- Auteur : Clément Hadrot
- Publié le : 2021-09-08
- Mis à jour le : 2021-09-08
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/formulaires-accessibles-wordpress/

## L’essentiel

- Chaque champ a besoin d'un label associé, jamais d'un simple placeholder
- Les erreurs doivent être annoncées, pas seulement colorées
- Le focus doit se déplacer vers la première erreur

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 `required` sur 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

> L'essentiel à retenir : Chaque champ a besoin d'un label associé, jamais d'un simple placeholder ; Les erreurs doivent être annoncées, pas seulement colorées ; Le focus doit se déplacer vers la première erreur

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.