Live regions ARIA : bonnes et mauvaises pratiques

Les live regions ARIA (littéralement « régions en direct ») permettent de faire restituer une information par les lecteurs d’écrans lors de son apparition, et ainsi éviter d’éventuelles pertes d’information.

Il est essentiel de prévenir les personnes aveugles et malvoyantes de ces mises à jour dynamiques : grâce aux articles déjà publiés sur les live regions ARIA, vous savez déjà comment.

Cependant, ces live regions doivent être utilisées avec précaution, au risque de détériorer l’expérience utilisateur plutôt que de l’améliorer.

Voici quelques exemples concrets pour comprendre dans quels cas les live regions ARIA sont appropriées, et dans quels cas il faut au contraire les éviter.

Mais avant toute chose, il est nécessaire de comprendre ce qui déclenche la parole d’un lecteur d’écran.

Remarque préalable

Les exemples présentés dans cet article impliquent uniquement des comportements qui se déclenchent de façon dynamique, au moyen de JavaScript.

Les live regions ARIA comme role="status", role="alert" ou la propriété aria-live seraient totalement inappropriées dans le cas d’actions déclenchant des rechargements de page.

Quand les lecteurs d’écran parlent-ils ?

Les lecteurs d’écran semblent souvent très bavards aux personnes qui les utilisent pour la première fois. Pourtant, ils ne parlent que lorsqu’il y a quelque chose à dire.

On dit qu’ils « restituent » l’information, et cela au moyen d’une synthèse vocale ou d’une plage braille.

Cette restitution se déclenche :

  • quand un élément dans la page reçoit le focus : l’élément est restitué ;
  • quand l’élément qui a le focus subit un changement (de nom ou description par exemple) : les changements sont restitués, ou l’élément en totalité selon le lecteur d’écran ;
  • quand une modification se produit à l’intérieur d’une live region : le texte de la live region est restitué.

Qu’est-ce que ça a à voir avec les live regions ARIA ?

Les personnes aveugles n’ont pas une perception globale de la page, mais uniquement de l’endroit précis de la page où se trouve le focus du lecteur d’écran à un instant T.

Pour cette raison, elles ont besoin :

  • d’être averties des informations survenant ailleurs dans la page, et qui ont de l’importance dans l’immédiat ;
  • de recevoir des retours d’action afin de comprendre que leurs actions ont déclenché quelque chose.

Si les live regions ARIA permettent de répondre à ces besoins dans de nombreux cas, elles sont inappropriées dans d’autres

Comprendre ce qui déclenche la restitution est essentiel non seulement pour détecter les situations qui posent des problèmes de compréhension ou des pertes d’informations aux personnes aveugles, mais aussi pour choisir la solution la mieux adaptée à chacune de ces situations.

Et cette solution peut être, ou ne pas être, une live region.

Exemples de bonnes pratiques avec les live regions ARIA

Notifier la réussite ou l’échec d’une action de l’utilisateur

Commençons par le cas le plus classique : les messages qui apparaissent après une action de l’utilisateur.

On les trouve le plus souvent dans un coin ou en bas de l’écran, mais ils peuvent se présenter de différentes façons visuellement.

Ces messages n’ont de sens que s’ils sont restitués au moment où ils apparaissent parce qu’ils sont directement liés à l’action qui vient d’être réalisée.

C’est pour cette raison qu’ils disparaissent en général après quelques secondes : le message n’aurait pas de sens si l’on y revenait plusieurs minutes plus tard.

Ces messages sont importants car ils donnent un retour sur l’action qui vient de se produire et transmettent parfois des informations essentielles, notamment une situation d’échec.

Par exemples :

  • un bouton « Copier le lien » déclenche l’apparition d’un message : « L’URL est copiée dans le presse-papier » ;
  • dans un module de téléversement de fichier, la sélection d’un fichier au format PDF déclenche l’apparition d’un message : « Mauvais format de fichier : seuls JPG, Gif et PNG sont acceptés ».

L’utilisation d’une live region comme role="status", role="alert" ou la propriété aria-live convient très bien pour ce genre de cas.

Annoncer le nombre d’éléments dans une liste en fonction des filtres appliqués

Lorsqu’une page web présente une longue liste d’éléments (résultats de recherche, produits d’un site e-commerce, actualités …), elle propose souvent un moyen de filtrer ces éléments.

Si la mise à jour des résultats se fait avec un rechargement complet de page, il n’y a rien de particulier à faire : le lecteur d’écran restituera le titre de la page et le parcours de tabulation reprendra en début de page.

