Qu'est-ce qu'ARIA ? Rôles, repères et régions live

Ce qu’est ARIA — et ce qu’il n’est pas

ARIA signifie Accessible Rich Internet Applications (applications internet riches accessibles). Il s’agit d’un ensemble d’attributs définis par la Web Accessibility Initiative (WAI) du W3C, qui permet aux développeurs de communiquer le sens et l’état des éléments d’interface aux technologies d’assistance telles que les lecteurs d’écran.

La règle la plus importante à propos d’ARIA est aussi la plus souvent ignorée : n’utilisez pas ARIA lorsque le HTML natif peut faire le travail. Un élément <button> s’annonce déjà comme un bouton et réagit aux événements clavier. Un élément <nav> communique déjà un repère de navigation aux lecteurs d’écran. Ajouter role="button" à un <div> puis scripter son comportement est plus difficile à maintenir, plus facile à casser et généralement moins bon pour l’accessibilité que d’utiliser d’emblée le bon élément.

ARIA ne fait pas ce qui suit :

Rendre un contenu visible ou interactif — il ne change que ce que la technologie d’assistance annonce
Réparer un accès clavier défaillant — vous avez toujours besoin de tabindex et d’écouteurs d’événements
Se substituer à un HTML sémantique bien structuré

Là où ARIA aide réellement, c’est lorsque le HTML natif n’offre aucun élément correspondant à ce que vous construisez : un sélecteur de date, une bannière de notification en direct, une liste combinée personnalisée, une arborescence. Dans ces cas, ARIA vous permet de communiquer la sémantique que le HTML ne peut pas exprimer.

Les rôles ARIA

Un rôle indique à la technologie d’assistance à quel type d’élément elle a affaire. Chaque élément interactif possède un rôle implicite dérivé de sa balise HTML. L’élément <a> a le rôle link. L’élément <input type="checkbox"> a le rôle checkbox. L’élément <h2> a le rôle heading.

Lorsque vous construisez un élément personnalisé sans équivalent HTML, vous lui attribuez un rôle explicite :

<!-- Un interrupteur personnalisé construit à partir d'un div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Mode sombre
</div>

Le lecteur d’écran annoncera désormais cet élément comme un interrupteur et énoncera son état coché. Sans le rôle, il serait annoncé comme du texte brut et l’utilisateur n’aurait aucune idée qu’il est interactif.

Rôles courants et quand les utiliser

Les rôles de widget décrivent les contrôles interactifs :

Rôle	À utiliser quand
`button`	Un élément cliquable personnalisé sans meilleure balise HTML
`checkbox`	Une case à cocher personnalisée à sélection multiple
`combobox`	Un champ de saisie combiné à une liste déroulante
`dialog`	Une superposition modale (uniquement lorsque l’élément natif `<dialog>` n’est pas utilisé)
`listbox`	Une liste déroulante personnalisée
`slider`	Un contrôle de plage personnalisé
`switch`	Un interrupteur marche/arrêt
`tab`, `tablist`, `tabpanel`	Une interface à onglets
`tooltip`	Une brève description affichée au survol ou au focus

Les rôles de structure du document décrivent les contenus non interactifs :

article — un contenu autonome
figure — une image accompagnée d’une légende
list, listitem — lorsqu’une sémantique de liste est nécessaire sur des éléments qui n’en sont pas
presentation / none — supprime le rôle implicite d’un élément (à utiliser rarement et avec précaution)

Une erreur critique : ajouter des rôles sans le comportement

Chaque rôle s’accompagne d’un contrat que les lecteurs d’écran et les utilisateurs au clavier s’attendent à voir respecté. Un role="button" doit réagir à la fois à Entrée et à Espace. Un role="checkbox" doit basculer avec Espace. Un role="link" doit naviguer avec Entrée.

Si vous ajoutez le rôle mais pas le comportement correspondant, vous induisez activement en erreur les utilisateurs de technologies d’assistance. Ils entendent l’annonce d’un contrôle, tentent d’interagir avec lui à l’aide du raccourci clavier attendu, et rien ne se produit. C’est pire que l’absence totale d’ARIA.

Les repères ARIA

Les repères (landmarks) constituent le squelette de navigation de la page. Ils permettent aux utilisateurs de lecteurs d’écran de passer d’une région majeure à l’autre sans lire tout ce qui se trouve entre les deux — l’équivalent du coup d’œil par lequel un utilisateur voyant balaie la mise en page.

HTML5 a introduit des éléments sémantiques qui correspondent directement à des rôles de repère. Utilisez-les et les repères vous sont fournis gratuitement :

