WCAG 3.2.4 : Identification cohérente

Ce que signifie cette règle

Le critère de succès 3.2.4 des WCAG — Identification cohérente — stipule que les composants qui ont la même fonctionnalité au sein d’un ensemble de pages web doivent être identifiés de manière cohérente. Cela signifie que chaque fois qu’un élément interactif ou une image remplit la même fonction, il doit porter le même nom ou libellé accessible chaque fois qu’il apparaît sur le site.

Le terme « identifié » dans ce contexte fait référence à la manière dont un composant est présenté aux technologies d’assistance et aux utilisateurs. Cela inclut le texte du libellé visible, l’attribut aria-label ou aria-labelledby, le texte alt d’une image, l’attribut title, ou le nom accessible calculé par l’arbre d’accessibilité du navigateur. Si un bouton de recherche apparaît sur chaque page d’un site, il doit toujours s’appeler « Search » — et non « Search » sur la page d’accueil, « Find » sur la page de liste de produits, et « Go » sur la page de paiement.

Ce critère s’applique à un ensemble de pages web, que les WCAG définissent comme un ensemble de pages partageant un objectif commun et produites par le même auteur. Cela couvre un site web entier, une application web ou un formulaire multi-étapes s’étendant sur plusieurs URL. Les composants qui sont simplement visuellement similaires mais remplissent des fonctions différentes ne sont pas tenus de partager le même nom — l’exigence est spécifiquement liée à une fonctionnalité identique.

Ce qui est considéré comme conforme : Une icône de navigation qui ouvre un menu hamburger est systématiquement libellée « Open navigation menu » (ou équivalent) sur toutes les pages. Une icône de panier d’achat a toujours le texte alt ou le nom accessible « Shopping cart ». Un bouton de déconnexion est toujours libellé « Log out ». Une variation de formulation pour la même fonction constitue un échec.

Ce qui est considéré comme non conforme : Un bouton d’envoi libellé « Submit » sur le formulaire d’inscription mais libellé « Send » sur le formulaire de contact alors que les deux boutons remplissent la même fonction de transmission des données saisies par l’utilisateur. Un bouton icône représentant une loupe libellé « Search » sur la plupart des pages mais « Ara » sur une seule sous-page traduite sans stratégie linguistique cohérente.

Exception officielle : Les WCAG précisent explicitement qu’il est acceptable d’avoir deux composants avec le même nom accessible s’ils remplissent des fonctions différentes — dans ce cas, la différence de fonction permet de les distinguer. Le critère ne s’applique que lorsque la fonction est identique mais que la dénomination est incohérente.

Pourquoi c’est important

Une identification incohérente crée une charge disproportionnée pour les utilisateurs qui s’appuient sur des stratégies de navigation non visuelles ou basées sur des schémas. Les groupes les plus gravement touchés incluent les utilisateurs de lecteurs d’écran, les personnes ayant des handicaps cognitifs et les personnes ayant des limitations motrices qui utilisent des logiciels de commande vocale.

Les utilisateurs de lecteurs d’écran construisent un modèle mental d’un site web en écoutant les noms des éléments lorsqu’ils naviguent avec la touche Tab ou par repères. Lorsqu’un bouton qui remplissait la même fonction sur la page précédente porte désormais un nom différent, l’utilisateur doit s’arrêter, enquêter et se réorienter — une expérience chronophage et frustrante. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle. Même une fraction de cette population, interagissant avec un site dont les libellés sont incohérents, rencontrera des obstacles significatifs.

Les personnes ayant des handicaps cognitifs, y compris celles ayant une dyslexie, des troubles de l’attention ou des troubles de la mémoire, dépendent fortement d’une dénomination prévisible pour réduire la charge cognitive. Rencontrer une icône ou un contrôle familier sous un nom différent impose un réapprentissage et provoque de l’anxiété. Un étiquetage cohérent réduit l’effort nécessaire pour construire une mémoire procédurale lors de l’utilisation régulière d’un site.

Les utilisateurs de commandes vocales (utilisant des outils comme Dragon NaturallySpeaking ou Voice Control d’Apple) prononcent le nom d’un contrôle pour l’activer. Si le nom accessible d’un bouton diffère de ce qu’ils attendent sur la base de leur expérience précédente du site, leur commande vocale échouera silencieusement — le logiciel ne trouvera tout simplement pas de correspondance. L’interface devient alors effectivement inutilisable à ce moment-là.

