L'attribut aria-label en HTML : comment l'utiliser correctement

aria-label : Petit code, grand impact

Imaginez que vous visitiez une boutique en ligne et que vous ne voyiez qu'une icône de panier. Les personnes voyantes comprennent immédiatement qu'il s'agit d'une commande. Mais pour les personnes utilisant un lecteur d'écran, le bouton reste obscur. Seule une étiquette aria-label, comme « Ajouter au panier », permet de le rendre clairement identifiable et accessible.

L'accessibilité numérique commence par le code. Le HTML sémantique en constitue la base, tandis que l'attribut aria-label ne fait que compléter les éléments standards insuffisants. Cela profite non seulement aux institutions, mais aussi aux entreprises, notamment aux boutiques en ligne, où des boutons et des champs de formulaire clairs garantissent un processus de commande fluide.

Qu'est-ce qu'une étiquette aria ?

L'attribut aria-label fait partie de la spécification ARIA (Accessible Rich Internet Applications) du W3C (World Wide Web Consortium). Le W3C est l'organisme international qui élabore des standards web ouverts, notamment l'attribut aria-label. Directives pour l'accessibilité du contenu Web (WCAG) .

L'attribut aria-label ajoute des étiquettes invisibles aux éléments HTML, que les lecteurs d'écran signalent lorsque les étiquettes visibles sont absentes ou peu claires. Cela permet de concilier accessibilité graphique et accessibilité technique, rendant ainsi les interfaces compréhensibles par tous.

Pourquoi les attributs ARIA sont importants

Les attributs ARIA ont été développés pour garantir l'accessibilité là où le HTML atteint ses limites. Les sites web modernes avec du contenu dynamique — comme des éléments JavaScript, des widgets personnalisés ou des designs visuels complexes — présentent leurs propres défis. Dans ce contexte, un attribut ARIA tel que aria-label permet de s'assurer que même ces interfaces sont correctement interprétées par les lecteurs d'écran.

Différence par rapport aux étiquettes visibles dans l'interface utilisateur

Une différence essentielle entre aria-label et les étiquettes visibles réside dans leur public cible : les étiquettes visibles sont accessibles à tous les utilisateurs, tandis que aria-label est exclusivement réservé aux technologies d’assistance.

Les étiquettes visibles sont les descriptions textuelles standard affichées dans l'interface, par exemple le texte « Adresse e-mail » au-dessus ou à côté d'un champ de saisie :

<label for="email">Adresse e-mail</label>

<input type="email" id="email" name="email">

Tous les utilisateurs savent immédiatement ce qu'ils doivent saisir dans le champ, et les lecteurs d'écran lisent également le texte à voix haute. Si une telle étiquette visible est absente, une étiquette aria-label peut être utilisée à la place. Elle ajoute de manière invisible une description que seuls les lecteurs d'écran peuvent détecter :

<input type="email" id="email" name="email" aria-label="Adresse e-mail">

De cette manière, le domaine reste compréhensible et accessible, même sans étiquette visible.

Comment fonctionne l'attribut aria-label en HTML ?

Les lecteurs d'écran déterminent le nom accessible d'un élément dans un ordre fixe :

• aria-étiqueté par – fait référence au texte visible dans le code

• étiquette aria – étiquette invisible

• visible <label> – pour les champs de formulaire

• contenu textuel – par exemple, le texte d'un bouton

• Attribut du titre – dernier recours

Un bouton d'icône de recherche n'est pas reconnu sans description supplémentaire. aria-label="Rechercher" Le lecteur d'écran lit « Rechercher » à voix haute, de manière claire et utilisable.

Exemple:
Un bouton de recherche avec une icône de loupe ne comporte aucun texte visible. Sans information supplémentaire, il serait incompréhensible pour les lecteurs d'écran. Cependant, si vous ajoutez du texte, il deviendra plus clair. aria-label="Rechercher" Le lecteur d'écran annonce « Recherche » et ignore toutes les autres sources possibles.

Exemples d'attribut aria-label pour les boutons et les liens

