Comprendre les attributs ARIA en HTML pour améliorer facilement l’accessibilité

Par Lucas

Les attributs ARIA en HTML permettent de transmettre des informations supplémentaires aux technologies d’assistance, notamment aux lecteurs d’écran. Ils sont particulièrement utiles lorsque les éléments HTML classiques ne suffisent pas à expliquer le rôle, l’état ou le fonctionnement d’un composant interactif.

Bien utilisés, les attributs ARIA rendent une interface plus claire pour les personnes qui naviguent au clavier ou avec un lecteur d’écran. Leur intégration est gratuite, rapide et compatible avec la majorité des navigateurs modernes.

Ce guide pratique présente les attributs ARIA les plus utiles, des exemples prêts à l’emploi et les bonnes pratiques à suivre pour éviter les erreurs fréquentes.

Sommaire

Que sont les attributs ARIA en HTML ?

ARIA signifie Accessible Rich Internet Applications. Il s’agit d’un ensemble de rôles, d’états et de propriétés permettant d’améliorer la description des interfaces web auprès des technologies d’assistance.

ARIA complète le HTML lorsque celui-ci ne fournit pas toutes les informations nécessaires. Il peut, par exemple, indiquer qu’un menu est ouvert, qu’un champ contient une erreur ou qu’un bouton contrôle une autre zone de la page.

Les attributs ARIA commencent généralement par le préfixe aria- :

  • aria-label
  • aria-expanded
  • aria-hidden
  • aria-current
  • aria-live

L’attribut role appartient également à l’écosystème ARIA, même s’il ne commence pas par aria-. Il sert à définir la fonction d’un élément, par exemple un bouton, une boîte de dialogue ou une barre de navigation.

<div role="button" tabindex="0">
  Ouvrir le menu
</div>

Cet exemple donne au lecteur d’écran l’information que le bloc se comporte comme un bouton. Cependant, il reste préférable d’utiliser un véritable élément <button>, qui possède déjà le bon comportement, la navigation au clavier et la sémantique adaptée.

Pourquoi les attributs ARIA sont-ils utiles ?

Les attributs ARIA sont utiles lorsque votre site contient des composants interactifs personnalisés qui ne peuvent pas être correctement décrits avec du HTML standard.

Ils permettent notamment de :

  • donner un nom accessible à un bouton contenant uniquement une icône ;
  • indiquer si un menu ou un accordéon est ouvert ;
  • signaler automatiquement un message d’erreur ;
  • annoncer une mise à jour dynamique sans recharger la page ;
  • identifier l’élément actuellement sélectionné ;
  • associer un champ à une aide ou à une description complémentaire.

Pour l’utilisateur, le bénéfice est concret. La navigation devient plus compréhensible, plus prévisible et plus efficace. Pour le développeur, ARIA représente une solution personnalisable qui peut être intégrée directement dans le code HTML, sans extension payante.

ARIA agit principalement sur l’arbre d’accessibilité utilisé par les lecteurs d’écran. Il ne modifie pas automatiquement l’apparence, le comportement ou la navigation au clavier d’un élément. Ces fonctionnalités doivent toujours être prévues dans le HTML, le CSS ou le JavaScript.

HTML sémantique ou attributs ARIA : que faut-il choisir ?

La règle la plus importante consiste à utiliser d’abord un élément HTML natif lorsqu’il répond au besoin.

Un élément HTML sémantique possède déjà un rôle, un comportement et une prise en charge du clavier. Il est donc généralement plus fiable et plus simple à maintenir qu’un composant recréé avec des blocs génériques et des attributs ARIA.

Exemple à éviter

<div role="button" tabindex="0">
  Envoyer
</div>

Solution recommandée

<button type="submit">
  Envoyer
</button>

Le véritable bouton fonctionne nativement avec la touche Entrée, la barre d’espace, le focus clavier et les technologies d’assistance. Il nécessite moins de code et limite les risques d’erreur.

Le W3C recommande d’utiliser un élément HTML natif plutôt que de transformer un élément générique avec un rôle ARIA lorsque le composant nécessaire existe déjà en HTML.

