aria-live : polite, assertive, aria-atomic (guide RGAA)

Vous avez ajouté aria-live sur un conteneur, et le lecteur d'écran reste muet. Ou l'inverse : il annonce tout, tout le temps, et l'application devient inutilisable à l'oreille. Les deux problèmes viennent du même endroit, un modèle à trois attributs dont un seul est vraiment décisif.

Ce guide couvre les trois valeurs de aria-live, le rôle de aria-atomic, les pièges qui rendent une région silencieuse, et les deux cas concrets où tout se joue : les notifications et les interfaces qui se rafraîchissent seules. À la fin, vous saurez lequel des deux problèmes vous avez, et quoi changer.

aria-live : ce que fait l'attribut, et ses trois valeurs

aria-live s'applique à un conteneur et prévient le lecteur d'écran qu'il doit surveiller son contenu. Quand le texte à l'intérieur change, le lecteur l'annonce sans que l'utilisateur ait à y déplacer le focus. C'est le seul mécanisme pour signaler un changement qui se produit ailleurs que là où l'utilisateur se trouve.

• aria-live="off" (valeur par défaut) : aucun changement n'est annoncé.
• aria-live="polite" : le lecteur termine ce qu'il est en train de dire, puis annonce. C'est la valeur que vous voulez presque toujours.
• aria-live="assertive" : le lecteur interrompt immédiatement, y compris au milieu d'un mot.

L'attribut se pose sur le conteneur, jamais sur le texte injecté. C'est la distinction qui explique la plupart des régions muettes, et on y revient plus bas.

polite ou assertive : la seule décision qui compte

Le test qui tranche n'est pas « est-ce important ? », parce que tout paraît important au moment où on l'écrit. Le test utile est : si l'utilisateur entend ce message dix secondes plus tard, est-ce que quelque chose est perdu ?

Si la réponse est non, c'est polite. Un message de succès, un compteur de résultats mis à jour, un chargement terminé, une sauvegarde automatique : tout cela peut attendre la fin de la phrase en cours.

Si la réponse est oui, c'est assertive. Une session qui expire dans trente secondes, une connexion perdue au milieu d'une saisie, un paiement refusé : ne pas l'entendre tout de suite a une conséquence réelle.

Une erreur de validation de formulaire ne relève pas de assertive. Elle est signalée là où l'utilisateur va revenir de toute façon, et l'interruption coûte plus qu'elle n'apporte.

role="status" et role="alert" : les raccourcis à préférer

Deux rôles ARIA portent déjà ce comportement, et disent en plus ce que la région est :

• role="status" implique aria-live="polite" et aria-atomic="true".
• role="alert" implique aria-live="assertive".

