WCAG 2.5.3 : Étiquette dans le nom

Ce que signifie cette règle

\n

WCAG 2.5.3 — Label in Name (Intitulé dans le nom) — s’applique à tout composant d’interface utilisateur qui possède une étiquette textuelle visible. Le critère exige que le nom accessible de ce composant corresponde exactement au texte de l’étiquette visible ou, au minimum, contienne le texte de l’étiquette visible comme sous-chaîne. Cela évite qu’un utilisateur voie une étiquette à l’écran alors que sa technologie d’assistance ou son logiciel de reconnaissance vocale reconnaît un nom complètement différent en arrière-plan.

\n

Le nom accessible est le nom exposé à l’arborescence d’accessibilité et utilisé par les lecteurs d’écran, les logiciels de commande vocale et d’autres technologies d’assistance. Il peut provenir de diverses sources, notamment le contenu textuel visible de l’élément, un attribut aria-label, une référence aria-labelledby, un attribut title ou un élément <label> associé. Lorsqu’un développeur remplace le nom accessible par quelque chose qui n’inclut pas le texte de l’étiquette visible, un décalage se produit et le critère n’est pas respecté.

\n

Les éléments concernés incluent tout composant interactif qui affiche du texte et possède également un nom accessible : boutons, liens, champs de formulaire avec étiquettes visibles, éléments de menu, onglets, cases à cocher, boutons radio et widgets ARIA personnalisés. Les éléments non interactifs tels que les paragraphes ou les titres ne sont pas couverts par ce critère.

\n

Ce qui est considéré comme conforme : Le nom accessible contient le texte de l’étiquette visible comme sous-chaîne continue, en ignorant les espaces au début et à la fin. La correspondance n’est pas sensible à la casse. Par exemple, si un bouton affiche « Search Products », un nom accessible « Search Products Now » est conforme car il contient « Search Products ». Un nom accessible « Find Products » n’est pas conforme car il ne contient pas le texte visible.

\n

Ce qui est considéré comme non conforme : Le nom accessible est complètement différent de l’étiquette visible, ou le nom accessible omet une partie significative de l’étiquette visible. Un bouton qui affiche visuellement « Buy Now » mais qui a aria-label='Purchase item' ne respecte pas ce critère. De même, un lien qui affiche « Contact Us » mais est enveloppé dans un élément avec aria-label='Reach our team' n’est pas conforme non plus.

\n

Exceptions officielles définies dans les WCAG : Le critère ne s’applique pas aux composants dont l’étiquette est purement symbolique ou pictographique sans équivalent textuel (par exemple, un bouton composé uniquement d’une icône sans texte visible). Il ne s’applique pas non plus lorsque le texte fait partie d’un élément purement décoratif qui ne porte aucune signification sémantique. La notation mathématique et les scénarios spécifiques à certaines langues où la représentation textuelle ne peut pas être associée à un mot prononcé sont également exclus. En outre, les composants dont le nom accessible est volontairement enrichi avec un contexte supplémentaire — à condition que le texte visible soit toujours présent dans le nom accessible — sont conformes.

\n\n

Pourquoi c’est important

\n

Ce critère protège principalement les personnes qui s’appuient sur des logiciels de reconnaissance vocale tels que Dragon NaturallySpeaking (désormais Dragon Professional), Windows Speech Recognition ou Voice Control d’Apple. Ces personnes naviguent et activent les éléments de l’interface en prononçant l’étiquette qu’elles voient à l’écran. Lorsque le nom accessible ne correspond pas à l’étiquette visible, le logiciel ne peut pas trouver l’élément cible lorsque l’utilisateur prononce son nom, ce qui rend effectivement le contrôle inatteignable sans souris ni clavier. Pour les personnes ayant des limitations motrices — y compris celles souffrant de troubles musculo-squelettiques, de dystrophie musculaire, de paralysie cérébrale ou de lésions de la moelle épinière — la saisie vocale est souvent leur moyen principal, voire unique, d’utiliser un ordinateur. Un décalage sur un seul bouton peut bloquer l’accès à tout un parcours.

\n

Les utilisateurs de lecteurs d’écran sont également concernés. Lorsqu’un lecteur d’écran annonce un nom accessible différent de ce qui est visible à l’écran, cela crée une désorientation cognitive. Une personne voyante qui utilise aussi un lecteur d’écran — par exemple, une personne malvoyante qui utilise simultanément un retour visuel et auditif — peut entendre une chose annoncée tout en lisant quelque chose de différent à l’écran, ce qui perturbe son modèle mental de l’interface.

\n