Élément HTML	Rôle de repère	Objet
`<header>`	`banner`	En-tête global du site (uniquement lorsqu’il s’agit de l’en-tête de premier niveau, et non à l’intérieur d’un `<article>`)
`<nav>`	`navigation`	Un menu de navigation
`<main>`	`main`	Le contenu principal de la page
`<aside>`	`complementary`	Un contenu secondaire lié au contenu principal
`<footer>`	`contentinfo`	Pied de page global du site
`<form>`	`form`	Un formulaire (uniquement lorsqu’il possède un nom accessible)
`<section>`	`region`	Une section nommée (uniquement lorsqu’elle possède un nom accessible via `aria-label` ou `aria-labelledby`)

Vous n’avez pas besoin d’ajouter role="main" à un élément <main> — c’est redondant. Les rôles de repère ARIA ne sont nécessaires que lorsque vous ne pouvez pas utiliser l’élément HTML sémantique, par exemple dans une base de code héritée qui génère <div class="sidebar"> :

<div class="sidebar" role="complementary" aria-label="Articles connexes">
  <!-- contenu de la barre latérale -->
</div>

Étiqueter les repères lorsqu’il y en a plusieurs

Lorsqu’une page comporte plusieurs instances du même repère — deux éléments <nav>, deux éléments <section> avec role="region" — chacune doit avoir un nom accessible unique afin que les utilisateurs puissent les distinguer :

<nav aria-label="Navigation principale">...</nav>
<nav aria-label="Navigation du pied de page">...</nav>

Sans étiquettes, un lecteur d’écran annonce simplement les deux comme « navigation ». Avec des étiquettes, les utilisateurs entendent « Navigation principale, repère de navigation » et « Navigation du pied de page, repère de navigation » et peuvent choisir le bon dans une liste de repères.

Les régions live ARIA

Une région live est une zone de la page dont le contenu se met à jour dynamiquement, et dont les mises à jour doivent être annoncées automatiquement aux utilisateurs de lecteurs d’écran sans qu’ils aient besoin de déplacer le focus.

L’attribut central est aria-live. Il accepte trois valeurs :

off — les mises à jour ne sont pas annoncées (valeur par défaut de tous les éléments)
polite — les mises à jour sont annoncées une fois que l’utilisateur a terminé sa tâche en cours
assertive — les mises à jour interrompent immédiatement ce que le lecteur d’écran est en train de dire

<!-- Une zone de message d'état alimentée après l'envoi d'un formulaire -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Votre message a été envoyé.';
</script>

Lorsque le contenu textuel change, un lecteur d’écran configuré avec aria-live="polite" attend une pause dans la parole puis annonce le nouveau contenu. Utilisez polite pour la grande majorité des mises à jour dynamiques. Réservez assertive aux défaillances critiques uniquement — une erreur de paiement, un avertissement d’expiration de session — lorsque l’information est suffisamment urgente pour justifier d’interrompre l’utilisateur.

Rôles raccourcis pour les régions live

Deux rôles regroupent la sémantique aria-live en un seul attribut :

role="status" — équivaut à aria-live="polite". À utiliser pour les messages de succès, les états de chargement et les mises à jour non urgentes.
role="alert" — équivaut à aria-live="assertive" et implique également aria-atomic="true". À utiliser pour les messages d’erreur et les défaillances critiques.

<!-- Erreur annoncée immédiatement, en interrompant la parole en cours -->
<div role="alert" id="payment-error"></div>

<!-- Mise à jour d'état annoncée poliment après la parole en cours -->
<div role="status" id="cart-count">3 articles dans le panier</div>

Erreurs fréquentes avec les régions live

Ajouter du contenu avant que l’élément ne soit dans le DOM. Le navigateur enregistre la région live au moment où l’élément est analysé pour la première fois. Si vous injectez l’élément et définissez son contenu textuel simultanément, certains lecteurs d’écran manquent complètement l’annonce. Incluez toujours le conteneur de la région live dans le HTML initial et mettez son contenu à jour ultérieurement via JavaScript.

Utiliser assertive pour tout. Les régions live assertives interrompent tout ce que fait l’utilisateur, y compris les autres annonces. Un compteur de résultats de recherche qui se met à jour à mesure que l’utilisateur tape ne justifie pas un role="alert". L’usage excessif d’assertive produit une expérience hostile pour les utilisateurs de lecteurs d’écran.

