Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ?
Un utilisateur de lecteur d’écran remplit un formulaire de contact et clique sur Envoyer. La page affiche « Votre message a bien été envoyé », le focus reste sur le bouton. Sans marquage ARIA, ce message n’existe pas pour le lecteur d’écran : il n’annonce rien, l’utilisateur ne sait pas si son action a réussi.
Le critère 7.5 s’applique aux messages de statut, c’est-à-dire aux messages qui apparaissent sans changement de contexte. Sans déplacement du focus, sans rechargement de page. Quatre catégories sont concernées : succès ou résultat d’une action, état occupé d’une application, progression d’un processus, existence d’erreurs ou de suggestions.
Chaque catégorie a son outil ARIA. Pour un message de succès ou d’état d’application : role="status" ou aria-live="polite" accompagné de aria-atomic="true". Pour une erreur ou un avertissement : role="alert" ou aria-live="assertive" avec aria-atomic="true". Pour la progression d’un processus : role="log", role="progressbar" ou role="status" selon l’intention. Le niveau d’urgence du message détermine le rôle à choisir.
Sans ARIA, le message existe visuellement. Pas pour le lecteur d’écran.
3 tests pour s'assurer que les messages de statut sont correctement restitués
Marquage ARIA des messages de statut
- Repérez dans la page tous les messages qui apparaissent sans changement de contexte (pas de déplacement du focus, pas de rechargement) : confirmations, erreurs, indicateurs de progression, messages d’état d’application.
- Pour chaque message identifié, déterminez sa catégorie, puis vérifiez le marquage de l’élément qui le contient :
- Succès, résultat d’action ou état d’application : l’élément doit avoir
role="status"OU (aria-live="polite"+aria-atomic="true"). - Erreur ou suggestion : l’élément doit avoir
role="alert"OU (aria-live="assertive"+aria-atomic="true"). - Progression d’un processus : l’élément doit avoir
role="log",role="progressbar"ourole="status"OUaria-live="polite"(pour l’équivalent d’un log) OU (aria-live="polite"+aria-atomic="true"pour l’équivalent d’un status).
- Succès, résultat d’action ou état d’application : l’élément doit avoir
- Le test est validé si au moins une des implémentations valides est présente. Il échoue si aucun rôle ni attribut ARIA adapté n’est détecté.
Marquage ARIA des messages de statut (suite 1)
Méthodologie identique au test 7.5.1. Appliquez les mêmes étapes : repérer les messages de statut dans la page, déterminer leur catégorie (succès, erreur, progression), puis vérifier la présence du rôle ou des attributs ARIA correspondants sur l’élément conteneur.
Marquage ARIA des messages de statut (suite 2)
Méthodologie identique au test 7.5.1. Appliquez les mêmes étapes : repérer les messages de statut dans la page, déterminer leur catégorie (succès, erreur, progression), puis vérifier la présence du rôle ou des attributs ARIA correspondants sur l’élément conteneur.
Exemples
❌ Non conforme : Message de confirmation injecté sans marquage ARIA
<button type="submit">Envoyer</button>
<!-- Injecté dynamiquement après soumission -->
<div id="confirmation">Votre profil a été mis à jour avec succès.</div>Le message apparaît dans le DOM après soumission, le focus reste sur le bouton. Sans role="status" ni aria-live, le lecteur d’écran ne détecte aucun changement. L’utilisateur ignore totalement si son action a réussi.
✅ Conforme : Message de confirmation avec role="status"
<!-- Présent dans le DOM dès le chargement, vide, rempli par JS après soumission -->
<div id="confirmation" role="status" aria-atomic="true"></div>
<button type="submit">Envoyer</button>Le conteneur role="status" est dans le DOM dès le chargement, mais vide. Quand le script y injecte le message, le lecteur d’écran l’annonce automatiquement en mode poli, sans interrompre la navigation. aria-atomic="true" garantit que le message entier est lu, et non seulement la partie modifiée.
❌ Non conforme : Messages d’erreur injectés après validation sans ARIA
<!-- Injecté dynamiquement après validation, focus non déplacé -->
<div id="erreurs">
<p>2 erreurs ont été détectées.</p>
<ul>
<li>L'adresse e-mail est invalide.</li>
<li>Le champ téléphone est obligatoire.</li>
</ul>
</div>Les erreurs apparaissent dans le DOM sans que le focus ne se déplace. Sans role="alert" ni aria-live="assertive", le lecteur d’écran ignore ces changements. L’utilisateur peut continuer à croire que le formulaire a été soumis correctement.
✅ Conforme : Messages d’erreur avec role="alert"
<!-- Présent dans le DOM dès le chargement, vide, rempli par JS après validation -->
<div id="erreurs" role="alert" aria-atomic="true"></div>role="alert" est sémantiquement équivalent à aria-live="assertive" + aria-atomic="true" implicites. Le lecteur d’écran interrompt ce qu’il lit pour annoncer les erreurs immédiatement. C’est le comportement attendu : l’utilisateur doit être informé sans délai que sa saisie pose problème.
Astuces et pièges
⚠️ Créer le conteneur ARIA en même temps que le message
Le conteneur portant role="status", role="alert" ou aria-live doit être présent dans le DOM avant que le message ne soit injecté. Si vous créez l’élément et y ajoutez le texte simultanément via innerHTML ou createElement, la plupart des lecteurs d’écran ratent l’annonce. La bonne pratique : un conteneur vide dans le HTML de base, rempli par JavaScript au moment opportun.
⚠️ Utiliser role="alert" pour tous les types de messages
role="alert" est intrusif : il interrompt immédiatement la lecture en cours. L’utiliser pour un message de succès (« Profil sauvegardé ») perturbe l’utilisateur inutilement. Réservez-le aux erreurs et avertissements urgents. Pour les confirmations non urgentes, role="status" ou aria-live="polite" sont les bons choix.
⚠️ Message d’erreur avec déplacement de focus : hors scope du critère 7.5
Si, après validation, le focus se déplace vers la zone d’erreur ou vers le premier champ en erreur, il y a changement de contexte. Le critère 7.5 ne s’applique plus : le lecteur d’écran lira naturellement le contenu là où se trouve le focus. Ajouter role="alert" dans ce cas est redondant et peut provoquer une double annonce, source de confusion.
💡 aria-atomic="true" n’est pas optionnel avec role="status"
La spécification ARIA n’impose pas aria-atomic par défaut sur role="status". Dans la pratique, certains lecteurs d’écran n’annoncent que la partie modifiée du conteneur si aria-atomic="true" est absent. Pour garantir que le message complet est lu, ajoutez systématiquement aria-atomic="true" sur les régions live de type status.
⚠️ Progression d’un processus : trois rôles possibles selon l’intention
Pour une barre de progression classique : role="progressbar" avec aria-valuenow, aria-valuemin et aria-valuemax. Pour un journal d’activité où les messages s’accumulent : role="log" ou aria-live="polite". Pour un indicateur d’étape (« Étape 2 sur 4 ») : role="status" avec aria-atomic="true". Chaque pattern correspond à un comportement attendu différent des technologies d’assistance.
Questions fréquentes
Comment distinguer un message de statut d'un message hors scope du critère RGAA 7.5 ?
La clé est le changement de contexte. Si le focus se déplace vers le message ou ailleurs dans la page, il y a changement de contexte et le critère 7.5 ne s’applique pas. Si le message apparaît dans le DOM sans que rien d’autre ne change (pas de rechargement, pas de déplacement du focus), c’est un message de statut au sens du critère 7.5.
Comment choisir entre role="alert" et aria-live="assertive" pour les messages de statut RGAA 7.5 ?
role="alert" est équivalent à aria-live="assertive" + aria-atomic="true" implicites. En pratique, role="alert" est plus concis et son intention est plus lisible dans le code. aria-live="assertive" avec aria-atomic="true" donne le même résultat mais nécessite deux attributs. Les deux sont valides au regard du critère 7.5.
Comment implémenter role="alert" sur un message d'erreur inline selon le RGAA 7.5 ?
Cela dépend de la mécanique d’annonce. Si le message est lié au champ via aria-describedby ou aria-errormessage, le lecteur d’écran le lira quand l’utilisateur navigue vers ce champ. Dans ce cas, role="alert" n’est pas nécessaire. En revanche, si le message apparaît dynamiquement après soumission sans que le focus ne revienne sur le champ, role="alert" ou aria-live="assertive" est indispensable pour une annonce immédiate.
Comment auditer efficacement le critère RGAA 7.5 sur les messages de statut ?
Utilisez les DevTools pour inspecter les éléments qui reçoivent du contenu dynamique (confirmations, erreurs, loaders). Cherchez role, aria-live et aria-atomic dans le HTML généré. Ensuite, testez avec un lecteur d’écran (NVDA sous Firefox, VoiceOver sous Safari) en déclenchant les actions correspondantes : soumission de formulaire, recherche, chargement. Si le message n’est pas vocalisé automatiquement, le critère échoue.
Comment distinguer les tests RGAA 7.5.1, 7.5.2 et 7.5.3 malgré leur méthodologie commune ?
Dans le RGAA, plusieurs tests sous un même critère correspondent souvent à différents types de technologies de contenu ou de contextes d’application couverts par la norme. La méthodologie est identique pour les trois. En pratique, appliquez la même procédure pour chacun et documentez les résultats séparément dans votre rapport d’audit.