L'attribut aria-label est souvent utilisé pour les boutons ne contenant qu'une icône. Pour les personnes voyantes, une loupe est immédiatement perçue comme une fonction de recherche, mais elle est incompréhensible pour les lecteurs d'écran. Grâce à aria-label, le bouton devient également compréhensible par les technologies d'assistance.

<button aria-label="Lancer la recherche">

<svg aria-hidden="true" width="24" height="24">…</svg>

</button>

Un autre exemple concret est celui des listes. De nombreuses boutiques en ligne utilisent des listes à icônes, comme les listes de catégories avec des symboles. Les lecteurs d'écran annonceraient simplement « Liste contenant 5 articles ». aria-label="Catégories de produits" , on comprend alors clairement ce que contient la liste.

Les liens, quant à eux, doivent clairement indiquer leur destination. Une phrase vague comme « En savoir plus » n’est pas accessible, car elle reste obscure hors contexte. L’attribut aria-label peut améliorer cela :

<a href="/article/accessibilité"

aria-label="Lire l'article sur l'accessibilité numérique">

Lire l'article sur l'accessibilité numérique

</a>

aria-label pour les éléments de formulaire

Les formulaires sont un élément central de presque tous les sites web. Pour les rendre accessibles, chaque champ de formulaire doit avoir un nom clair. Généralement, cela se fait à l'aide d'un nom visible. <label> élément:

<label for="email">Adresse e-mail</label>

<input type="email" id="email" name="email">

L'avantage : Tous les utilisateurs voient le libellé « Adresse e-mail », et les lecteurs d'écran le lisent à voix haute. De plus, les utilisateurs peuvent cliquer sur ce libellé pour sélectionner automatiquement le champ.

Parfois, pour des raisons de conception, aucune étiquette visible n'est utilisée, par exemple lorsqu'un simple texte d'espace réservé apparaît dans le champ. Pour les utilisateurs de lecteurs d'écran, cela pose problème, car les textes d'espace réservé ne sont pas considérés comme des étiquettes officielles. C'est là que l'attribut aria-label s'avère utile :

<input type="email"

aria-label="Adresse e-mail"

placeholder="exemple@domaine.com">

Les utilisateurs voyants voient le champ comme d'habitude, mais les utilisateurs de lecteurs d'écran entendent « Adresse e-mail ». Cela garantit que le champ reste compréhensible même sans étiquette visible.

Un autre exemple est celui des champs de saisie qui nécessitent instructions supplémentaires — comme les champs de mot de passe. Ici, une simple étiquette ne suffit pas. Avec aria-décrite par , ce champ peut être lié à des informations complémentaires :

<input type="mot de passe"

aria-label="Mot de passe"

aria-describedby="pwd-help">

<div id="pwd-help">Au moins 8 caractères, dont un chiffre</div>

Dans ce cas, le lecteur d'écran lit d'abord « Mot de passe », suivi de « Au moins 8 caractères, dont un chiffre ».

Important: L'étiquette aria dans les formulaires devrait généralement rester la exception . Un visible <label> C'est presque toujours la meilleure solution : elle est claire pour tous, plus facile à utiliser et nécessite moins de logique supplémentaire. L'attribut aria-label devrait principalement servir de solution de repli lorsque les étiquettes sont masquées pour des raisons de conception ou de mise en page.

Les rôles d'ARIA et leur interaction avec les labels

Les rôles ARIA décrivent la fonction d'un élément, tandis que l'attribut aria-label définit son nom. Cette combinaison est particulièrement importante pour les widgets personnalisés qui dépassent la sémantique standard du HTML :

<div role="button" aria-label="S'abonner à la newsletter" tabindex="0">

<svg>...</svg>

S'inscrire

</div>

Pour les widgets interactifs tels que les menus, des attributs supplémentaires sont pertinents. aria-expanded indique si un menu est développé, tandis que aria-haspopup signale qu'un élément déclenche l'affichage d'une fenêtre contextuelle ou d'un menu :

<button aria-label="Ouvrir le menu principal"

aria-expanded="false"

aria-haspopup="true"

aria-controls="main-menu">

