Guide développeur des libellés ARIA qui aident vraiment

Les libellés ARIA servent aux noms, pas aux excuses

ARIA est utile, mais il est souvent utilisé comme rustine pour du HTML peu clair. C’est là que les équipes commencent à avoir des problèmes.

L’exemple le plus courant est aria-label. Il semble inoffensif : ajouter une chaîne, satisfaire un linter, passer à autre chose. Mais un nom accessible n’est pas un élément décoratif. C’est le nom que de nombreuses technologies d’assistance exposent aux utilisateurs lorsqu’ils naviguent par boutons, liens, champs de formulaire, titres, repères et contrôles.

Si ce nom est vague, dupliqué, obsolète ou différent du libellé visible, l’interface devient plus difficile à utiliser. Parfois pire : aria-label peut remplacer un meilleur texte qui était déjà présent dans le DOM.

L’objectif n’est pas d’ajouter plus d’ARIA. L’objectif est de rendre clairs le nom, le rôle, l’état et la finalité de chaque élément d’interface.

Le nom accessible, en langage simple

La plupart des éléments interactifs ont un nom accessible. Les lecteurs d’écran utilisent ce nom pour annoncer ce qu’est l’élément.

Par exemple :

<button>Save changes</button>

Un lecteur d’écran peut annoncer quelque chose comme : « Save changes, bouton. » Le rôle vient de l’élément natif button. Le nom vient du texte qu’il contient.

C’est le cas idéal : le texte visible et le nom accessible correspondent.

Les attributs de libellé ARIA deviennent utiles lorsque l’interface visible ne fournit pas un nom complet, ou lorsque le nom doit provenir d’un autre élément. Les principaux attributs sont :

• aria-label : fournit une chaîne directement sur l’élément.
• aria-labelledby : pointe vers un ou plusieurs éléments dont le texte devient le nom.
• aria-describedby : pointe vers un texte descriptif complémentaire, et non vers le nom principal.

Ces trois attributs sont liés, mais ils ne sont pas interchangeables.

Première règle : privilégier le HTML natif et les libellés visibles

Si vous pouvez mettre du texte visible sur le contrôle, faites-le d’abord.

Ceci est préférable :

<button>Delete invoice</button>

À ceci :

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Le second modèle est valide pour un bouton composé uniquement d’une icône. Mais si la conception peut tolérer du texte visible, ce texte aide tout le monde : les utilisateurs de lecteurs d’écran, les utilisateurs de reconnaissance vocale, les personnes soumises à une charge cognitive, celles qui parcourent rapidement la page et celles qui utilisent des outils de traduction.

C’est un thème récurrent dans le travail d’accessibilité. Le HTML natif et les affordances visibles résolvent plus de problèmes que les métadonnées cachées. Le même principe s’applique plus largement à la sémantique des boutons ; si votre équipe audite les contrôles d’interface, notre checklist for accessible web buttons complète bien ce guide.

Quand aria-label est le bon outil

Utilisez aria-label lorsqu’un élément a besoin d’un nom accessible et qu’il n’existe pas de texte visible approprié à référencer.

Le cas classique est le bouton uniquement composé d’une icône :

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

C’est raisonnable. L’icône visible suggère une recherche, mais le chemin SVG lui-même ne fournit pas un nom fiable. aria-label en fournit un.

Autres bons cas d’usage :

• Un bouton de fermeture représenté uniquement par un « X ».
• Un repère de navigation qui a besoin d’un nom plus précis, comme aria-label="Product".
• Un contrôle répété dont le contexte visible ne fait pas partie du texte du bouton.

Par exemple :

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Les deux sont des repères de navigation, mais leurs libellés aident les utilisateurs à les distinguer lorsqu’ils se déplacent par repères.

Quand aria-label n’est pas le bon outil

N’ajoutez pas aria-label simplement parce qu’un test indique qu’un élément a besoin d’un libellé. Corrigez d’abord le balisage.

Mauvais :

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Mieux :

<button>Submit</button>

Le premier exemple crée du travail inutile. Vous devez maintenant recréer le comportement au clavier, les états désactivés, le comportement de formulaire et les attentes que les boutons natifs fournissent déjà.

Évitez également d’utiliser aria-label pour renommer un texte visible d’une manière qui en change le sens.

<button aria-label="Delete invoice">Remove</button>

Cela peut sembler mineur, mais cela peut dérouter les utilisateurs qui s’appuient sur la saisie vocale. Si un bouton visible indique « Remove », mais que son nom accessible est « Delete invoice », un utilisateur qui essaie de dire « cliquer sur Remove » peut ne pas obtenir le résultat attendu. L’exigence « label in name » de WCAG existe précisément pour cette raison : le texte visible devrait généralement être contenu dans le nom accessible.

Une meilleure version :

<button aria-label="Remove invoice">Remove</button>

Souvent encore mieux :

<button>Remove invoice</button>

Utilisez aria-labelledby lorsque du texte visible existe déjà

Si le texte du libellé est déjà présent sur la page, aria-labelledby est généralement préférable à aria-label.

Exemple :

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Le nom accessible de la section provient maintenant du titre visible. Vous évitez de dupliquer des chaînes, ce qui réduit les erreurs de traduction et les libellés obsolètes.

C’est particulièrement utile pour les groupes de champs de formulaire :

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

Dans de nombreux cas, le legend natif suffit sans ARIA. L’idée est que les libellés visibles doivent guider. ARIA doit relier un sens existant, et non créer une seconde version privée de celui-ci.