Cela n’est pas forcément le plus satisfaisant en terme d’expérience utilisateur, mais en tout cas il y aura un retour d’action donné par le lecteur d’écran.

Par contre, lorsque la mise à jour de la liste est faite dynamiquement au moyen de JavaScript, il faut s’assurer que les personnes aveugles et très malvoyantes soient averties des changements en temps réel.

1. Application individuelle des filtres

Si la liste des éléments est mise à jour lors de l’activation de chaque filtre individuellement, il est nécessaire d’en avertir les personnes aveugles et très malvoyantes.

Faute de quoi, elles ne prendront connaissance du nombre de résultats seulement lorsqu’elles atteindront la liste elle-même, ce qui nuira beaucoup à leur expérience utilisateur.

Un texte « X éléments trouvés » (ou équivalent) précède généralement la liste, ou peut être ajouté s’il n’existe pas.

Il suffit alors de créer une live region autour de ce texte, pour qu’il soit restitué de manière automatique à chaque fois que le nombre de résultats est mis à jour.

2. Application de tous les filtres en une fois

L’enjeu est moins important dans le cas où l’utilisatrice doit d’abord sélectionner des filtres puis déclencher la mise à jour de la liste au moyen d’un bouton. Mais il est tout de même nécessaire d’avoir un retour d’action à propos de l’activation du bouton.

Si la mise à jour de la liste des éléments entraîne un temps de chargement, représenté par exemple par un loader, une live region ARIA comme progressbar ou role="status" ou role="alert" devrait être utilisée pour indiquer à l’utilisatrice de patienter avant de consulter la liste.

Ensuite, qu’il y ait un temps de chargement ou non, vous pouvez :

  • soit utiliser une live region ARIA autour du texte « X éléments trouvés » comme dans le cas précédent ;
  • soit déplacer le focus de l’utilisatrice sur ce texte, ce qui déclenchera automatiquement sa restitution.

Pour en savoir plus : Reprise de focus et accessibilité par Jean-Pierre Villain.

Annoncer la mise à jour du montant total d’un panier d’achat

Sur les sites e-commerce, la page « panier » ou « récapitulatif de commande » présente la liste des articles mis au panier avec la possibilité de modifier la quantité pour chacun d’eux.

Le montant total de la commande est détaillé à la suite. Lorsqu’on modifie une quantité, ce montant total est mis à jour dynamiquement.

Tout comme pour l’exemple précédent, il est intéressant d’informer l’utilisateur des effets de ces changements. Cela lui évite d’avoir à se déplacer jusqu’à l’information modifiée pour vérifier le résultat de son action.

À nouveau, une live region ARIA est la solution idéale. Ici, il faut la définir autour du texte « montant total : X euros ».

Attention néanmoins au type de live region que vous utiliserez : privilégiez un role="status" ou éventuellement role="alert", mais surtout pas de role="log" qui ne restitue que les textes modifiés (par exemple : seulement le prix, et pas « montant total : [prix] »).

De même, si vous utilisez la propriété aria-live plutôt qu’un role, pensez à définir la propriété aria-atomic="true" pour les mêmes raisons.

Notifier la réception de nouveaux messages dans une messagerie instantanée

Les live regions ARIA sont particulièrement appropriées dans les modules de messagerie instantanée, pour avertir les utilisateurs que de nouveaux messages ont été reçus.

Il suffit pour cela de définir la live region autour de la liste des messages.

Ainsi, à chaque fois qu’un nouveau message sera reçu, il sera automatiquement restitué par le lecteur d’écran.

Piège à éviter

Attention ! L’erreur ici serait de provoquer la restitution de tous les messages à chaque fois qu’un nouveau est reçu.

Pour éviter cela, utilisez un role="log" et surtout pas "alert" ou "status". Vous pouvez également utiliser la propriété aria-live="polite".

Dans ce dernier cas, si vous utilisez aussi la propriété aria-atomic, alors il faut que sa valeur soit false. (Comme il s’agit de la valeur par défaut, vous pourriez ne pas la définir du tout.)

Exemples de mauvaises pratiques avec les live regions ARIA

Notifier une fenêtre de dialogue

Les fenêtres de dialogue, aussi appelées o« fenêtres modales », doivent respecter les principes du motif de conception ARIA Dialog (Modal) Pattern.

Celui-ci permet de reproduire la restitution et le comportement au clavier d’une fenêtre de dialogue native.

Aussi, n’utilisez pas de live regions ARIA pour indiquer la présence d’une fenêtre de dialogue : ce serait totalement inapproprié dans ce cas.