☰

</button>

<ul id="main-menu" role="menu" hidden>

<li role="menuitem"><a href="#home">Accueil</a></li>

<li role="menuitem"><a href="#about">À propos de nous</a></li>

</ul>

Toutefois, la première règle de l'ARIA s'applique : Utilisez le HTML natif autant que possible. Un vrai <button> un élément est toujours préférable à un <div role="button"> , puisqu'il inclut déjà toutes les fonctionnalités requises.

aria-label vs. alt text

On confond souvent l'attribut aria-label avec le texte alternatif. Tous deux contribuent à l'accessibilité, mais leurs objectifs sont différents :

• Texte alternatif Cette description est spécifiquement destinée aux images et décrit leur contenu visuel. Elle apparaît lorsque l'image ne peut pas être chargée et est lue à voix haute par les lecteurs d'écran.
  

• étiquette aria , en revanche, peut être appliqué à presque tous les éléments HTML et fournit aux lecteurs d'écran des informations supplémentaires sur la fonction ou la signification d'un élément.

<!-- Correct : Texte alternatif pour les images -->

<img src="product.jpg"

alt="Ordinateur portable avec écran ouvert">

<!-- Correct : aria-label pour le bouton sans texte -->

<button aria-label="Ajouter au panier">

<svg aria-hidden="true">...</svg>

</button>

Pour les images, le calcul du nom accessible suit une hiérarchie : aria-étiqueté par remplacements étiquette aria , ce qui à son tour prime sur le alt attribut. Mais en utilisant aria-label="Texte alternatif" au lieu d'un alt L'attribut n'est pas recommandé. alt devrait toujours être le premier choix pour les graphismes.

Lors de l'utilisation d'icônes SVG, une attention particulière est requise :

• icônes décoratives devrait être caché aux lecteurs d'écran avec aria-hidden="true" .

• Icônes fonctionnelles Il faut un label aria-signal pertinent.
  

Bonnes pratiques pour l'utilisation des étiquettes aria-label

L'utilisation efficace de l'attribut aria-label suit des règles claires afin de garantir l'accessibilité et la maintenabilité du code. Les développeurs doivent tenir compte de plusieurs facteurs pour éviter toute confusion chez les utilisateurs :

• Utilisez aria-label avec parcimonie : N'utilisez cet attribut que lorsque les éléments HTML natifs ou les étiquettes visibles ne suffisent pas. Les éléments qui possèdent déjà un nom descriptif grâce à leur contenu textuel ou à leurs attributs n'ont pas besoin d'un attribut aria-label supplémentaire.
  

• Rédigez des descriptions claires et concises : L'attribut aria-label doit être explicite et décrire précisément la fonction de l'élément. Évitez les termes techniques et les noms internes qui ne sont pas compréhensibles par les utilisateurs.
  

• Combiner avec du HTML sémantique : ARIA complète HTML mais ne le remplace pas. Utilisez des éléments sémantiques tels que <button> , <nav> , ou <main> comme base et les étendre avec des attributs ARIA si nécessaire.

<!-- ERREUR : étiquette aria-label redondante -->

<button aria-label="Se connecter">Se connecter</button>

<!-- DROITE : aucun label aria-label nécessaire -->

<button>Se connecter</button>

• Envisagez la gestion de la concentration : Pour les widgets interactifs, il est essentiel de gérer correctement le focus. Les fenêtres contextuelles et les boîtes de dialogue doivent initialement placer le focus sur le premier élément pouvant recevoir le focus et le restituer à l'élément déclencheur une fois fermées.

Erreurs courantes dans l'étiquetage ARIA

Les erreurs d'implémentation les plus fréquentes proviennent d'une méconnaissance de la hiérarchie ARIA et d'une utilisation incorrecte :

• Étiquettes contradictoires : Si l'attribut aria-label ne correspond pas au texte affiché, les utilisateurs de logiciels de saisie vocale sont désorientés. Par exemple, une personne voit « Vorname » comme étiquette, mais le lecteur d'écran annonce « First Name ». Les commandes vocales deviennent alors inopérantes.
  