Utilisez aria-describedby pour le texte d’aide, pas pour le nom

Une description n’est pas un libellé.

Considérez ce champ :

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Le nom accessible est « Password ». La description est « Use at least 12 characters. » Un lecteur d’écran peut annoncer les deux, mais ils ont des fonctions différentes.

Ne faites pas ceci :

<input type="password" aria-label="Use at least 12 characters">

Cela nomme le champ d’après l’instruction, et non d’après le concept. Un utilisateur qui navigue dans un formulaire veut d’abord savoir ce qu’est le champ, puis quelles contraintes s’appliquent.

Cette distinction compte aussi dans les états d’erreur :

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Le libellé reste stable. Le message d’erreur devient un contexte complémentaire.

Les contrôles répétés ont besoin de noms uniques

Les listes et les cartes sont des endroits où les libellés ARIA deviennent souvent nécessaires.

Mauvais :

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Un utilisateur de lecteur d’écran qui navigue par boutons peut entendre « Delete, bouton » trois fois, sans contexte.

Bon :

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

C’est une utilisation légitime de aria-label : le texte visible reste concis, tandis que le nom accessible inclut l’objet concerné.

Mais utilisez ce modèle avec prudence. Si le nom de l’objet est visible à proximité, aria-labelledby peut être plus maintenable :

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Le nom accessible devient « Delete Q4 revenue ». Cela évite de dupliquer le titre du rapport dans un attribut.

Ne libellez pas tout

Tous les éléments n’ont pas besoin d’un libellé ARIA.

Le texte statique n’en a généralement pas besoin. Les icônes décoratives non plus. Les conteneurs non plus, sauf s’ils ont un rôle significatif de repère ou de widget. Un excès de libellés peut rendre une page bruyante et plus difficile à parcourir.

Pour les images, utilisez le modèle propre aux images : les images significatives ont besoin d’un alt utile ; les images décoratives ont besoin d’un alt="" vide. N’utilisez pas les libellés ARIA comme substitut à un bon texte d’image. Si votre équipe mélange ces notions, revenez à pragmatic image alt text et séparez les alternatives d’image des noms de contrôles.

Une erreur courante consiste à donner un aria-label à chaque SVG. Si le SVG est à l’intérieur d’un bouton et que le bouton a déjà un nom, l’icône devrait généralement être masquée aux technologies d’assistance :

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Sinon, l’utilisateur peut entendre des annonces redondantes ou étranges selon la combinaison de navigateur et de technologie d’assistance.

Vérifiez le nom calculé, pas seulement le code

Les bogues d’accessibilité survivent souvent à la revue de code parce que le balisage semble plausible.

Les outils de développement des navigateurs modernes peuvent afficher l’arbre d’accessibilité calculé. Dans Chrome, Edge, Firefox et Safari, inspectez l’élément et recherchez les informations d’accessibilité comme le rôle, le nom et la description. Vous vérifiez trois choses :

1. Le rôle est-il celui que vous attendez ?
2. Le nom accessible est-il clair et spécifique ?
3. La description est-elle utile sans remplacer le nom ?

Ensuite, testez quelques parcours avec un vrai lecteur d’écran. Vous n’avez pas besoin de devenir expert à plein temps en technologies d’assistance pour repérer les bases. Sur macOS, VoiceOver est intégré. Sur Windows, NVDA est largement utilisé et gratuit. Sur mobile, testez avec VoiceOver sur iOS et TalkBack sur Android lorsque c’est pertinent.

Les outils automatisés sont utiles, mais ils ne peuvent pas déterminer de manière fiable si « Ouvrir », « Lire la suite » ou « Supprimer » est suffisamment contextualisé. Considérez l’automatisation comme un filet, pas comme un juge. C’est similaire à l’audit de performance : un rapport peut vous indiquer des zones suspectes, mais vous devez encore interpréter leur impact. La même approche calme que nous recommandons pour reading a Lighthouse report without panicking s’applique ici.

Une checklist de revue pratique

Avant de livrer des libellés ARIA, demandez-vous :

• Cela pourrait-il être du HTML natif à la place ?
• Existe-t-il du texte visible qui devrait être utilisé comme libellé ?
• Si du texte visible existe, le nom accessible l’inclut-il ?
• Les contrôles répétés sont-ils uniques lorsqu’ils sont parcourus hors du contexte visuel ?
• Le texte d’aide est-il relié avec aria-describedby, plutôt que forcé dans le libellé ?
• Les icônes décoratives sont-elles masquées aux technologies d’assistance ?
• Quelqu’un a-t-il vérifié le nom d’accessibilité calculé dans les outils de développement du navigateur ?
• Au moins un passage avec un vrai lecteur d’écran a-t-il été effectué pour le parcours critique ?

Cette checklist permet de repérer la plupart des problèmes de libellés avant qu’ils ne deviennent des problèmes pour les utilisateurs.

La discipline discrète du bon ARIA

Un bon travail ARIA est rarement spectaculaire. Il repose surtout sur la retenue.

Utilisez de vrais boutons. Utilisez de vrais libellés. Gardez les noms visibles et accessibles alignés. Ajoutez aria-label seulement lorsqu’il n’existe pas de meilleure source visible. Utilisez aria-labelledby lorsque la page contient déjà le bon texte. Utilisez aria-describedby pour les instructions complémentaires et les erreurs.

La plateforme web donne beaucoup gratuitement aux développeurs lorsque nous l’utilisons directement. ARIA est là pour combler les manques. La compétence consiste à savoir quand il y a réellement un manque.