Les personnes ayant des troubles cognitifs bénéficient de la cohérence entre ce qu’elles lisent et ce qui est prononcé ou annoncé. Des changements de nom inattendus augmentent la charge cognitive et peuvent provoquer confusion ou erreurs, en particulier pour les personnes ayant des troubles de la mémoire ou celles qui apprennent à utiliser un système pour la première fois.

\n

Un scénario concret : Imaginez une page de paiement e-commerce avec un bouton qui affiche visuellement le texte « Place Order ». Un développeur ajoute aria-label='Submit purchase form' pour fournir ce qu’il considère comme un nom plus descriptif. Une cliente utilisant Dragon NaturallySpeaking dit « Click Place Order » — Dragon analyse l’arborescence d’accessibilité, ne trouve aucun élément nommé « Place Order » et ne peut pas activer le bouton. La cliente ne peut pas finaliser son achat sans passer à la souris, ce qu’elle n’est peut-être pas en mesure de faire. Elle abandonne la transaction. Ce n’est pas un cas limite hypothétique ; c’est un schéma d’échec courant relevé lors d’audits automatisés sur des sites de vente en ligne et de banque.

\n

Selon l’Organisation mondiale de la Santé, plus d’un milliard de personnes dans le monde vivent avec une forme de handicap. Le rapport WebAIM Million 2023 a constaté que les décalages d’intitulé WCAG 2.5.3 apparaissaient dans une proportion significative de pages auditées, souvent introduits par de l’ARIA bien intentionné mais mal appliqué. Au-delà de l’accessibilité, une labellisation cohérente améliore le SEO, car les robots d’indexation des moteurs de recherche qui analysent le texte des liens et des boutons pour le classement de pertinence reçoivent des signaux plus significatifs lorsque les noms accessibles sont alignés sur le texte visible.

\n\n

Règles Axe-core associées

\n

\n
• label-content-name-mismatch : Il s’agit de la principale règle automatisée associée à WCAG 2.5.3. La règle vérifie les éléments interactifs — tels que les boutons, les liens et les rôles ARIA comme role='button', role='link', role='menuitem' et role='tab' — qui ont à la fois une étiquette textuelle visible et un nom accessible. Elle signale tout élément dont le nom accessible ne contient pas le texte visible comme sous-chaîne (sans tenir compte de la casse). La règle cible spécifiquement les éléments dont le nom accessible est remplacé par aria-label ou aria-labelledby d’une manière qui diverge du texte affiché à l’écran. Axe signale ces cas comme des violations avec un niveau d’impact « serious » car ils empêchent directement les utilisateurs de commande vocale d’activer les contrôles.
\n
• Limites de la détection automatisée : Les outils automatisés comme axe-core peuvent détecter de manière fiable les décalages lorsque le texte visible est rendu sous forme de nœuds de texte simples dans l’élément et que le nom accessible provient d’un attribut statique aria-label ou aria-labelledby. Cependant, des tests manuels sont nécessaires lorsque : (1) le texte visible est rendu via les pseudo-éléments CSS ::before ou ::after, car ceux-ci peuvent ou non être inclus dans l’arborescence d’accessibilité selon le navigateur et la version de la technologie d’assistance ; (2) l’étiquette est insérée dynamiquement via JavaScript après le chargement de la page ; (3) le texte visible inclut des icônes ou du texte sous forme d’image dont la composante textuelle doit être déduite ; (4) le nom accessible calculé de l’élément implique des chaînes aria-labelledby complexes qui concatènent plusieurs éléments. Dans ces cas, une personne testant avec un lecteur d’écran doit vérifier ce qui est réellement annoncé par rapport à ce qui est visible.
\n

\n\n

Comment tester

\n

