Les labels ARIA font partie des outils les plus mal compris en accessibilite web. Face a un element qui a besoin d'un nom accessible, le reflexe de beaucoup de developpeurs est de coller un aria-label dessus. Et dans bien des cas, ce reflexe cree plus de problemes qu'il n'en resout. Selon l'analyse annuelle WebAIM, les pages qui utilisent ARIA presentent en moyenne 41 pour cent d'erreurs d'accessibilite de plus que celles qui n'en utilisent pas. Ce chiffre ne dit pas que ARIA est mauvais. Il dit que la plupart des developpeurs l'utilisent mal. Ce guide passe en revue chaque attribut ARIA de labellisation, explique quand chacun est le bon choix, couvre les erreurs qui piegent meme les profils experimentees, et fournit des patterns de code applicables immediatement. Que vous corrigiez un site existant pour la conformite a la directive europeenne sur l'accessibilite ou que vous construisiez une nouvelle application, bien maitriser les labels ARIA est fondamental pour reussir tout audit WCAG 2.2.
Ce que font reellement les labels ARIA (et ce qu'ils ne font pas)
ARIA signifie Accessible Rich Internet Applications. La specification WAI-ARIA, maintenue par le W3C, fournit un ensemble d'attributs qui modifient la maniere dont les elements apparaissent dans l'arbre d'accessibilite du navigateur. C'est cet arbre que les lecteurs d'ecran, les logiciels de commande vocale et les autres technologies d'assistance utilisent pour presenter votre interface aux personnes qui ne peuvent pas la voir ou interagir visuellement avec elle.
Un label ARIA donne a un element son nom accessible. Quand un lecteur d'ecran rencontre un bouton, il annonce ce nom accessible pour que l'utilisateur sache ce que le bouton fait. Si ce nom est faux, absent ou pretant a confusion, l'utilisateur ne peut pas utiliser l'interface ou fait des suppositions incorrectes.
Trois attributs gerent l'essentiel du travail de labellisation ARIA : aria-label, aria-labelledby et aria-describedby. Chacun se comporte differemment, et choisir le mauvais dans une situation donnee est l'une des erreurs d'accessibilite les plus frequentes que notre verificateur detecte sur des milliers de sites scannes.
Point important : les labels ARIA ne changent rien visuellement. Ajouter aria-label sur un bouton n'ajoute pas de texte visible. Cela change uniquement ce que la technologie d'assistance annonce. Les utilisateurs voyants et les utilisateurs de lecteurs d'ecran peuvent finir par percevoir des interfaces completement differentes quand ARIA est utilise sans rigueur.
Les cinq regles d'ARIA a connaitre absolument
Avant de plonger dans les attributs specifiques, ces cinq regles du W3C gouvernent toute utilisation d'ARIA. En enfreindre une, c'est risquer de rendre votre interface moins accessible, pas plus.
Regle un : si vous pouvez utiliser un element HTML natif avec la semantique et le comportement dont vous avez besoin, faites-le au lieu d'ajouter ARIA. Un element button natif possede deja un role implicite de bouton, repond aux evenements clavier, et tire son nom accessible de son contenu texte. Un div avec role button et aria-label vous oblige a repliquer tout cela manuellement.
Regle deux : ne changez pas la semantique native sans raison valable. Ajouter role presentation a un titre supprime sa semantique de titre de l'arbre d'accessibilite.
Regle trois : tous les controles ARIA interactifs doivent etre utilisables au clavier. Si vous creez une case a cocher personnalisee avec role checkbox, vous devez aussi gerer le basculement par la barre d'espace, la gestion du focus et l'etat aria-checked.
Regle quatre : ne mettez pas role presentation ou aria-hidden true sur un element focusable. Un element qui peut recevoir le focus clavier mais est masque de l'arbre d'accessibilite cree un controle fantome.
Regle cinq : tout element interactif doit avoir un nom accessible. C'est la que aria-label, aria-labelledby et le contenu texte natif entrent en jeu.
aria-label : quand et comment l'utiliser correctement
L'attribut aria-label fournit une chaine de texte comme nom accessible pour un element. Les lecteurs d'ecran annoncent cette chaine a la place de tout autre contenu texte que l'element pourrait contenir.
Utilisez aria-label quand un element interactif n'a pas de texte visible et qu'aucun autre mecanisme ne fournit de nom accessible. L'exemple classique est le bouton a icone. Un bouton de fermeture qui ne contient qu'une icone X ou un SVG a besoin de aria-label="Fermer" pour que les lecteurs d'ecran annoncent bouton Fermer plutot que simplement bouton.
Autre cas d'usage valide : distinguer des landmarks de navigation repetes. Si votre page a deux elements nav, ajouter aria-label="Navigation principale" et aria-label="Fil d'Ariane" permet aux utilisateurs de lecteurs d'ecran de sauter au bon endroit.
Voila ou les developpeurs se trompent. N'utilisez pas aria-label sur des elements qui ont deja du texte visible. Si votre bouton dit Envoyer, ajouter aria-label="Envoyer le formulaire" cree une divergence. Sous le critere WCAG 2.2 2.5.3 Etiquette dans le nom, le nom accessible doit contenir le texte visible. Les utilisateurs de commande vocale qui disent clic envoyer ne pourront pas activer un bouton dont le nom accessible est envoyer le formulaire.
Une limitation critique : aria-label n'est pas traduit par les outils de traduction des navigateurs. Chrome, Edge et Firefox ignorent tous les valeurs aria-label lors de la traduction d'une page. En France, le RGAA 4.1 (referentiel general d'amelioration de l'accessibilite) s'aligne sur WCAG 2.1 AA et insiste sur la coherence entre le texte visible et le nom accessible. Pour les sites multilingues, privilegiez le texte visible ou aria-labelledby referencant du texte visible.
aria-labelledby : l'alternative preferee
L'attribut aria-labelledby definit le nom accessible en referencant l'id d'un ou plusieurs elements dont le contenu texte sert de nom. Il est plus robuste que aria-label pour plusieurs raisons.
Premierement, puisque aria-labelledby reference du texte visible sur la page, les outils de traduction du navigateur traduisent le texte reference. Les utilisateurs de lecteurs d'ecran obtiennent un nom accessible traduit automatiquement.
Deuxiemement, aria-labelledby synchronise automatiquement le texte visible et les noms accessibles. Si quelqu'un met a jour le texte d'un titre, le nom accessible se met a jour avec.
Troisiemement, aria-labelledby peut concatener le texte de plusieurs elements en listant plusieurs IDs separes par des espaces. Un dialogue dont le titre dit Supprimer et le sous-titre dit Voulez-vous vraiment supprimer ce fichier peut utiliser aria-labelledby referencant les deux elements.
Utilisez aria-labelledby quand du texte visible existe deja et pourrait servir de nom accessible. Les patterns courants incluent le labelling de sections par leur titre, le labelling de modales par leur element titre, et le labelling de groupes de formulaire.
Comportement de priorite important : aria-labelledby a la priorite sur aria-label et sur les mecanismes natifs comme l'element label. N'utilisez qu'un seul mecanisme de labellisation par element pour eviter toute confusion.
aria-describedby : ajouter du contexte sans changer le nom
L'attribut aria-describedby est souvent confondu avec aria-labelledby mais remplit un role different. Il ne definit pas le nom accessible. Il ajoute une description que les lecteurs d'ecran annoncent apres le nom.
Quand un lecteur d'ecran rencontre un champ avec un label Mot de passe et un aria-describedby pointant vers un texte Doit contenir au moins 8 caracteres dont un chiffre, l'annonce est Mot de passe, zone de saisie, Doit contenir au moins 8 caracteres dont un chiffre. Le nom est Mot de passe. La description fournit le contexte supplementaire.
Utilisez aria-describedby pour les instructions de champs de formulaire, les exigences de format, les messages d'erreur lies a des champs specifiques, et les informations complementaires qui aident l'utilisateur a comprendre un controle sans changer son identite.
Pattern courant pour la validation de formulaire : quand l'utilisateur soumet un formulaire avec des erreurs, chaque champ invalide recoit aria-describedby pointant vers son message d'erreur.
N'utilisez pas aria-describedby comme substitut de aria-label ou aria-labelledby. Un element sans nom accessible mais avec un aria-describedby reste sans nom. Les raccourcis de navigation des lecteurs d'ecran qui listent tous les boutons ou liens d'une page n'affichent que les noms accessibles, pas les descriptions.
Erreurs ARIA courantes et comment les corriger
Apres avoir scanne plus de dix mille sites, certaines erreurs ARIA reviennent systematiquement. Voici celles qui causent le plus de problemes reels aux utilisateurs de lecteurs d'ecran.
Erreur un : aria-label sur des elements qui ont deja du texte visible. Un lien avec le texte visible En savoir plus et aria-label="En savoir plus sur nos tarifs" cree une divergence. Les utilisateurs de commande vocale disent clic en savoir plus et rien ne se passe. Correction : soit rendez le texte visible assez descriptif, comme En savoir plus sur nos tarifs, soit supprimez l'aria-label et utilisez du texte visuellement masque ajoute au texte du lien.
Erreur deux : aria-label sur un div ou span sans role. Un div avec aria-label="Description du produit" mais sans attribut role voit ce label ignore par la plupart des lecteurs d'ecran. Correction : ajoutez un role approprie ou, mieux, utilisez un element semantique.
Erreur trois : dupliquer le contenu entre aria-label et le texte visible. Un bouton contenant le texte Rechercher et portant aussi aria-label="Rechercher" est redondant. Le contenu texte natif fournit deja le nom accessible.
Erreur quatre : utiliser aria-label au lieu d'un element label pour les champs de formulaire. Un input avec aria-label="Email" mais sans label visible signifie que les utilisateurs voyants n'ont pas d'etiquette non plus. Correction : utilisez un element label associe via l'attribut for.
Erreur cinq : references aria-labelledby cassees. Un attribut aria-labelledby pointant vers un id inexistant dans le DOM ne produit aucun nom accessible. Cela arrive souvent apres un refactoring. Notre verificateur d'accessibilite detecte automatiquement les references cassees.
Erreur six : utiliser aria-label sur des landmarks sans rendre les labels uniques. Trois elements nav tous avec aria-label="Navigation" ne permettent pas de les distinguer.
Patterns ARIA concrets pour composants courants
La theorie c'est bien. Les patterns fonctionnels c'est mieux. Voici les approches de labellisation ARIA pour les composants qui posent le plus de problemes d'accessibilite.
Boutons a icone. Chaque bouton contenant uniquement une icone a besoin d'un nom accessible. L'approche la plus robuste est d'inclure du texte visuellement masque dans l'element bouton, comme un span avec une classe visually-hidden contenant le texte Fermer. Ce texte est traduit, fonctionne avec la commande vocale, et fournit le nom accessible sans aria-label.
Dialogues modaux. Donnez au dialogue role dialog et aria-labelledby pointant vers son element titre. Ajoutez aria-modal true pour indiquer que le contenu derriere le dialogue est inerte. Gerez le focus : deplacez-le vers le premier element focusable a l'ouverture, emprisonnez-le dans le dialogue, et renvoyez-le vers l'element declencheur a la fermeture.
Landmarks de navigation. Utilisez l'element nav natif. Si vous en avez plusieurs, labellisez chacun avec aria-label. Le menu principal recoit aria-label="Navigation principale". Un sommaire lateral recoit aria-label="Sommaire".
Groupes de formulaire. Utilisez fieldset et legend pour les groupes de controles lies comme les boutons radio. Le legend fournit le label du groupe. Ne remplacez pas ce pattern par un div avec aria-label.
Tableaux de donnees. Utilisez l'element caption ou aria-labelledby pour nommer le tableau. Chaque cellule d'en-tete doit utiliser l'element th.
Regions dynamiques. Utilisez aria-live polite pour les mises a jour non urgentes. Utilisez aria-live assertive pour les messages urgents comme les alertes d'erreur.
Interfaces a onglets. Le conteneur recoit role tablist. Chaque onglet recoit role tab et aria-selected. Le panneau recoit role tabpanel et aria-labelledby referencant son onglet associe.
Tester vos labels ARIA
Ecrire du ARIA correct c'est la moitie du travail. Verifier que ca fonctionne c'est l'autre moitie.
Commencez par un scan automatise. Passez vos pages dans notre verificateur d'accessibilite gratuit sur web-accessibility-checker.com. Il detecte les noms accessibles manquants, les references aria-labelledby cassees, les aria-label sur des elements non interactifs, et les labels de landmarks dupliques.
Ensuite ouvrez l'arbre d'accessibilite du navigateur. Dans les DevTools Chrome, ouvrez le panneau Elements, selectionnez un element et consultez l'onglet Accessibilite. Il montre le nom accessible calcule et sa provenance.
Testez avec un lecteur d'ecran. NVDA sur Windows et VoiceOver sur macOS sont gratuits. Naviguez la page et ecoutez les annonces. Chaque bouton, lien, champ de formulaire, landmark et dialogue a-t-il un nom comprehensible hors contexte visuel ?
Verifiez la navigation clavier. Chaque element qui porte un label ARIA doit etre atteignable au clavier.
Testez sur plusieurs lecteurs d'ecran. NVDA, JAWS, VoiceOver et TalkBack interpretent chacun ARIA legerement differemment. Les tests croises revelent les divergences.