Role alert et status : quel rôle ARIA pour quel message

Une alerte affiche un message bref et important qui attire l'attention sans interrompre la tâche de l'utilisateur : injectée dynamiquement dans une zone live, elle est annoncée automatiquement par les lecteurs d'écran, sans déplacer le focus. Il n'existe pas d'élément natif dédié (<output> s'en approche pour un résultat calculé) : le mécanisme est role="alert" ou role="status".

Cette fiche est le contrat de référence du motif : quel rôle pour quel type de message, et la règle qui décide de tout, celle de la zone préexistante.

Quand ce motif est le mauvais choix

• L'utilisateur doit agir sur le message (bouton « Annuler », confirmation) : une zone live est le mauvais outil, le contenu interactif y est annoncé mais hors de portée. Utiliser une boîte de dialogue.
• Message routinier (copie effectuée, sauvegarde réussie) : role="alert" est trop agressif, il interrompt la lecture en cours au milieu d'une phrase. role="status" suffit.
• Suite ordonnée d'ajouts (messagerie, journal d'activité) : le motif adapté est role="log".
• Bandeau présent dès le chargement de la page : ce n'est pas un message de statut, aucun rôle live ne s'y justifie.

En cas de doute, role="status" : le mode assertif n'est presque jamais la bonne réponse.

Critères RGAA applicables

• Critère 7.5 : messages de statut. Le critère central du motif. Un message de statut informe d'un changement dans la page sans déplacer le focus, et le RGAA teste la correspondance entre le type de message et le rôle utilisé : succès, résultat d'une action ou état de l'application exigent role="status" (test 7.5.1) ; suggestion ou existence d'une erreur exigent role="alert" (test 7.5.2) ; progression d'un processus exige role="log", role="progressbar" ou role="status" (test 7.5.3).
• Critère 7.1 : scripts compatibles avec les technologies d'assistance. Le conteneur de message généré ou contrôlé par script doit exposer un rôle pertinent pour que le message soit restitué.
• Critère 3.1 : information donnée par la couleur. Une erreur signalée uniquement par du texte rouge est invisible pour l'utilisateur qui ne distingue pas cette couleur : coupler la couleur avec une icône et un texte explicite (« Erreur : ... »).
• Critère 13.1 : contrôle des limites de temps. Une notification qui se ferme seule après quelques secondes impose une limite de temps pour la lire ; l'utilisateur doit pouvoir contrôler cette limite, et l'unique copie d'une information importante ne doit jamais se trouver dans un toast qui disparaît.

Correspondance pratique type de message vers rôle :

Note technique du critère 7.5 : des attributs aria-live explicites peuvent valoir pour ces rôles (aria-live="polite" + aria-atomic="true" pour status, aria-live="assertive" + aria-atomic="true" pour alert, aria-live="polite" pour log), si la nature du message correspond. Une progression matérialisée par une barre graphique exige un role="progressbar" explicite.

Interaction clavier attendue

C'est précisément l'intérêt du motif : l'utilisateur est informé sans être déplacé. Ne jamais placer de bouton ou de lien dans la zone live ; si une action est attendue, utiliser une boîte de dialogue.

Rôles et attributs ARIA