\n
1. Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools (Chrome ou Firefox) ou lancez un audit d’accessibilité Lighthouse dans Chrome DevTools. Lancez l’analyse sur la page entièrement rendue — assurez-vous que le contenu dynamique, les modales et les menus développés sont ouverts s’ils contiennent des éléments interactifs. Dans le panneau de résultats axe, filtrez par l’ID de règle label-content-name-mismatch. Chaque élément signalé affichera son nom accessible calculé à côté du texte visible, ce qui rend le décalage immédiatement apparent. Notez le sélecteur de l’élément et inspectez le DOM pour identifier la source de la surcharge du nom accessible. Lighthouse fera remonter les mêmes échecs dans la catégorie « Accessibility » avec une référence à WCAG 2.5.3.
\n
2. Inspection manuelle avec les DevTools du navigateur : Ouvrez le panneau Accessibilité du navigateur (Chrome DevTools → Elements → onglet Accessibility, ou Firefox DevTools → onglet Accessibility). Sélectionnez chaque élément interactif qui possède du texte visible. Vérifiez, dans la section « Computed Properties », le champ Name de l’élément. Comparez cette valeur à l’étiquette visible. Si le nom calculé ne contient pas le texte de l’étiquette visible comme sous-chaîne, l’élément ne respecte pas 2.5.3.
\n
3. Test avec lecteur d’écran NVDA + Firefox : Ouvrez Firefox avec NVDA en cours d’exécution. Naviguez jusqu’à chaque élément interactif à l’aide de la touche Tab. Écoutez ce que NVDA annonce comme nom de l’élément. Notez toute différence entre le nom annoncé et le texte affiché à l’écran. Utilisez la liste des éléments de NVDA (Insert+F7) pour parcourir tous les liens et boutons et comparer en masse les noms annoncés aux étiquettes visuelles.
\n
4. Test avec lecteur d’écran JAWS + Chrome : Ouvrez Chrome avec JAWS en cours d’exécution. Parcourez tous les contrôles interactifs avec la touche Tab. JAWS annoncera le nom accessible suivi du rôle. Lorsque le nom annoncé n’inclut pas le texte visible, notez l’élément. Utilisez également le « mode navigation » de JAWS et le visualiseur virtuel pour voir le nom accessible calculé pour chaque contrôle.
\n
5. Test avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Commande+F5 sur macOS). Utilisez Tab ou VO+Flèche droite pour naviguer entre les éléments interactifs. VoiceOver annonce le nom accessible de chaque contrôle. Sur iOS, faites glisser un doigt vers la droite pour parcourir les éléments et écoutez les décalages entre nom et étiquette.
\n
6. Test de reconnaissance vocale avec Voice Control (macOS/iOS) ou Dragon : Activez Voice Control sur macOS (Réglages Système → Accessibilité → Voice Control). Dites « Show names » pour afficher les étiquettes de tous les éléments interactifs. Vérifiez que les étiquettes affichées par Voice Control correspondent au texte visible à l’écran. Essayez d’activer les contrôles en prononçant le texte de l’étiquette visible — tout contrôle qui ne répond pas à son nom visible constitue un échec 2.5.3. Répétez avec Dragon NaturallySpeaking sur Windows si possible, en utilisant la commande « Click [label] ».
\n

\n\n

Comment corriger

\n\n

Bouton avec aria-label qui remplace le texte — Incorrect

\n

<!-- FAIL: aria-label remplace complètement le texte visible \"Search\"\n     par \"Execute query\", ce qui casse la commande vocale -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Bouton avec aria-label qui remplace le texte — Correct

\n

<!-- PASS: Supprimer complètement l’aria-label non conforme.\n     Le texte visible du bouton \"Search\" devient automatiquement son nom accessible.\n     Les utilisateurs de commande vocale peuvent dire \"Click Search\" pour l’activer. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternative): Si un contexte supplémentaire est nécessaire,\n     assurez-vous que le nom accessible CONTIENT le texte visible. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Lien avec aria-labelledby pointant vers un texte sans rapport — Incorrect

\n

<!-- FAIL: aria-labelledby référence un titre \"Our Services\"\n     alors que le lien affiche visuellement \"Learn more\",\n     donc le nom accessible est \"Our Services\" plutôt que \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Lien avec aria-labelledby pointant vers un texte sans rapport — Correct

\n

<!-- PASS: Utiliser aria-labelledby pour concaténer le texte du lien avec le titre.\n     Le nom accessible devient \"Learn more Our Services\",\n     qui contient l’étiquette visible \"Learn more\". -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternative): Rendre le texte visible du lien auto-descriptif\n     pour qu’aucun remplacement ne soit nécessaire. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Bouton icône où aria-label est en conflit avec le texte visible — Incorrect

\n

<!-- FAIL: Le bouton affiche une icône de panier ET le texte \"Cart\".\n     L’aria-label 'View shopping basket' ne contient pas \"Cart\",\n     donc les utilisateurs qui disent \"Click Cart\" n’obtiennent aucune réponse. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Bouton icône où aria-label est en conflit avec le texte visible — Correct

\n

<!-- PASS: L’aria-label contient le texte visible \"Cart\" comme sous-chaîne.\n     Les utilisateurs peuvent dire \"Click Cart\" ou \"Click View Cart\" et les deux fonctionnent. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (préféré): Supprimer aria-label et masquer l’icône de l’arborescence.\n     Le texte du bouton \"Cart\" devient directement le nom accessible. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Champ de formulaire avec une étiquette visible mais un aria-label non concordant — Incorrect

\n\n

(Content truncated due to token limit — please retry this article.)