Annoncer le changement de slide d’un carrousel en auto-rotation

Vous pouvez utiliser une live region ARIA autour des slides d’un carrousel afin de déclencher la restitution du contenu actif lorsque l’utilisatrice change de slide. Cela donne un retour d’action approprié, surtout si le contenu des slides est assez bref.

Cependant, n’utilisez jamais de live region autour des slides si le carrousel est en auto-rotation, c’est-à-dire si les slides défilent automatiquement.

Cela serait désastreux pour les personnes utilisant un lecteur d’écran, puisque le contenu des slides serait restitué automatiquement toutes les X secondes.

Précisions sur les carrousels en auto-rotation

Notez aussi que les carrousels qui défilent de manière automatique doivent obligatoirement disposer d’un bouton « pause », conformément au critère 13.8 du RGAA.

L’idéal serait bien entendu de ne jamais faire défiler un carrousel automatiquement, même avec un bouton « pause » à disposition : en effet, le mouvement peut poser des difficultés majeures à de nombreuses personnes, notamment aux personnes ayant des difficultés de lecture ou des troubles de l’attention.

Annoncer le temps restant d’un minuteur

Prenons l’exemple d’une page qui demande de terminer une action en un temps limité, comme répondre aux questions d’un examen. La page affiche un compte à rebours sous forme d’un simple texte au format « 00:12:46 ».

Utiliser une live region ARIA sur ce type de texte serait une très mauvaise idée : imaginez le lecteur d’écran restituer le temps restant toutes les secondes ou même toutes les minutes ! 🤯

Pour autant, il s’agit d’une information importante, surtout lorsque le temps restant approche du terme. Pour avertir sans nuire à l’expérience utilisateur, on pourrait par exemple l’informer une heure avant la fin, puis 15 minutes avant la fin, puis 5 minutes avant la fin, etc.

Pour arriver à ce résultat, utilisez une live region ARIA autour d’un texte qui sera inséré aux moments voulus. Ce texte devra ensuite être supprimé du DOM, directement ou après quelques secondes, car il ne sera pertinent qu’à cet instant.

Ce texte peut être caché au moyen d’un positionnement hors écran, c’est-à-dire invisible à l’écran, mais bien présent dans le code pour les lecteurs d’écran [1]).

De plus, l’ajout d’un titre avant le minuteur serait également intéressant : les lecteurs d’écran permettant de naviguer par titres, il serait alors plus facile pour les personnes qui les utilisent d’accéder à l’information depuis n’importe quel endroit dans la page.

Notifier un formulaire qui se contextualise en fonction de la saisie

Dernier exemple : un formulaire de création de petite annonce contient un champ de sélection de catégorie et sous-rubriques. De nouveaux champs apparaissent à la suite du formulaire selon les options choisies.

Il s’agit d’une mise à jour dynamique qu’il est inutile de notifier : en poursuivant la saisie du formulaire, l’utilisateur prendra naturellement connaissance des nouveaux champs.

Cas particuliers : notification contenant un bouton ou un lien

Les live regions ARIA ne sont pas appropriées pour des notifications contenant un élément interactif, par exemple une notification de suppression avec un bouton d’annulation.

En effet, elles ne permettent ni de restituer qu’il y a un bouton (seul son texte est restitué), ni d’interagir avec celui-ci (le focus reste là où il se trouve).

Il n’existe pour l’instant pas de solution « prête à l’emploi » pour gérer ce genre de composants, qui nécessiterait d’être approfondi dans un billet dédié.

Nous vous recommandons néanmoins à ce sujet la lecture de l’article très détaillé de Sara Soueidan : Accessible notifications with ARIA live regions (Part 2).

Ce qui ne fonctionne pas : notifier au (re)chargement d’une page

L’utilisation de live regions ARIA n’est pas approprié lorsqu’une action déclenche un rechargement de page.

Imaginons que vous définissiez de manière statique l’élément suivant : <div role="alert"><p>Un message d’erreur ou d’alerte</p></div>

Dans ce cas, le lecteur d’écran ne restituera pas le message [2].

C’est normal, car ce sont les changements détectés dans la région live qui déclenchent la restitution. Or, ici, il n’y a pas de changement puisque le texte est présent dans la live region au chargement de la page.

Que faut-il faire alors ? C’est simple : rien.

En effet, la navigation recommence naturellement en début de page lors d’un (re)chargement. L’utilisatrice va parcourir les contenus et finira par atteindre le message d’erreur, à condition que celui-ci se trouve dans un ordre logique parmi le code HTML.