Quand l'un des deux décrit votre intention, utilisez-le plutôt que les attributs bruts : vous obtenez le bon comportement sans risquer d'oublier aria-atomic. Le contrat complet d'un composant d'alerte (rôle, moment d'insertion, gestion du focus) figure dans la fiche Alerte accessible.

aria-atomic : relire toute la phrase, ou seulement ce qui change

aria-atomic détermine ce que le lecteur relit quand une partie du conteneur change.

Prenez un compteur qui affiche « 3 résultats correspondent à vos critères » et passe à « 5 résultats ».

• Avec aria-atomic="false" (défaut), seul le fragment modifié est annoncé. L'utilisateur entend « 5 ». Sans contexte, ça ne veut rien dire.
• Avec aria-atomic="true", le conteneur entier est relu : « 5 résultats correspondent à vos critères ».

La règle tient en une ligne : dès que votre message est une phrase, mettez aria-atomic="true". Ne le laissez à false que si le conteneur est une liste d'entrées indépendantes où relire l'ensemble serait plus bruyant qu'utile.

Un mot sur aria-relevant, qui apparaît souvent dans le même paragraphe des tutoriels : l'attribut est toujours présent dans la spécification ARIA, il n'est pas déprécié. Mais son support varie assez d'un lecteur d'écran à l'autre pour qu'on ne puisse pas construire dessus. Le comportement par défaut, qui annonce les ajouts de texte, est ce sur quoi vous pouvez compter.

Les trois pièges qui rendent une région live muette

Le conteneur n'existait pas avant l'injection

C'est de loin la cause la plus fréquente. Le lecteur d'écran doit avoir vu la région avant que son contenu ne change. Si votre code crée la div et y met le texte dans le même cycle de rendu, il n'y a pas de changement à détecter : il y a une apparition, ce qui n'est pas la même chose.

Le conteneur doit être présent dans le DOM au chargement, vide, et attendre.

display: none

Un texte injecté dans un conteneur en display: none n'est pas annoncé. Et le passer ensuite en display: block ne l'annonce pas davantage, pour la même raison que ci-dessus : le lecteur observe des insertions de texte, pas des apparitions de conteneur.

Si la région doit être invisible, masquez-la avec une classe de type sr-only (position absolue, dimensions de 1 pixel, overflow: hidden), jamais avec display: none ni visibility: hidden.

aria-live posé trop haut dans l'arbre

Poser aria-live sur <body> ou sur le conteneur principal de l'application est une erreur qu'on rencontre en audit. L'intention est de ne rien rater. Le résultat est que chaque changement de classe CSS, chaque horloge, chaque micro-animation déclenche une annonce, et l'application devient impraticable à l'oreille.

Les régions live doivent être petites, ciblées, et peu nombreuses.

Deux cas concrets

Notifications toast

Le conteneur existe dès le chargement de la page et reste vide :

<div id="toast-region" role="status" aria-atomic="true" class="toast-container"></div>

L'injection déclenche l'annonce :

function showToast(message) {
  const container = document.getElementById('toast-region');

  const toast = document.createElement('div');
  toast.className = 'toast toast-success';
  toast.textContent = message;

  // Le lecteur d'écran détecte l'insertion de texte et annonce le message.
  container.appendChild(toast);

  setTimeout(() => toast.remove(), 5000);
}

role="status" suffit ici : il apporte aria-live="polite" et aria-atomic="true" d'un coup.

Interfaces qui se rafraîchissent seules

Un tableau de bord dont cinquante lignes changent en continu ne se traite pas avec aria-live. Si vous posez l'attribut sur les cellules, vous obtenez un flux ininterrompu que personne ne peut suivre.

La bonne approche est de laisser les données changer silencieusement et de proposer une synthèse à côté : un conteneur sr-only avec role="status" qui annonce, à un rythme raisonnable, « Marché en hausse de 2 %, 5 valeurs en alerte ». L'utilisateur reçoit l'information utile sans le détail illisible.

Il faut aussi un moyen d'arrêter le mouvement. C'est une exigence du critère RGAA 13.8, qui demande que tout contenu en mouvement ou clignotant déclenché automatiquement soit contrôlable : l'utilisateur doit pouvoir l'arrêter et le relancer, le masquer, ou accéder à la totalité de l'information sans le mouvement, sauf si le mouvement dure moins de cinq secondes. Un bouton « Figer les données » remplit cette condition et rend le tableau navigable.

Tester : rien ne remplace un lecteur d'écran

Aucun outil automatique ne juge la pertinence d'une annonce. Un validateur voit que aria-live est présent et bien formé. Il ne peut pas vous dire que votre application parle trop.

1. Lancez NVDA sur Windows ou VoiceOver sur macOS.
2. Utilisez votre application sans regarder l'écran.
3. Si la voix vous coupe pendant que vous essayez de réfléchir, la région est mal réglée.

La console Speech Viewer de NVDA affiche le journal textuel de tout ce qui est prononcé. C'est l'outil le plus efficace pour repérer les doubles annonces, qui viennent presque toujours d'un aria-live combiné à un role qui en implique déjà un.

Pour nommer correctement les éléments que vos régions live mentionnent, voir le guide aria-label et aria-labelledby.

Ce qu'il faut retenir

aria-live ne sert pas à tout annoncer, il sert à choisir ce qui mérite d'être dit. Dans la pratique, trois décisions couvrent la quasi-totalité des cas : polite sauf conséquence immédiate, aria-atomic="true" dès qu'il s'agit d'une phrase, et un conteneur présent dans le DOM avant l'injection.

Côté conformité française, ces régions relèvent du critère RGAA 7.5 sur la restitution des messages de statut. Nous en détaillons les trois tests et les cas limites dans notre article sur les messages de statut et le critère 7.5. Pour le choix entre déplacement du focus et région live sur un formulaire, voir le bouton désactivé et les angles morts du RGAA.

Vous développez une interface dynamique ? Testez le comportement du focus et des régions live avec notre testeur de focus, puis analysez la page complète pour repérer les régions live absentes ou mal typées.