Un scénario concret : Considérons une plateforme de e-commerce turque qui vend des vêtements. Sur la page de grille de produits, chaque article possède un bouton avec une icône de cœur dont le nom accessible est « Add to favourites ». Sur la page de détail du produit, le nom accessible de la même icône de cœur est « Kaydet » (turc pour « Enregistrer »). Un utilisateur de lecteur d’écran qui a appris à activer le bouton en forme de cœur par son nom sur la page de grille ne peut plus trouver le contrôle équivalent sur la page de détail sans exploration exhaustive. Il peut abandonner le site entièrement.

Au-delà de l’accessibilité, un étiquetage cohérent bénéficie au SEO. Les moteurs de recherche analysent les noms accessibles et le texte des liens pour comprendre le contenu des pages. Un étiquetage incohérent pour des liens fonctionnellement identiques (par exemple, « Read more », « Continue reading », « Learn more » pointant tous vers des pages de détail d’articles) dilue les signaux de mots-clés et rend plus difficile la compréhension de la structure du site par les robots d’indexation.

Règles axe-core associées

Le critère 3.2.4 des WCAG nécessite des tests manuels, car les outils automatisés ne peuvent pas déterminer l’intention sémantique à travers les pages ni savoir que deux composants portant des noms différents remplissent la même fonction. Aucune règle axe-core ne correspond directement à ce critère. Voici pourquoi l’automatisation est insuffisante et ce que les testeurs doivent faire à la place :

• Tests manuels requis — cohérence entre les pages : Axe-core évalue une seule page isolément. Il n’a aucun mécanisme pour comparer le nom accessible d’un bouton « Search » sur la page d’accueil avec un bouton « Find » sur une page produit, car il ne maintient pas un inventaire inter-pages des noms de composants. Un testeur humain doit cataloguer les éléments fonctionnels répétés et vérifier que leur dénomination est uniforme sur toutes les pages où ils apparaissent.
• Tests manuels requis — cohérence du texte alt des icônes et images : Les outils automatisés peuvent détecter l’absence de texte alt (via la règle image-alt) mais ne peuvent pas déterminer si deux images remplissant le même rôle portent le même texte alt sur différentes pages. Par exemple, une icône d’imprimante sur une page de reçus et la même icône d’imprimante sur une page de facture peuvent toutes deux avoir un texte alt — mais si l’une indique « Print » et l’autre « Print this page », un humain doit juger si cela constitue une incohérence au regard du critère 3.2.4.
• Tests manuels requis — cohérence des libellés ARIA : Axe-core vérifie que les libellés ARIA sont présents et non vides, mais il n’audite pas la cohérence des valeurs aria-label pour un même type de composant sur l’ensemble des pages. Un testeur doit inspecter l’arbre d’accessibilité sur plusieurs pages et comparer les noms des contrôles fonctionnellement identiques.
• Tests manuels requis — libellés des contrôles de formulaire : Des règles automatisées comme label vérifient que les champs de saisie sont associés à des libellés, mais elles ne vérifient pas qu’un champ « Username » sur la page de connexion est également libellé « Username » (plutôt que « Email » ou « User ID ») sur la page de récupération de compte lorsque les deux champs acceptent le même type de saisie et remplissent le même rôle fonctionnel.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools ou Lighthouse sur chaque page pour faire apparaître les violations associées, telles que l’absence de noms accessibles (image-alt, button-name, link-name). Corrigez celles-ci en premier — vous ne pouvez pas évaluer la cohérence des noms si les noms sont absents. Notez les noms accessibles signalés pour les composants répétés dans vos résultats d’analyse.
2. Créer un inventaire des composants : Dressez manuellement la liste de tous les composants fonctionnels qui se répètent sur les pages — menus de navigation, champs de recherche, boutons d’envoi, boutons icônes, liens de fil d’Ariane, liens vers les réseaux sociaux, boutons d’impression/partage et contrôles de pagination. Relevez le nom accessible de chaque instance à l’aide du panneau Accessibilité de votre navigateur (Chrome DevTools > Elements > Accessibility, ou Firefox Accessibility Inspector).
3. Comparer les noms entre les pages : Pour chaque type de composant de votre inventaire, vérifiez que chaque instance porte le même nom accessible. Signalez toute divergence. Portez une attention particulière aux composants qui apparaissent dans les en-têtes, pieds de page et barres latérales, car ce sont ceux qui risquent le plus d’être étiquetés de manière incohérente entre les gabarits.
4. Tests avec lecteur d’écran NVDA + Firefox : Accédez à la page d’accueil, puis utilisez la liste des éléments de NVDA (Insert + F7) pour ouvrir la liste des boutons et des liens. Notez les noms des contrôles répétés. Accédez ensuite à trois ou quatre autres pages représentatives et répétez l’opération. Soyez attentif à toute variation de nom pour des contrôles fonctionnellement identiques.
5. Tests avec VoiceOver + Safari (macOS/iOS) : Utilisez le Rotor (VO + U) pour afficher la liste des boutons ou des liens sur chaque page. Comparez les noms des éléments répétés. Sur iOS, faites défiler les éléments interactifs sur des pages équivalentes et notez toute différence de nommage.
6. Tests avec JAWS + Chrome : Utilisez le curseur virtuel de JAWS et la liste des champs de formulaire (Insert + F5) et des liens (Insert + F7) sur plusieurs pages. Confirmez que les contrôles identiques partagent des noms identiques sur l’ensemble du site.
7. Test de commande vocale : En utilisant Windows Voice Access ou Dragon NaturallySpeaking, prononcez le nom d’un contrôle répété sur une page (par exemple, « Click Search »). Accédez à une autre page et prononcez la même commande. Si elle échoue, les noms sont incohérents d’un point de vue fonctionnel.