S’il est essentiel que le message soit annoncé dès le (re)chargement de la page, comme après une soumission de formulaire qui retournerait des erreurs, vous pouvez utiliser le titre de la page (balise <title>) pour faire restituer l’information.

Par exemple : <title>Erreur : Formulaire de contact</title>.

Au cas par cas : aides à la saisie et messages d’erreur dans les formulaires

Des indications d’aide ou d’erreur apparaissent parfois dynamiquement lorsque l’utilisatrice remplit des champs de formulaire.

Ces informations importantes risquent de passer inaperçues pour les personnes aveugles et très malvoyantes qui naviguent dans le formulaire en tabulant : en effet, comme la tabulation ne passe pas par les textes statiques (paragraphe ou élément de liste par exemple), ceux-ci ne sont pas restitués par les lecteurs d’écran.

Voici quelques exemples.

Indiquer au fil de la saisie le nombre de caractères restants

Lorsqu’un champ de saisie a une contrainte sur le nombre de caractères, il est souvent accompagné d’un texte dynamique « X caractères restant » ou équivalent. Le nombre de caractères restants est calculé au fil de la saisie et le texte est mis à jour en conséquence.

Cette indication est importante car la saisie est bloquée dès qu’elle atteint la limite fixée, sauf que cela n’est en général pas restitué par les lecteurs d’écran.

Les personnes déficientes visuelles n’ont donc souvent pas conscience que les caractères qu’elles saisissent ne sont pas enregistrés.

Il existe deux solutions :

  • soit définir un role="status" autour de l’indication, afin de que les lecteurs d’écran la restituent à chaque mise à jour ;
  • soit utiliser une propriété aria-describedby [3] pour définir le texte comme description du champ. Le champ ayant le focus lors de la saisie, le lecteur d’écran restituera automatiquement chaque changement sur l’élément (ici : le changement de sa description).

Le lecteur d’écran ne restituera pas le texte à chaque caractère ajouté (heureusement !), mais plutôt lorsque l’utilisatrice fera une pause dans la saisie.

Sur le même sujet : Les écueils du contrôle de saisie dynamique par Adam Silver

Signaler, lors de la saisie, les erreurs sur les règles de mot de passe non respectées

La saisie de nouveau mot de passe doit souvent respecter de nombreuses règles, comme un nombre de caractères minimum, parmi lesquels on doit trouver au moins une minuscule et une majuscule, un chiffre, un caractère spécial, etc.

Pour aider l’utilisateur à saisir un mot de passe valide, des indications dynamiques sont parfois présentes à proximité du champ. Par exemple, les règles non respectées peuvent être listées et mises à jour en fonction des caractères saisis.

Un role="status" permettrait de restituer les indications en même temps qu’elles changent en fonction de la saisie.

Mais l’utilisateur a aussi besoin de retrouver ces indications s’il quitte le champ et y revient par après, ce que ne permet pas la live region, à moins de saisir à nouveau du texte dans le champ.

Dans ce cas-ci, il faut donc définir une description du champ avec la propriété aria-describedby plutôt qu’une live region.

Pourquoi cette différence de traitement entre ce cas et le précédent ? Parce qu’il s’agit ici d’un message d’erreur, essentiel à l’utilisateur pour qu’il puisse corriger la saisie et valider le formulaire.

Alors que dans l’exemple du nombre de caractères restants, l’indication est plutôt informative puisque l’utilisateur ne peut pas causer d’erreur de saisie sur ce champ (il est impossible de saisir davantage de caractères que la limite autorisée).

Annoncer les erreurs de saisie à la perte de focus du champ

Certains formulaires déclenchent l’apparition d’un message d’erreur lorsque l’utilisatrice quitte un champ, si celui-ci reste vide ou s’il contient une erreur.

Dans ce cas, le lecteur d’écran doit restituer le message dès qu’il apparaît, sans quoi l’utilisatrice n’en prendra pas connaissance et poursuivra la saisie des champs suivants jusqu’à soumission du formulaire.

Ce sera seulement à ce moment-là que les erreurs lui seront annoncées, ce qui l’obligera à revenir en arrière pour corriger…

Pour améliorer cela, un message d’erreur doit, comme dans le cas précédents, être restitué non seulement lorsqu’il apparaît, mais également à la prise de focus lorsque l’utilisatrice revient sur le champ en erreur.

