Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ?
Un utilisateur malvoyant navigue avec un zoom à 400 %. Il voit le champ de saisie, mais l’étiquette se trouve à trois écrans de distance. Il ne sait pas quoi taper. Ce critère est là pour ça.
Le critère 11.4 ne demande pas seulement qu’une étiquette existe (c’est le rôle du critère 11.1) ni qu’elle soit pertinente (critère 11.2). Il exige qu’elle soit visuellement proche de son champ. Une étiquette séparée du champ par un paragraphe d’explication, un espaceur ou un autre élément est hors critère, même si l’association programmatique via for/id est techniquement correcte.
La règle de positionnement dépend du type de contrôle. Pour les champs texte, listes déroulantes et autres contrôles standard : l’étiquette se place immédiatement au-dessus ou à gauche (en langue LTR). Pour les cases à cocher et les boutons radio : elle se place immédiatement à droite ou en dessous. C’est la convention que les utilisateurs ont internalisée — la violer crée de la confusion même sans situation de handicap.
Si l’étiquette est masquée visuellement (classe sr-only ou équivalent), le critère 11.4 est non applicable. La proximité visuelle ne peut pas être vérifiée quand l’étiquette est invisible.
3 tests pour confirmer que chaque étiquette est visuellement rattachée à son champ
Accolement visuel entre étiquette et champ
Pour chaque champ de formulaire présent dans le document :
- Identifiez l’étiquette associée au champ.
- Vérifiez que l’étiquette et le champ sont visuellement accolés — aucun autre élément ne les sépare dans l’interface rendue.
- Si tous les champs passent ce contrôle, le test est validé. Un seul champ dont l’étiquette est éloignée suffit à faire échouer le test.
Position de l'étiquette pour les champs texte et listes
Ce test concerne tous les champs qui ne sont pas des cases à cocher ni des boutons radio (ni leurs équivalents ARIA role="checkbox", role="radio", role="switch").
Pour chaque champ concerné :
- Repérez l’étiquette visuellement associée au champ.
- Pour une langue LTR (français, anglais...) : vérifiez que l’étiquette est immédiatement au-dessus ou à gauche du champ, sans élément intermédiaire.
- Pour une langue RTL (arabe, hébreu...) : vérifiez que l’étiquette est immédiatement au-dessus ou à droite du champ.
- Si tous les champs passent ce contrôle, le test est validé.
Position de l'étiquette pour <input type=checkbox> et radio
Ce test concerne uniquement les cases à cocher (<input type="checkbox">), les boutons radio (<input type="radio">), et leurs équivalents ARIA (role="checkbox", role="radio", role="switch").
Pour chaque contrôle concerné :
- Repérez l’étiquette visuellement associée.
- Pour une langue LTR (français, anglais...) : vérifiez que l’étiquette est immédiatement à droite ou en dessous du contrôle.
- Pour une langue RTL (arabe, hébreu...) : vérifiez que l’étiquette est immédiatement à gauche ou en dessous du contrôle.
- Si tous les contrôles passent ce test, le test est validé.
Exemples
❌ Non conforme : Étiquette séparée du champ par un texte explicatif
<label for="email">Adresse e-mail</label>
<p>Nous utiliserons cette adresse pour vous envoyer vos factures.</p>
<input type="email" id="email" name="email" autocomplete="email">L’étiquette et le champ sont séparés par un paragraphe de texte. L’association programmatique via for/id est correcte, ce qui satisfait le critère 11.1. Mais un utilisateur zoomant à 400 % verra soit l’étiquette, soit le champ — rarement les deux simultanément. Le critère 11.4.2 échoue.
✅ Conforme : Étiquette immédiatement au-dessus d’un champ texte
<div class="form-field">
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">
</div>L’étiquette est immédiatement au-dessus du champ, sans élément intermédiaire. C’est le positionnement attendu par le test 11.4.2 pour un champ texte en langue LTR. L’utilisateur qui zoome voit les deux éléments dans la même zone de vision.
❌ Non conforme : Case à cocher avec étiquette à gauche (non conforme)
<div class="checkbox-field">
<label for="cgu">J’accepte les conditions générales d’utilisation</label>
<input type="checkbox" id="cgu" name="cgu">
</div>Pour une case à cocher en langue LTR, l’étiquette doit se trouver à droite ou en dessous du contrôle. Ici elle est à gauche : position correcte pour un champ texte, mais incorrecte pour une case à cocher selon le test 11.4.3. La convention est : on coche d’abord, on lit ce qu’on coche ensuite.
✅ Conforme : Case à cocher avec étiquette à droite (conforme)
<div class="checkbox-field">
<input type="checkbox" id="cgu" name="cgu">
<label for="cgu">J’accepte les conditions générales d’utilisation</label>
</div>L’étiquette est immédiatement à droite de la case à cocher. C’est la disposition attendue par le test 11.4.3 pour une langue LTR : le contrôle apparaît en premier, l’étiquette suit immédiatement. L’utilisateur sait ce qu’il coche avant de valider.
Astuces et pièges
⚠️ Un grand espacement CSS casse l’accolement sans que le code y paraisse
Un margin-bottom: 2rem sur le <label>, ou un gap élevé dans un conteneur flex, peut créer une séparation visuelle suffisante pour faire échouer le critère. C’est l’erreur la plus fréquente en audit sur les formulaires stylisables. Le HTML est correct, l’association aussi : seul le rendu CSS trahit la non-conformité. Un auditeur qui teste à 200 % de zoom le détecte immédiatement.
⚠️ Étiquette masquée visuellement : critère non applicable
Si l’étiquette est masquée avec une classe sr-only ou visually-hidden, le critère 11.4 ne s’applique pas. La proximité visuelle est sans objet quand il n’y a rien à voir. Reportez-vous au critère 11.1 pour vérifier que l’étiquette existe et est correctement associée programmatiquement au champ.
⚠️ CSS order ou flex-direction: row-reverse peut induire en erreur
Le test 11.4 évalue le rendu visuel, pas l’ordre du DOM. Un <label> placé après le <input> dans le code HTML mais affiché à gauche via CSS peut être conforme visuellement. Inversement, un <label> avant le <input> dans le DOM mais déplacé loin visuellement échoue. Auditez toujours le rendu dans le navigateur, pas la source.
⚠️ Les labels flottants (floating labels) sont rarement conformes
Quand un champ est vide, le label flottant est positionné à l’intérieur du champ, agissant comme un placeholder. Il n’est pas « accolé » au sens du critère 11.4.2. Quand le champ est rempli, le label remonte au-dessus et devient conforme. Le critère est donc en échec dans l’état vide. En pratique, les labels flottants cumulent plusieurs problèmes d’accessibilité et sont à éviter dans tout formulaire soumis à audit RGAA.
💡 Tester avec un zoom navigateur de 400 % est la méthode la plus efficace
Les outils automatiques ne détectent pas ce critère. C’est un contrôle visuel manuel. Zoomez à 200 % puis à 400 % et parcourez chaque champ : si vous devez faire défiler la page pour voir simultanément l’étiquette et son champ, le critère est très probablement en échec.
Questions fréquentes
Comment le critère RGAA 11.4 s'applique-t-il aux étiquettes masquées visuellement ?
Non. Le critère 11.4 mesure la proximité visuelle entre une étiquette visible et son champ. Si l’étiquette est masquée via sr-only, visually-hidden ou toute technique équivalente, il n’y a pas d’étiquette visible à évaluer : le critère est non applicable. L’association programmatique reste évaluée par le critère 11.1, lui toujours applicable.
Comment auditer visuellement le critère RGAA 11.4 et quels éléments contrôler ?
Deux vérifications : (1) qu’aucun élément ne s’intercale entre le label et le champ, et (2) que la position respecte la convention selon le type de champ. Pour les champs texte, le label est au-dessus ou à gauche. Pour les cases à cocher et boutons radio, le label est à droite ou en dessous. Activez le zoom navigateur à 200 % pour simuler l’usage d’un malvoyant : si le label disparaît pendant la saisie, la proximité est insuffisante.
Pourquoi un label positionné à droite du champ enfreint-il le critère RGAA 11.4 ?
Pour un champ texte standard en français, le label à droite est non conforme au test 11.4.2. Le label doit être immédiatement au-dessus ou à gauche. La disposition « Label : [Champ] » sur une même ligne est conforme si le label est à gauche, sans élément intercalé entre les deux.
Dans quels contextes les tests RGAA 11.4.2 et 11.4.3 sont-ils applicables ?
Non, quatre situations les rendent non applicables : (1) étiquette mélangeant des sens de lecture gauche-droite et droite-gauche au sein d’un même libellé, (2) formulaire avec des labels en plusieurs langues dont les sens de lecture s’inversent, (3) cases à cocher ou boutons radio non présentés visuellement comme tels, (4) contexte UX où une position différente est légitime et justifiable. Dans tous ces cas, notez l’inapplicabilité dans votre rapport.
Quels composants ARIA comme role="switch" sont couverts par le critère RGAA 11.4 ?
Oui, partiellement. Les éléments avec role="checkbox", role="radio" ou role="switch" sont explicitement couverts par le test 11.4.3 : leur label doit être immédiatement à droite ou en dessous (en français). Les autres rôles ARIA de formulaire (role="combobox", role="spinbutton"…) relèvent du test 11.4.2 par analogie avec les champs texte. L’accolement s’apprécie toujours visuellement.