Comment corriger

Bouton de recherche avec libellés incohérents — Incorrect

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Bouton de recherche avec libellés incohérents — Correct

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Image icône utilisée pour la même action avec des textes alt différents — Incorrect

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Image icône utilisée pour la même action avec des textes alt différents — Correct

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Bouton de fermeture de navigation nommé de manière incohérente — Incorrect

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Bouton de fermeture de navigation nommé de manière incohérente — Correct

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Liens de partage social avec des noms variables — Incorrect

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Liens de partage social avec des noms variables — Correct

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Erreurs courantes

• Utiliser des valeurs aria-label différentes dans différents gabarits pour le même composant : Lorsque des développeurs distincts construisent des gabarits de page indépendamment sans bibliothèque de composants partagée, des boutons icônes comme fermer, rechercher et panier reçoivent fréquemment des libellés ad hoc. Mettez en place un jeton de design system ou un composant partagé pour chaque élément interactif répété afin que le nom accessible soit défini une fois et réutilisé partout.
• Traduire les noms accessibles de manière incohérente sur des pages multilingues : Un site peut correctement libeller un bouton de recherche « Search » en anglais mais utiliser ensuite un équivalent turc incohérent — parfois « Ara », parfois « Arama Yap » — selon le gabarit de page qui a été localisé en premier. Maintenez une seule clé de traduction par libellé de composant et appliquez-la dans tous les fichiers de langue.
• Ajouter des suffixes contextuels à des contrôles par ailleurs identiques : Libeller des boutons « Add to cart — Blue T-Shirt », « Add to cart — Red Dress », etc. lorsque la fonction principale (ajouter au panier) est la même n’est pas automatiquement un échec au regard du critère 3.2.4 — les WCAG autorisent la désambiguïsation — mais le faire de manière incohérente (parfois avec suffixe, parfois sans) crée de la confusion. Choisissez un modèle et appliquez-le uniformément.
• Compter sur le texte visible du libellé pour assurer la cohérence alors que les aria-label de remplacement diffèrent : Lorsqu’un bouton affiche visuellement « Search » mais qu’un gabarit ajoute aria-label='Search the site' et qu’un autre n’a pas d’attribut aria-label (de sorte que le nom accessible est dérivé uniquement du texte visible), les lecteurs d’écran annonceront des noms différents même si le bouton semble identique. Auditez le calcul complet du nom accessible, pas seulement le libellé visible.
• Laisser les éditeurs d’un CMS modifier librement le texte des boutons sans gouvernance en matière d’accessibilité : Les systèmes de gestion de contenu qui exposent les libellés des boutons comme champs éditables permettent aux éditeurs de renommer « Submit » en « Send » ou « Gönder » selon leurs préférences. Limitez la modification des libellés pour les composants d’interface fonctionnels ou ajoutez une validation qui avertit les éditeurs lorsqu’un libellé proposé diverge de la norme établie.
• Ne pas auditer les widgets tiers ou composants intégrés : Les widgets de chat, bannières de consentement aux cookies et iframes de paiement injectés par des tiers contiennent souvent des boutons libellés différemment des conventions du site hôte. Examinez et, lorsque c’est possible, configurez les noms accessibles des tiers pour les aligner sur vos conventions de nommage, ou documentez l’écart comme une exception connue.
• Utiliser le texte d’infobulle (attribut title) comme seul nom accessible dans certains cas mais aria-label dans d’autres : L’attribut title n’est pas annoncé de manière fiable par toutes les technologies d’assistance et est considéré comme une source de nom accessible faible. Si certaines instances d’un composant répété utilisent title et d’autres aria-label, les noms calculés peuvent différer en raison des différences de gestion entre navigateurs et lecteurs d’écran.
• Supposer que les contrôles de pagination sont exemptés parce que leurs numéros diffèrent : Les contrôles « Next page » et « Previous page », même lorsqu’ils comportent un numéro de page dans leur libellé (par exemple, « Go to page 3 »), doivent appliquer un modèle cohérent. Mélanger « Next » sur certaines pages avec « Next page » ou « İleri » sur d’autres pour le même contrôle de pagination enfreint le critère 3.2.4.
• Ne pas tester les composants d’en-tête et de pied de page sur chaque gabarit de page distinct : Les sites ont souvent plusieurs gabarits de page (page d’accueil, page de catégorie, page d’article, paiement). Les composants d’en-tête et de pied de page peuvent s’afficher légèrement différemment selon les gabarits. Les testeurs qui ne vérifient qu’un ou deux gabarits peuvent manquer des incohérences introduites par des substitutions spécifiques à certains gabarits.
• Confondre 3.2.4 avec 3.2.3 (Navigation cohérente) : Les équipes pensent parfois que si l’ordre de navigation est cohérent (3.2.3), la dénomination doit l’être aussi — mais il s’agit d’exigences distinctes. Une barre de navigation au même emplacement sur chaque page (conformité 3.2.3) peut tout de même enfreindre le critère 3.2.4 si ses liens sont libellés différemment d’une page à l’autre. Traitez explicitement les deux critères dans votre processus d’assurance qualité.