Si vous utilisez une propriété aria-describedby comme dans l’exemple précédent, le message d’erreur sera bien restitué à la prise de focus sur le champ, mais pas lorsqu’il apparaît puisqu’il apparaît précisément lorsque le champ perd le focus.

Dans ce cas-ci, il serait donc nécessaire d’utiliser les deux méthodes : la description du champ avec aria-describedby et la live region sur le message d’erreur lui-même.

Annoncer les erreurs de saisie lors de la validation du formulaire

Dans ce dernier exemple, plus classique, tous les messages d’erreur apparaissent simultanément sous les champs concernés après activation du bouton de soumission.

Les live regions ARIA sont absolument à proscrire dans ce cas : en effet, les lecteurs d’écran restitueraient tous les messages les uns après les autres. Ce qui donnerait une expérience utilisateur médiocre, surtout dans le cas de messages assez générique comme « Veuillez saisir ce champ » par exemple.

La meilleure méthode, et celle qui devrait toujours être privilégiée dans les cas similaires, est de définir les messages d’erreurs comme descriptions des champs avec aria-describedby, et de déplacer le focus de l’utilisateur sur le premier champ erroné.

De cette façon, vous guiderez l’utilisateur dans la correction des erreurs en le déplaçant à l’endroit le plus logique pour cela. Et, en donnant le focus au champ, vous déclencherez sa restitution et donc celle du message d’erreur présent dans sa description.

L’utilisateur repassera ensuite sur les champs suivants en tabulant jusqu’au bouton de validation, et prendra connaissance des éventuelles autres erreurs en cours de route.

Conclusion

Vous l’avez compris : les live regions ARIA doivent être utilisées avec précaution au risque de faire plus de mal que de bien.

Lorsque vous intégrez des composants qui déclenchent des mises à jour dynamiques de contenu, posez-vous ces questions :

  • est-il nécessaire que l’utilisatrice soit avertie de cette mise à jour immédiatement ?
  • l’utilisateur reçoit-il bien un retour d’action ?
  • l’information est-elle pertinente au moment de son apparition uniquement ou à tout moment ?
  • est-il nécessaire de déplacer le focus de l’utilisatrice pour la guider au sein du composant ?

Vous serez alors mesure de déterminer la solution la plus adaptée à chaque situation : live region ARIA, changement sur l’élément qui a le focus (ajout de description par exemple), déplacement de focus, ou éventuellement une combinaison de l’un et l’autre.

Pour terminer, n’oubliez pas l’essentiel : testez vos implémentations avec un lecteur d’écran afin d’en vérifier la restitution et de vous assurer que le résultat répond bien aux besoins des utilisateurs concernés.

Approfondissez votre connaissance du développement web accessible

Rejoignez-nous lors d’une prochaine session de formation Développer et coder des sites accessibles pour voir d’autres exemples et approfondir vos connaissances de l’accessibilité numérique côté développement front-end et intégration web.

À l’issue de votre formation, vous pourrez obtenir une certification professionnelle en accessibilité numérique, reconnue par l’État.

Des possibilités de financement existent. N’hésitez pas à nous contacter pour obtenir un devis gratuit !

Notes

  • [1] Voir par exemple la méthode .sr-only. Elle consiste à utiliser des propriétés CSS autres que display et visibility, qui ont pour résultat de cacher le texte pour tout le monde, y compris les lecteurs d’écran, ce qui serait l’inverse de notre besoin ici.
  • [2] Sauf avec NVDA, JAWS et les navigateurs Chromium, qui restituent effectivement le message, uniquement pour role="alert".
  • [3] La propriété aria-describedby doit être définie sur l’élément qui est décrit par le texte. Elle prend pour valeur l’attribut id de ce texte.

Publié le 21 janvier 2025 – Mis à jour le 20 janvier 2025

Catégorie : Développement

Tags : Live regions ARIA, ARIA, Handicaps visuels, JavaScript, Lecteurs d’écran

À propos

  • Cécile Jeanne

    Experte accessibilité numérique

    Cécile Jeanne est experte accessibilité numérique chez Access42 depuis 2020. Forte de son expérience en tant qu’intégratrice web et développeuse front-end, Cécile prend en charge des missions d’audit et d’accompagnement. Elle anime nos formations au développement accessible et à l'audit RGAA. Elle fait aussi partie de notre jury de certification.

Ajouter un commentaire

Le formulaire contient des erreurs. Veuillez vérifier votre saisie puis envoyer à nouveau votre demande s’il vous plaît.

* Champs obligatoires

Veuillez remplir ce champ s'il vous plaît.

Veuillez remplir ce champ s'il vous plaît.