Les attributs ARIA les plus utiles avec des exemples

aria-label pour donner un nom accessible

L’attribut aria-label attribue un nom accessible à un élément. Il est adapté aux boutons contenant uniquement une icône, sans texte visible.

<button type="button" aria-label="Fermer la fenêtre">
  &times;
</button>

Visuellement, le bouton affiche seulement une croix. Grâce à aria-label, le lecteur d’écran annonce « Fermer la fenêtre ».

Utilisez cet attribut uniquement lorsqu’aucun texte visible adapté ne peut servir de libellé. Lorsqu’un libellé visible existe, il est généralement préférable de le référencer avec aria-labelledby.

aria-labelledby pour utiliser un texte déjà visible

aria-labelledby relie un élément à un ou plusieurs textes déjà présents dans la page. Il évite de répéter le même contenu dans le code.

<h2 id="titre-dialogue">Supprimer le document</h2>

<div role="dialog" aria-labelledby="titre-dialogue">
  <p>Cette action est définitive.</p>
</div>

Le titre visible devient également le nom accessible de la boîte de dialogue. Cette solution est pratique, cohérente et facile à personnaliser.

aria-describedby pour ajouter une description

aria-describedby associe un élément à un texte complémentaire. Il est souvent utilisé pour les consignes de formulaire, les formats attendus ou les messages d’erreur.

<label for="mot-de-passe">Mot de passe</label>

<input
  type="password"
  id="mot-de-passe"
  aria-describedby="aide-mot-de-passe"
>

<p id="aide-mot-de-passe">
  Utilisez au moins 12 caractères.
</p>

Lorsque l’utilisateur atteint le champ, le lecteur d’écran peut annoncer le libellé puis la consigne associée.

aria-expanded pour indiquer un contenu ouvert ou fermé

aria-expanded indique si un élément contrôlé est actuellement développé ou réduit. Il est particulièrement adapté aux menus, accordéons et listes déroulantes.

<button
  type="button"
  aria-expanded="false"
  aria-controls="contenu-faq"
>
  Comment fonctionne le service ?
</button>

<div id="contenu-faq" hidden>
  <p>Le service fonctionne directement depuis votre navigateur.</p>
</div>

Lorsque le contenu s’ouvre, JavaScript doit remplacer la valeur par aria-expanded="true". L’attribut doit toujours refléter l’état réel du composant.

aria-controls pour identifier un élément contrôlé

aria-controls indique qu’un élément interactif contrôle une autre partie de la page. Sa valeur correspond à l’identifiant de l’élément concerné.

<button
  type="button"
  aria-controls="menu-principal"
  aria-expanded="false"
>
  Menu
</button>

<nav id="menu-principal">
  ...
</nav>

Dans cet exemple, le bouton contrôle la navigation dont l’identifiant est menu-principal. Cette relation aide les technologies d’assistance à comprendre le fonctionnement du composant.

aria-current pour signaler l’élément actif

aria-current identifie l’élément correspondant à la page, à l’étape ou à la date actuellement active.

<nav aria-label="Navigation principale">
  <a href="/" aria-current="page">Accueil</a>
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

Le lecteur d’écran peut ainsi préciser que le lien Accueil correspond à la page actuelle. Dans un même ensemble, un seul élément doit normalement être marqué comme actif.

aria-pressed pour créer un bouton à deux états

aria-pressed convient aux boutons qui peuvent être activés ou désactivés, comme un bouton favori, un mode silencieux ou une option d’affichage.

<button type="button" aria-pressed="false">
  Ajouter aux favoris
</button>

Après activation, JavaScript doit modifier la valeur :

<button type="button" aria-pressed="true">
  Retirer des favoris
</button>

Le texte visible et l’état ARIA doivent rester cohérents pour éviter toute confusion.

aria-hidden pour masquer un contenu aux lecteurs d’écran

aria-hidden="true" retire un élément de l’arbre d’accessibilité. Il est adapté aux éléments purement décoratifs ou redondants.

<button type="button">
  <span aria-hidden="true">✓</span>
  Valider
</button>