Lien avec la réglementation turque en matière d’accessibilité

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences d’accessibilité contraignantes pour un large éventail de services numériques publics et privés. La circulaire impose la conformité à des normes d’accessibilité reconnues au niveau international — s’alignant en pratique sur les WCAG 2.2 niveau AA — et lie cette conformité au logo d’accessibilité (Erişilebilirlik Logosu) délivré par le ministère de la Famille et des Services sociaux (Aile ve Sosyal Hizmetler Bakanlığı).

Le critère 3.2.4 des WCAG, Identification cohérente, est un critère de niveau AA, ce qui signifie qu’il s’agit d’une exigence obligatoire — et non d’une recommandation facultative — pour les organisations qui souhaitent obtenir ou conserver l’Erişilebilirlik Logosu. Le fait de ne pas mettre en œuvre une identification cohérente sur un service numérique empêchera une conformité complète au niveau AA et, par conséquent, l’éligibilité au logo.

La circulaire couvre explicitement les types d’entités suivants, qui doivent tous traiter le critère 3.2.4 des WCAG dans leurs interfaces web et mobiles : institutions publiques et agences gouvernementales ; banques et prestataires de services financiers ; hôpitaux et plateformes de santé ; opérateurs de télécommunications comptant 200,000 abonnés ou plus ; plateformes de e-commerce ; agences de voyage et services de réservation ; entreprises de transport privé ; et écoles privées autorisées par le ministère de l’Éducation nationale (Milli Eğitim Bakanlığı).

Pour ces organisations, l’implication pratique est significative. Les grands sites institutionnels — tels que le portail de banque en ligne d’une banque, le système de prise de rendez-vous d’un hôpital ou le système d’information des étudiants d’une université — s’étendent généralement sur des centaines de pages et sont construits par plusieurs équipes de développement sur de nombreuses années. L’étiquetage incohérent de contrôles répétés (boutons d’action sur les comptes, barres de recherche, icônes de navigation) sur ces pages est un mode de défaillance courant et facilement négligé. Les programmes de conformité doivent inclure des audits de cohérence inter-pages comme phase de test dédiée, et pas seulement des analyses automatisées page par page.

Les organisations turques qui visent l’Erişilebilirlik Logosu devraient intégrer les vérifications du critère 3.2.4 des WCAG dans la gouvernance de leur design system, leurs flux de travail de gestion de contenu et leurs pipelines de QA. Plus précisément, chaque composant d’interface réutilisable devrait avoir son nom accessible défini comme une constante non modifiable au niveau du design system, avec des clés de traduction gérées de manière centralisée pour garantir que les versions turques et toute autre variante linguistique restent cohérentes sur toutes les pages et tous les gabarits où le composant apparaît.