role="alert" implique aria-live="assertive" + aria-atomic="true" (interrompt la lecture en cours) ; role="status" implique aria-live="polite" + aria-atomic="true" (attend une pause) ; role="log" implique aria-live="polite" (l'ordre des ajouts compte). Préférer le rôle à un aria-live brut : il porte les bons réglages par défaut.

La règle décisive du motif : le conteneur doit exister vide dans le DOM avant l'arrivée du message. Un lecteur d'écran n'annonce que les mutations des zones qu'il surveillait déjà ; une zone créée en même temps que son texte n'annonce souvent rien.

<!-- Rendues VIDES au chargement de la page : le lecteur d'écran
     enregistre les zones maintenant, les textes écrits plus tard
     seront annoncés. -->
<div id="statut-formulaire" role="status" class="sr-only"></div>
<div id="alerte-session" role="alert" class="sr-only"></div>

<!-- Zone visible, NON live : la zone live ci-dessus annonce,
     celle-ci affiche. -->
<div id="message-formulaire" class="message" hidden></div>

const zoneLive = document.getElementById('statut-formulaire');
const messageVisible = document.getElementById('message-formulaire');

function annoncer(message) {
  // Vider d'abord : deux textes identiques d'affilée ne produisent
  // aucune mutation, la seconde annonce serait silencieuse.
  zoneLive.textContent = '';
  requestAnimationFrame(() => {
    zoneLive.textContent = message;
  });
}

function afficherMessage(message) {
  messageVisible.textContent = message;
  messageVisible.hidden = false;
  annoncer(message);
}

afficherMessage('Votre profil a été enregistré.');

// Réellement urgent : mérite d'interrompre (test 7.5.2).
function prevenirExpiration(minutes) {
  document.getElementById('alerte-session').textContent =
    `Votre session expire dans ${minutes} minutes.`;
}

Le message visible, lui, ne doit pas reposer sur la couleur seule :

<!-- Icône + préfixe textuel, pas seulement du rouge (critère 3.1). -->
<div class="message" data-tone="erreur">
  <svg aria-hidden="true" focusable="false" width="16" height="16">
    <use href="#icone-erreur"/>
  </svg>
  <strong>Erreur :</strong> le paiement n'a pas pu être traité.
</div>

Et les contre-exemples qui concentrent l'essentiel des échecs du motif :

// À ne pas faire : créer la zone et son texte d'un seul coup.
// LE bug des zones live : le lecteur d'écran ne surveillait pas ce
// nœud, il n'annonce souvent rien. Le bug passe les tests manuels une
// fois sur deux, c'est pourquoi il est partout en production.
const toast = document.createElement('div');
toast.setAttribute('role', 'alert');
toast.textContent = 'Enregistré !';
document.body.append(toast);

// À ne pas faire : écrire deux fois le même texte sans vider la zone.
// Aucune mutation détectée : la seconde annonce est silencieuse.
zoneLive.textContent = 'Aucun résultat.';
zoneLive.textContent = 'Aucun résultat.'; // silencieux

<!-- À ne pas faire : role="alert" sur un bandeau rempli au chargement.
     Annoncé à chaque page pour rien : les utilisateurs apprennent
     à l'ignorer. -->
<div role="alert" class="bandeau">Bon retour parmi nous !</div>

<!-- À ne pas faire : du contenu interactif dans la zone live.
     « Annuler » est annoncé mais le focus est ailleurs, et le toast
     disparaît avant d'être atteignable au clavier. -->
<div role="alert">
  Message supprimé. <button type="button">Annuler</button>
</div>

<!-- À ne pas faire : cumuler un rôle et un aria-live contradictoire.
     role="alert" est déjà assertif. -->
<div role="alert" aria-live="polite">...</div>

<!-- À ne pas faire : une zone live sur toute une région de page.
     Chaque mutation du conteneur serait annoncée : sur une liste de
     résultats, la liste entière est relue à chaque frappe. -->
<main aria-live="polite">...</main>

Défauts fréquents et impact utilisateur

• Zone créée en même temps que son texte (<div role="alert">Enregistré</div> ajouté au DOM d'un coup) : le lecteur d'écran ne surveillait pas cette zone, l'annonce échoue fréquemment. Le défaut le plus répandu du motif, précisément parce qu'il est intermittent.
• role="alert" ou aria-live="assertive" pour un message routinier : l'utilisateur est interrompu au milieu d'une phrase pour entendre « Copié » ; il perd sa position dans le contenu.
• Deux écritures du même texte sans vider la zone entre les deux : aucune mutation n'est détectée, la deuxième annonce est silencieuse (« Aucun résultat » puis « Aucun résultat » ne s'entend qu'une fois).
• Contenu interactif dans la zone live (« Message supprimé. Annuler ») : le bouton est annoncé mais le focus est ailleurs et le toast disparaît avant que l'utilisateur puisse l'atteindre au clavier.
• role="alert" sur un bandeau rempli dès le chargement : annoncé à chaque page pour rien.
• Annoncer par la zone live ET déplacer le focus vers le message : le message est restitué deux fois. Choisir l'un ou l'autre ; pour un récapitulatif d'erreurs de formulaire, déplacer le focus est souvent préférable.

Ce que les outils automatiques ne détectent pas

• Ce motif ne se vérifie réellement qu'au lecteur d'écran : il n'y a ni signal visuel ni contrôle automatisable de l'annonce elle-même. Tant que l'annonce n'a pas été entendue, rien ne prouve qu'elle fonctionne.
• Le bug d'enregistrement (zone créée en même temps que son texte), le silence à la répétition d'un même message et l'usage abusif du mode assertif échappent entièrement aux outils automatiques.
• L'adéquation entre le type de message et le rôle (erreur vers role="alert", succès vers role="status", telle que testée par le critère 7.5) est un jugement manuel.

Les outils automatiques, dont notre scanner, repèrent en revanche des valeurs aria-live contradictoires ou une zone live placée sur un élément masqué : utile, mais aucun des vrais bugs du motif n'est dans cette liste. C'est probablement le motif le moins automatisable de toute la collection.

Vérifier ce composant

Protocole manuel, au lecteur d'écran obligatoirement :

1. Le test d'enregistrement : déclencher le message. Si rien n'est annoncé, la zone a été créée en même temps que son texte ; vérifier que le conteneur vide est bien dans le DOM dès le chargement.
2. Le test de répétition : déclencher deux fois le même message. S'il n'est annoncé qu'une fois, la zone n'est pas vidée entre les deux écritures.
3. Le test de politesse : déclencher un message routinier pendant que le lecteur d'écran lit un paragraphe. Il doit attendre la fin ; s'il interrompt, alert a été utilisé là où status convenait.
4. Le test du type de message : confronter chaque message à la correspondance du critère 7.5 (succès vers status, erreur vers alert, progression vers log, progressbar ou status).

Deux outils gratuits du site aident à ce contrôle : l'outil Patterns ARIA génère des notifications à zone live correctement préenregistrée (role="status" ou role="alert") prêtes à adapter, et le Simulateur Lecteur d'Écran permet de vérifier que la zone et son rôle sont bien présents dans l'arbre d'accessibilité dès le chargement. Pour le test d'écoute réel avec NVDA ou VoiceOver, suivre le guide Tester avec un lecteur d'écran.

Approfondir avec les fiches critères

• Critère 3.1 : Information par couleur
• Critère 7.1 : Compatibilité scripts
• Critère 7.5 : Messages de statut
• Critère 13.1 : Limite de temps

Toutes les fiches composants accessibles