WCAG 2.5.3 Étiquette dans le nom

Le critère de succès 2.5.3 exige que, pour les composants d'interface dotés à la fois d'une étiquette textuelle visible et d'un nom accessible, ce nom accessible contienne le texte de l'étiquette visible. C'est un critère de niveau A sous la règle 2.5 (Modalités d'entrée), ajouté dans les WCAG 2.1.

Qui ce critère protège, et pourquoi l'écart compte

Les logiciels de saisie vocale - Dragon NaturallySpeaking, Contrôle vocal, Voice Access - permettent d'utiliser une interface en prononçant l'étiquette visible de l'élément visé : « cliquer sur Envoyer », « appuyer sur Rechercher ». Cela ne fonctionne que si le nom accessible de la commande - ce que les technologies d'assistance, y compris les logiciels de reconnaissance vocale, lisent réellement - correspond au texte affiché sur le bouton ou le contient. Si un bouton affiche « Rechercher » alors que son nom accessible, défini par aria-label, est en réalité « Envoyer les données du formulaire », une personne disant « cliquer sur Rechercher » ne déclenche aucune correspondance : la commande échoue silencieusement.

La cause courante : remplacer le nom accessible par un texte sans rapport

<!-- Le texte visible dit « Rechercher » mais le nom accessible est tout autre -->
<button aria-label="Trouver des articles dans notre catalogue">Rechercher</button>

Une personne utilisant un lecteur d'écran entend « Trouver des articles dans notre catalogue », une personne voyante lit « Rechercher », et une personne utilisant la commande vocale qui dit « cliquer sur Rechercher » n'obtient aucune correspondance : trois expériences différentes et déconnectées d'un même bouton.

La correction

Veillez à ce que tout aria-label - ou aria-labelledby - appliqué à un élément comportant par ailleurs un texte visible corresponde exactement à ce texte, ou le contienne au minimum :

<!-- Le nom accessible (aria-label) contient le texte visible -->
<button aria-label="Rechercher dans notre catalogue">Rechercher</button>

Pourquoi c'est une erreur fréquente et facile à éviter

Cette non-conformité survient généralement lorsqu'une personne ajoute un aria-label pour apporter un contexte supplémentaire, sans réaliser qu'il remplace entièrement le nom accessible calculé à partir du texte visible, au lieu de le compléter. Si l'objectif est seulement d'ajouter du contexte au-delà de l'étiquette visible, conserver le texte visible au début de l'aria-label, comme dans la correction ci-dessus, satisfait à la fois cet objectif et ce critère.

Références officielles

• Deque University : label-content-name-mismatch