aria-label et aria-labelledby : le guide complet RGAA

Un bouton icône sans nom accessible, un aria-label qui écrase le texte visible, un aria-labelledby qui pointe vers un identifiant supprimé depuis : ces trois erreurs représentent l'essentiel des problèmes ARIA rencontrés en audit. Ce guide explique comment le navigateur choisit le nom accessible, lequel des attributs utiliser selon la situation, et les conditions que le RGAA ajoute dès que l'étiquette cesse d'être visible.

Le nom accessible : l'ordre de priorité appliqué par le navigateur

Chaque élément interactif porte un nom accessible : le texte restitué par un lecteur d'écran ou une commande vocale. Le navigateur le calcule en parcourant des étapes dans un ordre fixe et s'arrête à la première qui produit un résultat.

La spécification Accessible Name and Description Computation du W3C fixe cet ordre à la section 4.3.2 :

Deux conséquences pratiques souvent ignorées. D'abord, aria-label écrase l'étiquette native : un <input> correctement associé à son <label> verra celui-ci ignoré si un aria-label traîne sur le champ. Ensuite, title arrive en dernier : il ne sert de nom accessible que si absolument rien d'autre n'est disponible.

aria-label : nommer un élément sans texte visible

aria-label définit le nom accessible directement dans l'attribut. Le texte n'apparaît jamais à l'écran.

Son cas d'usage légitime est étroit : un élément interactif dont le design n'affiche aucun texte.

<!-- Sans nom accessible : annoncé « bouton », rien de plus -->
<button>
  <svg><!-- icône hamburger --></svg>
</button>

<!-- Avec aria-label, icône masquée car devenue décorative -->
<button aria-label="Ouvrir le menu de navigation">
  <svg aria-hidden="true"><!-- icône hamburger --></svg>
</button>

L'attribut sert aussi à distinguer deux régions de même nature :

<nav aria-label="Navigation principale">...</nav>
<nav aria-label="Fil d'Ariane">...</nav>

Attention à sa portée réelle : aria-label n'est restitué de façon fiable que sur les éléments interactifs et sur ceux qui portent un rôle ARIA acceptant un nom. Sur une <div> nue, il est ignoré. Sur une image, c'est alt qui fait foi.

aria-labelledby : réutiliser un texte déjà affiché

aria-labelledby ne contient pas de texte mais un ou plusieurs identifiants. Le contenu des éléments référencés devient le nom accessible.

<h2 id="titre-contact">Nous contacter</h2>
<form aria-labelledby="titre-contact">
  <!-- Le formulaire est nommé « Nous contacter » -->
</form>

La concaténation de plusieurs identifiants permet de composer un nom à partir de fragments existants, dans l'ordre où ils sont listés :

<span id="lbl-prenom">Prénom</span>
<span id="lbl-requis">(obligatoire)</span>
<input type="text" aria-labelledby="lbl-prenom lbl-requis">
<!-- Restitué : « Prénom (obligatoire) » -->

L'avantage décisif tient à la maintenance. Le texte n'existe qu'à un seul endroit : il suit les corrections, les traductions et les tests de non-régression sans effort supplémentaire. Un aria-label se duplique, se périme en silence et échappe souvent aux fichiers de traduction.

aria-label ou title : lequel choisir

Ces trois attributs sont régulièrement confondus alors qu'ils répondent à des besoins distincts.

title cumule quatre limites qui le disqualifient comme choix de conception : l'infobulle ne s'affiche qu'au survol souris, elle est inatteignable au clavier, elle n'existe pas sur écran tactile, et sa restitution par les lecteurs d'écran varie d'un produit et d'une configuration à l'autre.

Le troisième attribut du tableau relève d'un autre besoin : il ne donne pas le nom, il ajoute une description par-dessus. Consignes de saisie, format attendu, message d'erreur rattaché à un champ. Son implémentation, ses pièges et sa différence avec aria-details sont traités dans notre guide dédié à aria-describedby, qui est la référence à consulter dès que le sujet dépasse le simple nommage.

Ce que le RGAA exige en plus quand l'étiquette n'est pas visible

C'est le point que la documentation francophone traite rarement, et il change la façon de concevoir un formulaire.

Le test 11.1.1 du RGAA 4.1.2 accepte plusieurs solutions au choix pour étiqueter un champ : aria-labelledby référençant un passage de texte identifié, aria-label, une balise <label for>, un attribut title, ou un bouton adjacent fournissant l'étiquette.

Mais le test 11.1.3 ajoute une condition dès que l'étiquette n'est plus visible ou plus accolée au champ, ce qui est exactement le cas avec aria-label. Le champ doit alors vérifier l'une de ces conditions :

• un attribut title dont le contenu permet de comprendre la nature de la saisie attendue ;
• un passage de texte accolé au champ qui devient visible à la prise de focus ;
• un passage de texte visible accolé au champ.

Autrement dit : remplacer un <label> visible par un aria-label ne fait pas disparaître l'exigence, elle la déplace. Le champ doit toujours offrir une information compréhensible aux personnes qui voient l'écran.

Le test 11.2.3 ferme la boucle : l'étiquette implémentée via aria-label doit permettre de connaître la fonction exacte du champ. Un aria-label="champ" est formellement présent et matériellement inutile.

Les critères concernés par ces attributs, avec leur correspondance WCAG :

Les erreurs les plus fréquentes

Doubler un texte déjà correct. <button aria-label="Envoyer">Envoyer</button> n'apporte rien et introduit un risque de désynchronisation à la première correction de libellé. Le contenu textuel suffit.

Contredire le texte visible. Le critère WCAG 2.5.3 « Étiquette dans le nom » (AA) demande que le texte affiché soit contenu dans le nom accessible. <button aria-label="valider le formulaire">Envoyer</button> empêche un utilisateur de commande vocale de dire « cliquer Envoyer ».

Référencer un identifiant absent. Un aria-labelledby qui pointe vers un id supprimé ou renommé ne produit aucun nom, sans le moindre message d'erreur. C'est la panne silencieuse typique des refontes.

Oublier aria-hidden sur l'icône. Si le SVG du bouton contient une balise <title>, elle peut s'ajouter au nom et provoquer une double annonce.

Poser un aria-label sur une image. L'attribut alt reste la solution attendue, et c'est lui que le RGAA évalue au critère 1.3.

Reste à savoir lesquelles de ces erreurs sont présentes sur vos pages. La présence d'une étiquette (critère 11.1) fait partie des points qu'un scan tranche seul, sans intervention humaine. Sa pertinence (critère 11.2) n'en fait pas partie et n'en fera jamais partie : juger qu'un aria-label décrit la fonction exacte d'un champ suppose de comprendre ce que ce champ attend de l'utilisateur.

Deux prolongements utiles selon votre cas : les règles d'étiquetage des champs sont détaillées dans notre article sur les labels de formulaire, et le cas particulier des éléments masqués aux technologies d'assistance dans celui sur aria-hidden.

Un audit automatisé vous rend donc la liste des champs, liens et boutons sans nom accessible, puis la consigne de contrôle à dérouler pour juger les autres.

Analyser les étiquettes de votre page →