• Utilisation excessive d'ARIA : L'ajout de l'attribut aria-label à chaque élément réduit l'accessibilité. Les utilisateurs de lecteurs d'écran sont surchargés d'informations redondantes au lieu d'atteindre leur objectif plus rapidement.
  

• Échec de la mise à jour du contenu dynamique : Pour les éléments pilotés par JavaScript, il est impératif de s'assurer que les valeurs de l'attribut aria-label sont mises à jour lors des changements d'état. Ceci est particulièrement important pour les widgets à états dynamiques.
  

• Étiquettes inexactes : Les étiquettes qui ne reflètent plus la fonction actuelle de l'élément créent de fausses attentes et rendent la navigation plus difficile.
  

Liste de contrôle pour les développeurs et les concepteurs

• Vérifier la nécessité : Cet élément a-t-il réellement besoin d'un attribut aria-label, ou le HTML sémantique est-il suffisant ?
  

• Test avec des lecteurs d'écran : Utilisez NVDA (Windows), VoiceOver (Mac) ou d'autres lecteurs d'écran pour la vérification.
  

• Valider le calcul du nom accessible : Utilisez les outils de développement de votre navigateur pour vérifier quel nom est réellement calculé.
  

• Assurer la cohérence : Utilisez une formulation cohérente pour les éléments similaires sur l'ensemble du site web.
  

• Documenter les implémentations ARIA : Expliquez dans le code pourquoi et comment les attributs ARIA sont utilisés.
  

• Considérez toutes les méthodes de saisie : Assurez-vous que les widgets soient utilisables à la fois via le clavier et au toucher.
  

• Listes et navigation : Utilisez des balises HTML sémantiques pour les listes et les liens de navigation, en ajoutant des attributs ARIA lorsque cela est nécessaire.
  

Conclusion : Comment utiliser efficacement l’attribut aria-label

L'attribut aria-label est un outil précieux pour les sites web accessibles, mais sa mise en œuvre doit être réfléchie. Il fait le lien entre la conception visuelle et l'accessibilité sémantique, mais doit toujours être considéré comme un complément au HTML sémantique, et non comme un substitut.

L'efficacité de l'attribut aria-label est particulièrement visible pour les boutons à icône, les widgets personnalisés et dans les cas où des étiquettes visibles perturberaient la mise en page. Parallèlement, les exigences légales telles que BFSG et WCAG 2.1 imposent une approche systématique des étiquettes ARIA.

La clé d'une mise en œuvre réussie d'ARIA réside dans la compréhension que l'accessibilité web est une étape importante vers l'inclusion numérique de tous, quelles que soient leurs capacités ou limitations individuelles.

FAQ

Faut-il toujours utiliser l'attribut aria-label, ou seulement lorsque c'est nécessaire ?

L'attribut aria-label ne doit être utilisé que lorsque les éléments HTML natifs ou les étiquettes visibles ne suffisent pas. Son utilisation excessive entraîne une redondance d'informations et une expérience utilisateur dégradée pour les utilisateurs de lecteurs d'écran.

Comment puis-je tester si mon attribut aria-label fonctionne ?

Utilisez des lecteurs d'écran comme NVDA (Windows) ou VoiceOver (Mac/iOS) pour des tests réalistes. Les outils de développement du navigateur affichent les propriétés calculées et le nom accessible réel dans l'onglet Accessibilité.

Quels lecteurs d'écran prennent en charge l'attribut aria-label ?

Les lecteurs d'écran modernes tels que NVDA, JAWS, VoiceOver et TalkBack prennent largement en charge l'attribut aria-label. Cependant, la compatibilité peut varier selon le navigateur et sa version ; il est donc recommandé de tester sur différentes configurations.

Que se passe-t-il si un élément n'a pas d'attribut aria-label ?

Les lecteurs d'écran utilisent le nom suivant disponible dans la hiérarchie de calcul des noms accessibles : aria-labelledby, contenu textuel visible ou attribut title. Sans aucune étiquette, les éléments interactifs peuvent rester incompréhensibles pour les technologies d'assistance.