WCAG AA Prestataire Complexe

Les messages de confirmation, d'erreur et de progression de votre site sont-ils annoncés par les logiciels de lecture ?

Critère officiel 7.5 — Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ?

Pourquoi c'est important

Après avoir soumis un formulaire, une personne aveugle attend de savoir si l'opération a réussi. Si le message de confirmation apparaît visuellement sans être annoncé par le logiciel de lecture, elle ne sait pas si sa demande a bien été prise en compte — et peut relancer le formulaire inutilement, engendrant des doublons.

Exemples concrets

Ce qui est conforme

Après l'envoi d'une demande de renseignements, le message « Votre message a bien été envoyé. Vous recevrez une réponse dans les 5 jours ouvrés. » est annoncé immédiatement par le logiciel de lecture, sans que l'utilisateur ait à le chercher.

Ce qui pose problème

Le même message de confirmation apparaît visuellement en haut de la page, mais n'est pas déclaré pour être annoncé automatiquement. La personne aveugle, dont le focus est resté sur le bouton d'envoi, n'entend rien et ne sait pas si le formulaire a été traité.

Comment agir

Lors de tout développement ou mise à jour d'un formulaire de contact, d'inscription ou de demande en ligne, incluez dans le cahier des charges : « Les messages de confirmation, d'erreur et de chargement doivent être annoncés automatiquement par les lecteurs d'écran via les attributs ARIA role="status" et role="alert". »

Règles clés

  • Préparer les regions live dans le DOM au chargement de la page (vides), pas au moment du message.
  • aria-live="polite" pour les messages informatifs non urgents : confirmations, résultats de recherche, mises à jour de compteurs.
  • role="alert" (équivalent aria-live="assertive") uniquement pour les erreurs critiques qui nécessitent une attention immédiate.
  • role="status" (équivalent aria-live="polite" + aria-atomic="true") pour les messages de statut courts.
  • Ne pas déplacer le focus ET utiliser une region live pour le même message — choisir l'un ou l'autre.
  • aria-atomic="true" sur la region live pour que le message soit annoncé en entier, pas mot par mot.

Erreurs fréquentes

  • Message de confirmation affiché visuellement mais sans region live — jamais annoncé par le lecteur d'écran
  • Utilisation de role="alert" pour des messages informatifs non urgents — interrompt la lecture de façon agressive
  • Region live présente dans le DOM mais vide au chargement, puis remplie au moment du message — correct
  • Region live créée dynamiquement au moment du message — trop tard, les AT ne l'ont pas détectée
  • Message annoncé ET focus déplacé sur le message — double annonce, perturbant
  • Compteur de résultats mis à jour sans region live ('3 produits trouvés')

Exemples de code

confirmation sans live region

✗ Non conforme
// Après ajout au panier :
document.getElementById('message').textContent =
  'Article ajouté au panier';
document.getElementById('message').style.display = 'block';

<!-- HTML -->
<div id="message" style="display:none;"
  class="alert-success">
</div>

Le message apparaît visuellement mais aucune region live ne l'annonce. L'utilisateur de lecteur d'écran n'en saura rien.

confirmation avec live region polite

✓ Conforme
<!-- Region live déclarée au chargement, vide -->
<div
  role="status"
  aria-live="polite"
  aria-atomic="true"
  id="messages-statut"
  class="sr-only"
></div>

<!-- Script après ajout au panier -->
<script>
function annoncerStatut(message) {
  const region = document.getElementById('messages-statut');
  // Vider puis remplir pour forcer la relecture
  region.textContent = '';
  // Délai minimal pour que le changement soit détecté
  setTimeout(() => {
    region.textContent = message;
  }, 50);
}

// Usage :
annoncerStatut('Article ajouté au panier. Total : 3 articles.');
</script>

La region avec role="status" est présente dans le DOM dès le chargement. Le message est injecté après l'action. aria-atomic="true" assure que le texte complet est annoncé. La classe sr-only masque visuellement la region sans la cacher aux AT.

erreur critique avec role alert

✓ Conforme
<!-- Region d'alerte, vide au chargement -->
<div
  role="alert"
  id="erreur-critique"
  class="sr-only"
></div>

<!-- À l'échec de la soumission du formulaire -->
<script>
function signalerErreurCritique(message) {
  document.getElementById('erreur-critique').textContent = message;
}

// Usage :
signalerErreurCritique(
  'Échec de la sauvegarde. Votre connexion a été interrompue.'
);
</script>

role="alert" interrompt immédiatement la lecture du lecteur d'écran — réservé aux erreurs réellement urgentes. Pour un message comme 'Formulaire soumis avec succès', utiliser role="status" à la place.

compteur de résultats de recherche

✓ Conforme
<!-- Region live pour les résultats de recherche -->
<p
  role="status"
  aria-live="polite"
  aria-atomic="true"
  id="compteur-resultats"
></p>

<script>
function mettreAJourCompteur(nombre) {
  const el = document.getElementById('compteur-resultats');
  el.textContent = nombre === 0
    ? 'Aucun résultat trouvé.'
    : `${nombre} résultat${nombre > 1 ? 's' : ''} trouvé${nombre > 1 ? 's' : ''}.`;
}
</script>

Le compteur de résultats est une region live visible — l'utilisateur voyant et le lecteur d'écran reçoivent l'information. La formulation est explicite ('résultats trouvés') pour être compréhensible hors contexte.

Référence WCAG : 4.1.3

La lettre de l'Atelier A11Y

Ressources pédagogiques, critères RGAA commentés et retours de terrain : une lettre mensuelle pour progresser sur l'accessibilité numérique, sans jargon.

  • Nouveaux articles et ressources pédagogiques
  • Critères RGAA décortiqués avec des exemples concrets
  • Bonnes pratiques et retours d'expérience terrain
S'abonner à la newsletter (s'ouvre dans un nouvel onglet)

Gratuit. Désabonnement possible à tout moment.