RGAA 11.1 — Chaque champ de formulaire a-t-il une étiquette ?

Champs de formulaire sans étiquette

Le problème

Les champs de formulaire sans étiquette sont un obstacle majeur à l'accessibilité. Le critère 11.1 du RGAA exige que chaque champ de formulaire (input, textarea, select) soit associé à une étiquette qui décrit clairement l'information attendue. Sans étiquette, un utilisateur de lecteur d'écran entend simplement « édition de texte » ou « zone de liste » sans savoir ce qu'il doit saisir. Le problème se présente sous plusieurs formes. La plus courante est l'utilisation d'un placeholder comme seule indication du champ. Le placeholder disparaît dès que l'utilisateur commence à taper, ce qui pose un problème de mémoire : l'utilisateur ne se souvient plus de ce qu'on lui demandait. De plus, les lecteurs d'écran ne traitent pas tous les placeholders de la même manière — certains les annoncent, d'autres non. Un placeholder n'est jamais un substitut acceptable à un label. Une autre erreur fréquente est la présence d'un texte visuellement proche du champ mais non associé programmatiquement. Un paragraphe « Votre email » placé au-dessus d'un input sans for/id correspondant sera visible à l'écran mais invisible pour les lecteurs d'écran. L'association doit être explicite via l'attribut for du label pointant vers l'id du champ, ou en enveloppant le champ dans la balise label. Les groupes de champs radio et checkbox nécessitent aussi un traitement particulier : chaque option doit avoir son label individuel, et le groupe entier doit être enveloppé dans un fieldset avec un legend décrivant la question. L'absence de fieldset/legend fait que le lecteur d'écran annonce « bouton radio, Oui » sans contexte — l'utilisateur ne sait pas à quelle question « Oui » fait référence.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Impact sur les utilisateurs

Pour un utilisateur de lecteur d'écran, un formulaire sans étiquettes est un formulaire qu'il ne peut pas remplir correctement. Il doit deviner quel champ correspond à quelle information en se basant sur l'ordre des champs, ce qui est source d'erreurs. Il peut saisir son nom dans le champ email, son adresse dans le champ téléphone — autant d'erreurs qui entraînent des soumissions échouées ou des données erronées. Les utilisateurs de commande vocale sont aussi affectés : ils disent « Cliquer sur Email » pour placer le curseur dans le champ email, mais si le champ n'a pas de label associé, la commande ne fonctionne pas. Les personnes ayant des troubles cognitifs bénéficient des étiquettes clairement associées aux champs. L'absence d'étiquette augmente la charge cognitive et le taux d'abandon des formulaires. Sur un site e-commerce, un formulaire de commande sans étiquettes accessibles peut entraîner une perte directe de chiffre d'affaires en excluant une partie de la clientèle.

Exemple de code

Avant (non conforme)
<form>
  <input type="text" placeholder="Nom">
  <input type="email" placeholder="Email">
  <p>Acceptez-vous les CGV ?</p>
  <input type="radio" name="cgv" value="oui"> Oui
  <input type="radio" name="cgv" value="non"> Non
  <button type="submit">Envoyer</button>
</form>
Après (conforme)
<form>
  <div>
    <label for="nom">Nom</label>
    <input type="text" id="nom" name="nom" autocomplete="name">
  </div>
  <div>
    <label for="email">Adresse email</label>
    <input type="email" id="email" name="email" autocomplete="email">
  </div>
  <fieldset>
    <legend>Acceptez-vous les CGV ?</legend>
    <label>
      <input type="radio" name="cgv" value="oui"> Oui
    </label>
    <label>
      <input type="radio" name="cgv" value="non"> Non
    </label>
  </fieldset>
  <button type="submit">Envoyer</button>
</form>

Questions fréquentes

Peut-on utiliser aria-label au lieu d'un label visible ?
Techniquement oui, aria-label fournit une étiquette aux lecteurs d'écran. Mais un label visible bénéficie à tous les utilisateurs : il aide les personnes avec des troubles cognitifs, les utilisateurs sur mobile qui ont besoin de savoir quel champ ils remplissent, et il augmente la zone de clic (cliquer sur le label donne le focus au champ). Utilisez aria-label uniquement quand le design ne permet vraiment pas de label visible.
Le placeholder peut-il remplacer le label ?
Non. Le placeholder disparaît quand l'utilisateur tape, ce qui pose un problème de mémoire. Il n'est pas annoncé de manière fiable par tous les lecteurs d'écran. Son contraste est souvent insuffisant. Le RGAA n'accepte pas le placeholder comme étiquette valide. Utilisez un vrai label et le placeholder uniquement comme complément (exemple de format attendu).
Comment associer un label à un champ de formulaire ?
Deux méthodes : 1) L'attribut for : <label for="email">Email</label><input id="email">. L'id du champ doit correspondre au for du label. 2) L'imbrication : <label>Email <input type="email"></label>. Le champ est à l'intérieur du label, l'association est automatique. La première méthode est généralement préférée car elle offre plus de flexibilité de mise en page.
Quand utiliser fieldset et legend ?
Utilisez fieldset et legend pour les groupes de champs radio, checkbox, et tout groupe de champs liés par une même question ou un même sujet. Le legend décrit la question commune (« Quelle est votre tranche d'âge ? ») et chaque label décrit l'option individuelle (« 18-25 ans »). Sans fieldset/legend, le lecteur d'écran annonce les options sans contexte.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit