Un bouton porte l’inscription « Envoyer le message ». Une utilisatrice de commande vocale dit « Cliquez sur Envoyer le message ». Rien ne se passe. Le logiciel de reconnaissance vocale compare ce qu’elle a prononcé au nom accessible exposé par le bouton, pas à son apparence. Si ce nom accessible ne contient pas la totalité du texte visible, la commande échoue, et l’utilisatrice n’a aucun moyen de comprendre pourquoi.
Ce défaut porte un nom précis dans les référentiels : le critère 2.5.3 « Nom dans le texte visible » (Label in Name) de la norme WCAG 2.1, niveau A. Il est souvent introduit sans intention de nuire, par un développeur qui cherche à enrichir le contexte d’un bouton pour un lecteur d’écran, et qui finit par masquer le texte qu’il voulait justement clarifier.
Ce qu’on voit dans le code
Le marquage suivant est fréquent dans les thèmes WordPress qui personnalisent leurs boutons d’appel à l’action :
<button aria-label="Confirmer et passer à l'étape suivante du tunnel">
Envoyer
</button>
Visuellement, le bouton affiche « Envoyer ». Techniquement, son nom accessible restitué aux technologies d’assistance devient « Confirmer et passer à l’étape suivante du tunnel », car l’attribut aria-label remplace intégralement le contenu textuel de l’élément dans le calcul du nom accessible (spécification Accessible Name and Description Computation du W3C). Le mot « Envoyer » a disparu de ce nom.
Pourquoi c’est un problème concret
Trois publics sont directement pénalisés. D’abord les utilisateurs de logiciels de commande vocale (Dragon NaturallySpeaking, ou la commande vocale intégrée à Windows et macOS), qui prononcent le texte affiché pour activer un contrôle : si ce texte ne figure pas dans le nom accessible, la commande ne trouve rien à activer. Ensuite les utilisateurs de lecteurs d’écran qui basculent entre une lecture visuelle partagée avec un accompagnant et une lecture vocale : l’incohérence entre ce qui s’affiche et ce qui s’annonce sème la confusion. Enfin les testeurs eux-mêmes, qui peuvent valider un audit automatisé (un nom accessible existe bel et bien) tout en laissant passer un vrai obstacle d’usage.
Le critère 2.5.3 est particulièrement insidieux parce qu’il ne déclenche presque jamais d’alerte dans les outils d’audit automatisés généralistes. Un bouton avec aria-label renseigné passe la plupart des vérifications de présence de nom accessible. Seule une vérification manuelle, ou un outil spécialisé qui compare le texte du nœud à l’attribut, révèle l’écart.
Ce qu’on repère en revue de code
- Un
aria-labelplus long ou différent du texte visible du bouton ou du lien - Un
aria-labelledbyqui pointe vers un élément dont le contenu ne reprend pas le texte affiché - Des composants React ou Vue qui injectent un libellé dynamique dans
aria-labelsans le synchroniser avec le rendu visuel - Des boutons d’icônes personnalisés où le texte visible caché en CSS (
clip, positionnement hors écran) diffère duaria-labelajouté « pour faire bonne mesure »
Quoi faire à la place
La correction la plus sûre consiste à ne pas utiliser aria-label du tout lorsque le texte visible suffit déjà à décrire l’action. Le nom accessible sera alors calculé directement à partir du contenu textuel du bouton, sans risque de divergence :
<button>
Envoyer
</button>
Quand un contexte supplémentaire est réellement utile (plusieurs boutons « Envoyer » sur une même page, chacun lié à un formulaire différent), la bonne pratique consiste à faire commencer ou terminer le nom accessible par le texte visible, jamais à le remplacer :
<button aria-label="Envoyer le formulaire de contact">
Envoyer
</button>
Ici, le mot « Envoyer » apparaît toujours dans le nom accessible complet ; la commande vocale « Cliquez sur Envoyer » continue de fonctionner, tandis que les lecteurs d’écran restituent un contexte plus riche.
Sur nos projets, nous avons pris l’habitude de bannir purement et simplement
aria-labelsur les boutons dont le texte est déjà explicite. Le réflexe « j’ajoute un aria-label pour être plus accessible » cause plus de régressions WCAG 2.5.3 qu’il n’en résout.
En résumé
Le critère WCAG 2.5.3 rappelle une règle simple mais rarement vérifiée : le nom accessible d’un composant interactif doit contenir le texte que l’utilisateur voit et peut prononcer. Un aria-label ajouté sans discipline peut satisfaire un audit automatisé tout en cassant l’usage réel pour les technologies de commande vocale. La vérification est rapide à outiller : comparer, pour chaque bouton et chaque lien, le texte du nœud DOM et la valeur calculée du nom accessible, puis s’assurer que le second contient le premier. Ce contrôle mérite sa place dans toute checklist de recette avant mise en production d’un thème ou d’une extension WordPress.