L’icône n’apporte aucune information supplémentaire puisque le texte « Valider » décrit déjà l’action.

Ne placez pas aria-hidden="true" sur un bouton, un lien, un champ ou le parent d’un élément pouvant recevoir le focus. Un élément interactif visible mais absent de l’arbre d’accessibilité devient difficile, voire impossible à utiliser avec un lecteur d’écran.

aria-disabled pour signaler une action indisponible

aria-disabled="true" indique qu’un élément est actuellement désactivé. Contrairement à l’attribut HTML disabled, il ne bloque pas automatiquement les clics et ne retire pas nécessairement l’élément de l’ordre de tabulation.

<button type="button" aria-disabled="true">
  Étape suivante
</button>

Le développeur doit donc empêcher l’action avec JavaScript et prévoir un style visuel compréhensible. Lorsque cela est possible, utilisez plutôt l’attribut HTML natif disabled.

aria-live pour annoncer un changement dynamique

aria-live permet d’annoncer une information ajoutée ou modifiée sans déplacer le focus de l’utilisateur.

<div aria-live="polite" id="message-statut"></div>

Le contenu peut ensuite être mis à jour avec JavaScript :

document.getElementById("message-statut").textContent =
  "Votre document a bien été enregistré.";

La valeur polite attend généralement que le lecteur d’écran termine son annonce actuelle. La valeur assertive interrompt plus rapidement la lecture et doit être réservée aux informations réellement urgentes.

Les régions dynamiques sont utiles pour les confirmations, les résultats de recherche, les paniers, les alertes et les erreurs de formulaire.

aria-required et aria-invalid pour les formulaires

aria-required="true" indique qu’un champ doit être rempli. aria-invalid="true" signale que sa valeur n’est pas valide.

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

<input
  type="email"
  id="email"
  required
  aria-invalid="true"
  aria-describedby="erreur-email"
>

<p id="erreur-email">
  Saisissez une adresse e-mail valide.
</p>

Lorsque le champ est corrigé, la valeur de aria-invalid doit être remplacée par false ou l’attribut doit être retiré.

Pour un champ HTML classique, utilisez en priorité l’attribut natif required. L’attribut ARIA peut compléter l’information dans certains composants personnalisés, mais il ne déclenche pas à lui seul la validation du navigateur.

Comment choisir le bon attribut ARIA ?

Le choix doit partir d’un besoin précis. N’ajoutez pas des attributs ARIA simplement pour rendre le code plus technique ou pour obtenir un meilleur score dans un outil d’audit.

1. Vérifier si un élément HTML natif existe

Commencez par rechercher l’élément HTML correspondant au besoin :

  • <button> pour déclencher une action ;
  • <a> pour ouvrir une page ou une ressource ;
  • <nav> pour une zone de navigation ;
  • <details> et <summary> pour un contenu dépliable simple ;
  • <dialog> pour certaines fenêtres modales ;
  • <label> pour nommer un champ de formulaire.

2. Identifier l’information manquante

Demandez-vous ce que l’utilisateur d’un lecteur d’écran ne peut pas comprendre :

  • le nom de l’élément ;
  • son rôle ;
  • son état actuel ;
  • la zone qu’il contrôle ;
  • une consigne complémentaire ;
  • un changement dynamique.

3. Ajouter uniquement l’attribut nécessaire

Un bouton avec une icône peut avoir besoin de aria-label. Un accordéon peut avoir besoin de aria-expanded et aria-controls. Une confirmation dynamique peut nécessiter aria-live.

Il n’est pas utile d’ajouter plusieurs attributs lorsqu’un seul suffit.

4. Vérifier la compatibilité avec le rôle

Tous les attributs ARIA ne sont pas autorisés sur tous les rôles et tous les éléments. Un attribut incorrect peut être ignoré ou produire une annonce trompeuse.

La spécification ARIA in HTML définit les rôles, états et propriétés autorisés pour les différents éléments HTML.

5. Mettre à jour les états avec JavaScript

Les attributs représentant un état doivent rester synchronisés avec l’interface.

const bouton = document.querySelector(".bouton-menu");
const menu = document.querySelector(".menu");