Mettre à jour la région live trop fréquemment. Si un indicateur de progression met à jour sa région live toutes les 100 millisecondes, la file d’attente vocale déborde et les utilisateurs n’entendent rien d’utile. Ne mettez à jour le texte live qu’à des jalons significatifs — 25 %, 50 %, 75 %, terminé — ou temporisez les mises à jour avec une minuterie.

Oublier aria-atomic. Par défaut, seul le nœud de texte modifié à l’intérieur d’une région live est annoncé. Si vous souhaitez que l’intégralité de la région soit relue (et pas seulement le fragment modifié), ajoutez aria-atomic="true" :

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> éléments restants
</div>

Sans aria-atomic, un lecteur d’écran peut n’annoncer que « 2 » lorsque le compteur passe de 3 à 2. Avec cet attribut, la phrase complète « 2 éléments restants » est énoncée, ce qui correspond presque toujours à ce que vous souhaitez.

Autres attributs ARIA essentiels

aria-label — fournit un nom accessible lorsqu’aucun texte visible n’est approprié :

<button aria-label="Fermer la boîte de dialogue">✕</button>

aria-labelledby — pointe vers un autre élément dont le texte sert de nom accessible. À préférer à aria-label lorsque le texte de l’étiquette est déjà visible sur la page :

<h2 id="billing-heading">Adresse de facturation</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — pointe vers un texte complémentaire qui décrit un élément au-delà de son nom :

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Doit comporter au moins 12 caractères et inclure un symbole.</p>

aria-expanded — indique si un élément repliable (liste déroulante, accordéon, menu) est ouvert ou fermé. Mettez-le à jour en JavaScript chaque fois que l’état change :

<button aria-expanded="false" aria-controls="nav-menu">Menu</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — retire un élément de l’arbre d’accessibilité. À utiliser pour les icônes décoratives, le texte dupliqué ou les éléments visuels qui ajouteraient du bruit pour les utilisateurs de lecteurs d’écran :

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 étoiles sur 5</span>

aria-disabled="true" — marque un contrôle comme désactivé sans le retirer de l’ordre de tabulation. Utile lorsque vous voulez que les utilisateurs découvrent l’existence du contrôle et comprennent pourquoi il est indisponible, plutôt qu’il soit ignoré silencieusement :

<button aria-disabled="true">Envoyer (remplissez d'abord tous les champs)</button>

Tester ARIA en pratique

Écrire des attributs ARIA est simple. Les écrire correctement exige des tests. Les outils d’analyse automatisée détectent les schémas manifestement défaillants — un role="button" sans nom accessible, un aria-labelledby qui référence un identifiant inexistant, une région live dont la valeur aria-live est invalide. Ils ne peuvent pas vous dire si le texte annoncé a du sens dans son contexte, ni si un widget personnalisé complexe se comporte correctement lorsqu’on le parcourt au clavier seul.

Pour des tests représentatifs de la réalité, combinez au moins deux couples lecteur d’écran / navigateur :

NVDA + Chrome sous Windows — gratuit, très répandu, proche de la population réelle d’utilisateurs de lecteurs d’écran
VoiceOver + Safari sous macOS ou iOS — intégré, indispensable aux tests d’accessibilité mobile
JAWS + Chrome ou Edge sous Windows — payant, mais le lecteur d’écran le plus utilisé en environnement d’entreprise

Parcourez vos composants interactifs en utilisant uniquement le clavier. Écoutez attentivement ce qui est annoncé lorsque vous ouvrez un menu, envoyez un formulaire comportant une erreur de validation ou déclenchez la mise à jour d’une région live. Si l’annonce est ambiguë ou trompeuse, l’implémentation ARIA est erronée — quel que soit le verdict des outils automatisés.

La règle qui couvre tout

La spécification ARIA comporte cinq règles de rédaction. La première est la plus importante :

Si vous pouvez utiliser un élément ou un attribut HTML natif intégrant déjà la sémantique et le comportement dont vous avez besoin, plutôt que de détourner un élément et d’y ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, alors faites-le.

Construisez avec du HTML sémantique. Ne recourez à ARIA que lorsque le HTML atteint ses limites. Testez avec un vrai lecteur d’écran. Cela couvre presque toutes les situations que vous rencontrerez.

Pour une vérification concrète de la manière dont les attributs ARIA sont implémentés sur l’ensemble de votre site, nos audits d’accessibilité manuels incluent des tests par lecteur d’écran menés par des personnes qui utilisent des technologies d’assistance au quotidien et savent repérer les subtils problèmes d’ARIA que les outils automatisés laissent passer.