Aller au contenu principal
Mynto
AccessibiliteRGAA 7.5Niveau AAScripts

Message de statut non restitué aux technologies d'assistance

Le critère RGAA 7.5, niveau AA, impose que les messages de statut - confirmations, erreurs, mises à jour de compteur - soient restitués par les lecteurs d'écran sans nécessiter de prise de focus sur l'élément.

C'est quoi

Un message de statut est une information qui apparaît en réponse à une action utilisateur ou à un événement, sans déplacer le focus : "Article ajouté au panier", "Formulaire envoyé", "3 résultats trouvés", "Erreur : email invalide".

Les lecteurs d'écran ne lisent pas automatiquement les changements de contenu dans le DOM. Pour notifier l'utilisateur sans déplacer le focus, il faut utiliser des régions ARIA en direct :

  • role="status" (ou aria-live="polite") : annonce le message sans interrompre la lecture en cours. A utiliser pour les confirmations.
  • role="alert" (ou aria-live="assertive") : annonce immédiatement et coupe la lecture - à réserver aux erreurs critiques.

Sans ces attributs, le message s'affiche visuellement mais reste silencieux pour les utilisateurs de lecteurs d'écran.

Qui est touché

  • Les personnes aveugles ou malvoyantes utilisant un lecteur d'écran (NVDA, JAWS, VoiceOver) : sans aria-live, elles ne savent pas si leur action a été prise en compte.
  • Les personnes en navigation clavier : si le focus ne se déplace pas vers le message de confirmation, elles n'en ont pas connaissance non plus.

Impact business

Un utilisateur de lecteur d'écran qui clique sur "Ajouter au panier" et ne reçoit aucune confirmation vocale ne peut pas savoir si son action a réussi. Il peut cliquer plusieurs fois, vider ses achats, ou abandonner la transaction.

Ce critère est particulièrement critique sur les sites e-commerce et les formulaires complexes où la confirmation d'action est essentielle.

Sources des chiffres

Comment le détecter

  • Lecteur d'écran : active NVDA (Windows) ou VoiceOver (Mac/iOS) et effectue des actions qui déclenchent des messages : ajout au panier, envoi de formulaire, filtrage de résultats. Si le lecteur d'écran ne lit pas le message, il manque aria-live.
  • Audit Mynto : le scanner détecte les éléments dont le contenu est modifié dynamiquement sans attribut aria-live ou role approprié.
  • DevTools : inspecte les messages de confirmation. S'ils n'ont pas role="status", role="alert", aria-live="polite" ou aria-live="assertive", ils sont silencieux pour les lecteurs d'écran.

Comment corriger

Avant - HTML
<!-- Message de confirmation sans ARIA : silencieux pour les lecteurs d'écran -->
<div class="message-succes">Article ajouté au panier</div>
Après - HTML
<!-- Avec role="status" : annoncé sans déplacer le focus -->
<div class="message-succes" role="status" aria-live="polite">
  Article ajouté au panier
</div>

Ajoute role="status" sur le conteneur du message. Cela suffit pour que les lecteurs d'écran l'annoncent quand son contenu change.

Règle du conteneur persistant : l'élément avec aria-live doit exister dans le DOM AVANT que le message soit injecté. Si tu crées dynamiquement un <div> avec aria-live et que tu injectes le texte en même temps, certains lecteurs d'écran ratent l'annonce.

Bonne pratique : place un conteneur aria-live vide dans le HTML de la page, et injecte le texte dedans via JavaScript quand nécessaire.

Sur WordPress avec WooCommerce, les fragments de panier ont souvent des messages de mise à jour non annoncés. Ajoute role="status" sur le conteneur .woocommerce-message via un hook PHP ou un script dédié.

Questions fréquentes

Quelle différence entre role="status" et role="alert" ?

role="status" (ou aria-live="polite") attend la fin du discours en cours avant d'annoncer. role="alert" (ou aria-live="assertive") interrompt immédiatement la lecture. Utilise alert uniquement pour les erreurs critiques nécessitant une action immédiate.

Faut-il vider le conteneur entre deux messages successifs ?

Oui. Certains lecteurs d'écran n'annoncent pas un nouveau message si le texte est identique au précédent. Vide le conteneur (texte vide) avant d'injecter le nouveau message, même brièvement via setTimeout(0).

Les toasts ou snackbars sont-ils couverts par ce critère ?

Oui. Un toast qui apparaît en bas d'écran après une action est un message de statut. Il doit avoir role="status" ou role="alert" selon son urgence pour être restitué par les lecteurs d'écran.

À lire aussi

Cette erreur est-elle sur ton site ?

Lance un audit Mynto gratuit. Tu sauras en quelques minutes si ton site est concerné, sur quelles pages, et avec quel impact.