bouton.addEventListener("click", function () {
  const estOuvert = bouton.getAttribute("aria-expanded") === "true";

  bouton.setAttribute("aria-expanded", String(!estOuvert));
  menu.hidden = estOuvert;
});

Ce modèle est prêt à l’emploi et facile à personnaliser. Il met à jour simultanément l’affichage du menu et l’information transmise aux technologies d’assistance.

Avantages et limites des attributs ARIA

Les principaux avantages

  • Intégration gratuite : aucun outil payant n’est nécessaire.
  • Gain de temps : quelques attributs peuvent améliorer rapidement un composant existant.
  • Solution personnalisable : ARIA s’adapte aux menus, fenêtres modales, onglets, accordéons et formulaires personnalisés.
  • Compatibilité étendue : les attributs principaux sont reconnus par de nombreux navigateurs et lecteurs d’écran.
  • Amélioration de la compréhension : les rôles, états et relations deviennent plus explicites.
  • Adapté aux interfaces dynamiques : ARIA permet d’annoncer des changements sans rechargement de page.

Les principales limites

  • ARIA ne remplace pas le HTML sémantique.
  • ARIA ne crée pas automatiquement la navigation au clavier.
  • ARIA ne gère pas le focus à votre place.
  • ARIA ne modifie pas automatiquement le comportement d’un composant.
  • Un mauvais attribut peut rendre l’interface plus confuse.
  • La prise en charge peut varier selon les combinaisons de navigateurs et de technologies d’assistance.

Le guide officiel des pratiques ARIA rappelle qu’une mauvaise utilisation peut transmettre une représentation incorrecte de l’interface aux utilisateurs de lecteurs d’écran. Dans certains cas, aucun ARIA est préférable à un ARIA incorrect.

Bonnes pratiques pour utiliser ARIA correctement

Préférer la simplicité

Utilisez le moins d’attributs possible. Une structure HTML claire est souvent plus efficace qu’une accumulation de rôles et de propriétés.

Conserver un texte visible

Un texte visible profite à tous les utilisateurs. Ne remplacez pas systématiquement les libellés par des informations uniquement accessibles aux lecteurs d’écran.

Ne pas répéter un rôle natif inutilement

<button role="button">Enregistrer</button>

L’attribut role="button" est inutile ici, car l’élément <button> possède déjà ce rôle.

Tester la navigation au clavier

Vérifiez que chaque élément interactif peut être atteint avec la touche Tab, activé au clavier et utilisé sans souris.

Contrôlez également :

  • l’ordre du focus ;
  • la visibilité du focus ;
  • la fermeture des fenêtres modales avec Échap lorsque cela est prévu ;
  • le retour du focus vers l’élément d’origine ;
  • l’absence de piège au clavier.

Tester avec un lecteur d’écran

Les outils automatiques détectent certaines erreurs, mais ils ne peuvent pas confirmer que l’expérience est réellement compréhensible.

Effectuez au minimum un test avec :

  • NVDA sous Windows ;
  • VoiceOver sous macOS ou iOS ;
  • TalkBack sous Android.

Utiliser les modèles officiels pour les composants complexes

Pour créer des onglets, des menus, des listes déroulantes, des arbres ou des fenêtres modales, utilisez les modèles de conception de l’ARIA Authoring Practices Guide. Ils fournissent des exemples fonctionnels ainsi que les comportements clavier attendus.

Exemple complet d’accordéon accessible avec ARIA

Voici une base simple et prête à l’emploi pour créer une question dépliable.

<div class="accordeon">
  <h3>
    <button
      type="button"
      id="bouton-livraison"
      aria-expanded="false"
      aria-controls="contenu-livraison"
    >
      Quels sont les délais de livraison ?
    </button>
  </h3>

  <div
    id="contenu-livraison"
    role="region"
    aria-labelledby="bouton-livraison"
    hidden
  >
    <p>
      La livraison prend généralement entre trois et cinq jours ouvrés.
    </p>
  </div>
</div>

