Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ?
Un utilisateur navigue sur un site d’e-commerce. Sur la page d’accueil, le champ de recherche s’appelle « Rechercher ». Sur la page catégorie, il lit « Trouver ». Sur la page résultats, « Chercher ». Pour une personne ayant des troubles cognitifs, ou pour un utilisateur de lecteur d’écran qui repère les formulaires par leurs étiquettes, cette variabilité crée une charge mentale réelle : s’agit-il du même outil ou de fonctions différentes ?
Le critère 11.3 exige que les champs ayant la même fonction portent des étiquettes cohérentes, que ce soit au sein d’une même page ou d’un ensemble de pages. La cohérence n’exige pas l’identité parfaite, mais que les étiquettes permettent de comprendre qu’il s’agit du même type de saisie. Un formulaire de commande avec deux blocs d’adresse doit nommer ses champs de rue de la même façon dans les deux blocs.
Même fonction, même étiquette. C’est la règle.
Ce problème surgit dans deux situations concrètes. Les formulaires multi-sections construits par différents développeurs sans concertation : l’un nomme le champ « Adresse », l’autre « Rue ». Les A/B tests ou composants dupliqués qui évoluent indépendamment d’une page à l’autre. La solution la plus fiable : un composant réutilisable avec une étiquette fixe.
2 tests pour vérifier la cohérence des étiquettes entre les pages
Cohérence des étiquettes de même nature dans la page
- Repérez les groupes de champs ayant la même fonction au sein de la page (ex. : deux blocs adresse dans un formulaire de commande, plusieurs champs e-mail dans un formulaire multi-étapes).
- Pour chaque groupe, comparez les étiquettes utilisées : permettent-elles de comprendre qu’il s’agit du même type de saisie ?
- Si une étiquette dit « Adresse » et une autre dit « Rue » pour deux champs de rue, le test échoue.
- Si toutes les étiquettes sont cohérentes entre elles, le test est validé.
Cohérence des étiquettes de même nature entre les pages
- Sur l’ensemble des pages de l’échantillon d’audit, repérez les champs récurrents : champ de recherche global, inscription newsletter, formulaire de connexion.
- Pour chaque champ récurrent, relevez l’étiquette utilisée sur chaque page où il apparaît.
- Comparez les étiquettes entre les pages : sont-elles identiques ou suffisamment proches pour qu’un utilisateur comprenne qu’il s’agit du même champ ?
- Si une variation existe (ex. : « Rechercher » sur une page, « Trouver » sur une autre), le test échoue.
- Si toutes les étiquettes sont cohérentes sur l’ensemble des pages, le test est validé.
Exemples
❌ Non conforme : Deux blocs adresse avec des étiquettes incohérentes
<fieldset>
<legend>Adresse de facturation</legend>
<label for="fact-adresse">Adresse</label>
<input type="text" id="fact-adresse" name="fact_adresse">
<label for="fact-cp">Code postal</label>
<input type="text" id="fact-cp" name="fact_cp">
<label for="fact-ville">Ville</label>
<input type="text" id="fact-ville" name="fact_ville">
</fieldset>
<fieldset>
<legend>Adresse de livraison</legend>
<label for="livr-rue">Rue</label>
<input type="text" id="livr-rue" name="livr_rue">
<label for="livr-cp">Code postal</label>
<input type="text" id="livr-cp" name="livr_cp">
<label for="livr-ville">Ville</label>
<input type="text" id="livr-ville" name="livr_ville">
</fieldset>Le premier champ de rue s’appelle « Adresse », le second « Rue ». Pour un utilisateur de lecteur d’écran qui navigue par formulaire, ou pour une personne ayant des difficultés cognitives, cette incohérence crée un doute : ces deux champs demandent-ils vraiment la même chose ? Le test 11.3.1 échoue.
✅ Conforme : Deux blocs adresse avec des étiquettes cohérentes
<fieldset>
<legend>Adresse de facturation</legend>
<label for="fact-rue">Rue</label>
<input type="text" id="fact-rue" name="fact_rue">
<label for="fact-cp">Code postal</label>
<input type="text" id="fact-cp" name="fact_cp">
<label for="fact-ville">Ville</label>
<input type="text" id="fact-ville" name="fact_ville">
</fieldset>
<fieldset>
<legend>Adresse de livraison</legend>
<label for="livr-rue">Rue</label>
<input type="text" id="livr-rue" name="livr_rue">
<label for="livr-cp">Code postal</label>
<input type="text" id="livr-cp" name="livr_cp">
<label for="livr-ville">Ville</label>
<input type="text" id="livr-ville" name="livr_ville">
</fieldset>Les deux blocs utilisent exactement les mêmes étiquettes (« Rue », « Code postal », « Ville »). La légende du fieldset (« Adresse de facturation » / « Adresse de livraison ») différencie le contexte sans modifier les étiquettes des champs. L’utilisateur comprend immédiatement qu’il saisit le même type d’information dans les deux blocs.
Astuces et pièges
⚠️ Les synonymes font échouer le test
« Rechercher », « Trouver », « Chercher » : pour un développeur, ce sont des variantes équivalentes. Pour le critère 11.3 et la technique d’échec F31, ce sont trois étiquettes différentes pour la même fonction. Le test échoue. Choisissez un terme et tenez-vous y sur toutes les pages.
⚠️ Même format de saisie ne signifie pas même fonction
Un champ « E-mail de facturation » et un champ « E-mail de livraison » ont le même format, mais des fonctions différentes. Le critère 11.3 ne s’applique pas entre eux. Il s’applique si le même champ « E-mail » apparaît dans le formulaire d’inscription sur plusieurs pages avec des libellés variés.
💡 Un composant réutilisable garantit la cohérence structurellement
Si votre champ de recherche est un composant React, Vue ou Web Component avec une étiquette définie dans le composant lui-même, la cohérence inter-pages est garantie sans effort. C’est plus fiable qu’une convention de nommage documentée que chaque développeur doit respecter manuellement.
⚠️ Les A/B tests brisent silencieusement la cohérence
Un test d’interface qui renomme un champ sur une variante crée une non-conformité au critère 11.3 si les deux variantes coexistent au même moment sur des pages différentes. C’est une erreur fréquente lors des audits de sites avec des outils de personnalisation ou d’expérimentation actifs.
⚠️ La cohérence n’exige pas l’identité parfaite
Le critère demande que les étiquettes permettent de « comprendre qu’il s’agit de saisies de natures identiques ». « E-mail » et « Adresse e-mail » pour le même champ de connexion sont généralement considérés comme cohérents. En revanche, « Identifiant » et « Login » pour le même champ constituent une ambiguïté réelle selon l’audience visée.
Questions fréquentes
Comment auditer la cohérence sur un ensemble de pages en pratique ?
Construisez un tableau : chaque ligne est un champ récurrent (recherche, newsletter, connexion), chaque colonne est une page de l’échantillon. Renseignez l’étiquette trouvée sur chaque page. Les cellules qui diffèrent signalent les non-conformités. Pour un site de taille standard, l’opération prend une vingtaine de minutes.
Quand une variation comme E-mail et Adresse e-mail constitue-t-elle une non-conformité RGAA 11.3 ?
Non dans la plupart des cas. Le critère évalue si l’utilisateur peut comprendre qu’il s’agit du même type de saisie : « E-mail » et « Adresse e-mail » sont suffisamment proches. En revanche, « Rechercher » et « Trouver » pour le même champ constituent une incohérence au sens du critère et de la technique d’échec F31.
Dans quels cas le critère RGAA 11.3 concerne-t-il les boutons de soumission ?
Le critère 11.3 porte sur les étiquettes des champs de formulaire, pas sur les boutons. La cohérence des boutons (ex. : « Envoyer » sur une page, « Valider » sur une autre) est néanmoins couverte par le critère de succès WCAG 3.2.4 (Identification cohérente), qui est la référence normative de ce critère.
Quand des étiquettes différentes sur un même champ de recherche répété constituent-elles une non-conformité RGAA ?
Oui. Si les deux champs sont présents sur la même page avec des étiquettes différentes, c’est une non-conformité au test 11.3.1. Si les étiquettes ne varient qu’entre pages, c’est le test 11.3.2 qui s’applique. Dans les deux cas, la correction est la même : une étiquette unique, systématique, portée par un composant partagé.