RGAA Lab

RGAA 4.1.2 · Scripts · Critère 7.5

Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ?

« Article ajouté au panier », « 3 résultats », « Mot de passe trop court » : ces messages apparaissent sans déplacer le focus. Sans région d'annonce, ils sont invisibles pour qui ne regarde pas l'endroit où ils s'affichent.

Ce que dit le référentiel

Transcription du RGAA 4.1.2, sans interprétation. C’est ce texte qui fait foi, et celui que vous citez dans un rapport.

  1. 7.5.1
    Chaque message de statut qui informe de la réussite, du résultat d’une action ou bien de l’état d’une application utilise-t-il l’attribut WAI-ARIA role="status" ?
  2. 7.5.2
    Chaque message de statut qui présente une suggestion, ou avertit de l’existence d’une erreur utilise-t-il l’attribut WAI-ARIA role="alert" ?
  3. 7.5.3
    Chaque message de statut qui indique la progression d’un processus utilise-t-il l’un des attributs WAI-ARIA role="log", role="progressbar" ou role="status" ?

Comment le vérifier

  1. Provoquer les messages de la page : soumettre un formulaire incomplet, filtrer une liste, ajouter un article, lancer un traitement long.
  2. Classer chacun. Réussite, résultat d'une action, état de l'application : role="status". Erreur ou suggestion de correction : role="alert". Progression d'un traitement : role="log", role="progressbar" ou role="status".
  3. Vérifier que le conteneur porte le rôle avant que le message y soit injecté : un rôle ajouté en même temps que le texte n'est pas toujours annoncé.
  4. Vérifier avec un lecteur d'écran que le message est effectivement lu, et une seule fois.
  5. Écarter ce qui n'est pas un message de statut : si le focus se déplace vers le message, ou s'il s'agit d'un changement de contexte, ce critère ne s'applique pas.

Ce que notre outil fait

Assisté

Le moteur repère les éléments concernés et vous pose la question. Il ne conclut pas à votre place.

Un message de statut n'existe qu'à l'instant où il apparaît : une analyse du DOM au chargement ne le voit pas. L'outil peut relever les régions d'annonce déjà déclarées dans la page, ce qui aide à savoir ce qui est prévu — mais constater qu'un message apparaît hors de toute région demande de le déclencher, et c'est vous qui le déclenchez.

Comment nous mesurons ce que l'outil sait faire · ce critère s'audite dans l'extension RGAA Lab.

Les pièges

Les erreurs qu’on rencontre vraiment, relevées au fil des audits.

  • Un conteneur créé et inséré avec son role="alert" d'un seul coup n'est souvent pas annoncé : la région doit préexister, vide, et recevoir le texte ensuite.
  • role="alert" interrompt l'utilisateur en cours de lecture. Le réserver aux erreurs : l'employer pour « Enregistré » rend la page hachée.
  • Un compteur de résultats mis à jour à chaque frappe dans une région assertive produit un bavardage ininterrompu. polite laisse finir la phrase en cours.
  • Une erreur de saisie affichée sous un champ relève aussi du 11.10 : même message, deux exigences distinctes — être annoncé, et dire quoi corriger.

À lire avec