<script>
  const bouton = document.getElementById("bouton-livraison");
  const contenu = document.getElementById("contenu-livraison");

  bouton.addEventListener("click", function () {
    const estOuvert = bouton.getAttribute("aria-expanded") === "true";

    bouton.setAttribute("aria-expanded", String(!estOuvert));
    contenu.hidden = estOuvert;
  });
</script>

Ce composant utilise un véritable bouton, fonctionne au clavier et informe le lecteur d’écran de son état. Le contenu est également associé à son titre grâce à aria-labelledby.

Erreurs fréquentes à éviter avec les attributs ARIA

Ajouter aria-label sur tous les éléments

aria-label ne doit pas être utilisé comme une description générale. Il sert principalement à fournir un nom accessible lorsque le nom existant est absent ou insuffisant.

Utiliser aria-hidden sur un élément interactif

Un bouton masqué avec aria-hidden="true" peut rester visible et utilisable à la souris tout en devenant invisible pour le lecteur d’écran. Cette incohérence doit être évitée.

Oublier de mettre à jour aria-expanded

Si un menu est ouvert visuellement mais conserve aria-expanded="false", l’utilisateur reçoit une information incorrecte.

Confondre aria-disabled et disabled

aria-disabled annonce uniquement l’état. Il ne bloque pas automatiquement l’interaction. L’attribut HTML disabled désactive réellement les contrôles compatibles.

Créer un faux bouton sans gérer le clavier

Ajouter role="button" à un bloc ne suffit pas. Il faut également gérer le focus, la touche Entrée, la barre d’espace et les différents états du composant. La solution la plus rapide et la plus fiable reste généralement l’élément <button>.

FAQ sur les attributs ARIA en HTML

Les attributs ARIA sont-ils obligatoires sur tous les sites ?

Non. Un site utilisant correctement les éléments HTML sémantiques peut être accessible avec peu d’attributs ARIA. Ils deviennent surtout nécessaires pour décrire des composants personnalisés, des états dynamiques ou des relations qui ne sont pas exprimés naturellement par le HTML.

Quelle est la différence entre role et aria-label ?

role indique la fonction d’un élément, par exemple bouton, dialogue ou navigation. aria-label lui donne un nom accessible. Un rôle répond à la question « qu’est-ce que c’est ? », tandis que le libellé répond à la question « comment s’appelle cet élément ? ».

ARIA améliore-t-il directement le référencement naturel ?

Les attributs ARIA ne constituent pas un levier direct de positionnement SEO. Ils contribuent toutefois à créer une structure plus compréhensible et une expérience plus inclusive. Le HTML sémantique, la qualité du contenu, les performances et la facilité de navigation restent prioritaires.

Peut-on utiliser aria-label à la place d’un élément label ?

Techniquement, aria-label peut donner un nom accessible à certains champs. Cependant, un véritable <label> visible reste généralement préférable. Il améliore la compréhension pour tous et permet aussi de cliquer sur le texte pour placer le focus dans le champ.

Comment vérifier si les attributs ARIA fonctionnent ?

Commencez par naviguer uniquement au clavier. Utilisez ensuite les outils d’accessibilité du navigateur, un analyseur automatique et un lecteur d’écran. Vérifiez que le rôle, le nom, l’état et les descriptions annoncés correspondent réellement à ce qui apparaît à l’écran.

Faut-il ajouter ARIA à un bouton HTML classique ?

Pas systématiquement. Un bouton HTML possède déjà un rôle accessible et un comportement clavier. Ajoutez uniquement un attribut utile, comme aria-expanded lorsqu’il ouvre un menu ou aria-label lorsqu’il contient seulement une icône sans texte visible.

Conclusion

Comprendre les attributs ARIA en HTML permet de rendre les interfaces dynamiques plus accessibles sans compliquer inutilement le code. Commencez toujours par utiliser un HTML sémantique, puis ajoutez uniquement les rôles, états ou propriétés réellement nécessaires.

Pour passer à l’action, examinez vos menus, boutons avec icônes, accordéons et formulaires. Vérifiez que leur nom, leur état et leur fonctionnement sont compréhensibles au clavier comme avec un lecteur d’écran.

Laisser un commentaire