Live regions ARIA : aria-live et ses analogues alert, log, status

Des régions en direct live

Derrière la dénomination « live regions », on trouve un ensemble de propriétés ARIA dont la fonction est d’informer l’utilisateur ou l’utilisatrice que des changements se sont produits dans la page.

Lorsque ces propriétés sont appliquées sur des zones de contenu dynamique, elles indiquent aux lecteurs d’écran les modifications de contenu afin qu’ils les vocalisent.

Cette technique permet de s’assurer que les informations importantes qui apparaissent dans la page sont bien restituées aux personnes aveugles ou très malvoyantes ; sans quoi, elles passeraient à côté de ces informations, ce qui créerait un problème grave d’accessibilité.

Par exemple : une notification d’erreur qui apparaît dans un coin de la page à la suite d’une action doit être restituée.

Les live regions en pratique : alert, status et log

Concrètement, ARIA met à disposition trois rôles permettant de définir des live regions : alert, status et log. Ces rôles sont eux-mêmes des dérivés de la propriété aria-live, sur laquelle nous reviendrons.

Ainsi, tout contenu inséré dans un élément HTML portant l’un de ces rôles sera automatiquement restitué par le lecteur d’écran, avec certaines spécificités détaillées ci-dessous :

• role="alert" : ce rôle transmet des messages considérés comme importants, voire urgents. Les messages sont vocalisés dès qu’ils sont rendus disponibles aux technologies d’assistance, interrompant tout restitution vocale en cours ;
• role="status" : ce rôle concerne des messages moins prioritaires. À la différence des messages d’une zone alert, ici les contenus sont vocalisés lorsqu’ils sont rendus disponibles aux technologies d’assistance en attendant la fin de toute autre restitution vocale en cours ;
• role="log" : ce rôle transmet des messages qui « s’empilent », comme des notifications qui se succèdent. Lors de chaque ajout dans la zone, seul le nouveau contenu est restitué et non la totalité, sans interrompre une éventuelle restitution vocale en cours.

Il convient donc de choisir chaque rôle ARIA avec précaution.

Par exemple, dans le cas d’une liste de notifications, le choix d’un rôle ARIA status ou alert au lieu de log ruine totalement l’effet désiré : en effet, à chaque nouvelle notification, c’est la liste entière qui est restituée !

Pour tester la restitution de ces contenus dynamique, accédez à la page de démo ci-dessous, lancez votre lecteur d’écran et cliquez sur les différents boutons.

Précisions sur aria-live

Enfin, il faut savoir que les rôles alert, status et log sont dérivés d’autres propriétés ARIA et qu’il est donc tout à fait possible d’en reproduire les effets en utilisant les propriétés suivantes :

• aria-live : cette propriété définit une live region. Deux valeurs sont possibles pour permettre la restitution des mises à jour de contenu :
  • aria-live="polite" : cela indique que le message attendra la fin d’une éventuelle restitution en cours,
  • aria-live="assertive" : cela indique que le message interrompra toute restitution en cours,
  • note : la valeur par défaut de aria-live est off ;
• aria-atomic : utilisée conjointement à aria-live, cette propriété précise la quantité d’information à restituer. Deux valeurs sont possibles :
  • aria-atomic="false" (valeur par défaut) : seules les parties ayant subi un changement seront restituées,
  • aria-atomic="true" : tout le contenu sera restitué.

Ainsi, <div aria-live="polite" aria-atomic="true"> est l’équivalent de <div role="status">.

Correspondance entre les rôles ARIA alert, status, log et les propriétés aria-live, aria-atomic

Quelle méthode privilégier ?

Concrètement, il n’y a pas de grande différence de restitution entre l’utilisation de role et de aria-live.

Le role ajoute une sémantique que ne transmet pas la propriété aria-live, en définissant un type de message à restituer. Indication qui peut ou non être exploitée par les lecteurs d’écrans.

Par exemple, NVDA annonce « alerte » avant les mises à jour de contenu de <div role="alert">, mais pas avant les mises à jour de contenu de <div aria-live="assertive">.

Le prochain article montrera en revanche que la bonne restitution par les lecteurs d’écran n’est pas garantie selon la propriété utilisée, ce qui pèsera davantage dans le choix de celle-ci.

Les live regions ARIA dans le RGAA 4

Le RGAA 4 parle de « message de statut » pour faire référence aux contenus qui devraient utiliser les live regions ARIA.

Le référentiel y dédie un critère, le critère 7.5 et en donne la définition suivante dans son glossaire :

Un message de statut informe l’utilisatrice d’un changement de contenu dans la page sans interrompre son activité principale (il n’y a pas de changement de contexte par exemple un repositionnement du focus sur le message).

Le critère s’attache à vérifier que ces messages de statut sont correctement restitués :

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

Pour cela, il propose 3 tests, basés sur la nature du message :

Test 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" ?

Test 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" ?

Test 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" ?

Il est également précisé en note technique que les équivalents aria-live/aria-atomic sont autorisés et conformes.

Si l’on s’attarde sur ces trois tests, les deux premiers ne posent pas de difficulté, mais le troisième peut poser question.

Message de statut de progression

En effet, le test 7.5.3 du RGAA 4 couvre les indications de « progression d’un processus », c’est-à-dire une barre de progression ou un loader qui apparaîtraient lors d’un chargement de données par exemple.

Nous reviendrons en détail dans un instant sur le rôle progressbar, car il ne s’agit pas d’une live region au sens strict : néanmoins, il peut être utilisé comme base d’une implémentation qui va en reproduire le comportement, c’est-à-dire restituer une information (ici concernant une progression) en temps réel.

Attardons-nous par contre sur les deux autres techniques proposées pour valider ce test.

• Le rôle status pourrait par exemple être utilisé sur un texte « Chargement en cours » pour signifier à l’utilisateur qu’un processus est en cours et qu’il doit attendre la fin de ce processus pour recommencer à interagir avec la page (voir la démonstration ci-après). Nous vous conseillons d’utiliser cette solution uniquement s’il n’est pas possible d’implémenter un progressbar, et uniquement pour des temps de chargements rapides. En effet, cette méthode, bien que conforme, a pour inconvénient de n’informer l’utilisatrice qu’au début du processus, et non tout du long. Or, pour un processus de plusieurs dizaines de secondes, les utilisateurs et utilisatrices risquent de ne pas comprendre que le processus est toujours en cours.
• Le rôle log est proposé également. Sur le principe, celui-ci devrait être réservé à des contenus historisés et serait peu adapté pour restituer des temps de chargement. Mais on pourrait l’utiliser par exemple dans le cas d’indications de progression consistant en une succession d’étapes : « Nom de l’étape 1 : terminée ; Nom de l’étape 2 : terminée ; Nom de l’étape 3 : en cours », etc. Attention : ce rôle serait inapproprié pour indiquer la présence d’un loader graphique animé, par exemple.

Pour tester la restitution d’une indication de chargement utilisant le rôle status, accédez à la page de démo ci-dessous, lancez votre lecteur d’écran et cliquez sur le bouton de test.

Ici, l’exemple utilise le texte visible « Chargement en cours » , mais on pourrait tout aussi bien utiliser un texte positionné hors écran, ou encore une image possédant une alternative textuelle (par exemple <img src="loader.gif" alt="Chargement en cours" />).

Rôle ARIA progressbar

De manière générale, nous vous recommandons si possible d’utiliser un rôle progressbar pour indiquer vos temps de chargements, plutôt qu’un rôle status.

Certes, l’implémentation de progressbar nécessite un peu plus de travail, mais sa restitution offrira une meilleure expérience utilisateur !

Tout comme un rôle status, un rôle progressbar permet à l’utilisatrice de comprendre qu’un processus a été déclenché (par exemple, le début d’un chargement de données).

Mais, contrairement au rôle status, il l’informe en plus de la progression du chargement jusqu’à son terme. C’est là sa valeur ajoutée !

En l’absence d’un tel dispositif, l’utilisatrice n’est pas avertie que le processus est toujours en cours, et pourrait tenter d’accéder ou interagir avec des contenus obsolètes, ou bien poursuivre sa consultation sans prendre connaissance d’un contenu chargé ensuite plus haut dans la page.

Visuellement, une indication de chargement en cours pourrait être représentée au moyen d’un loader animé ou bien d’une barre de progression par exemple. Cette indication visuelle peut être retransmise par les lecteurs d’écrans grâce au rôle progressbar.

Selon le lecteur d’écran ou son paramétrage, et selon le navigateur utilisé, la restitution vocale consistera à annoncer le pourcentage de chargement en cours, ou à émettre des signaux sonores répétitifs (des « bips » sur NVDA).

Pour tester la restitution du progressbar, lancez votre lecteur d’écran et cliquez sur le bouton de la démonstration ci-dessous :

Points d’attention sur le rôle ARIA progressbar

Quelques points d’attention concernant l’implémentation : la présence seule du rôle progressbar sur l’élément visuel ne déclenche aucune vocalisation.

Pour que la mise à jour de contenu soit détectée, il faut lui associer d’autres propriétés ARIA :

• aria-valuemin : définit la valeur numérique minimum de progression ;
• aria-valuemax : définit la valeur numérique maximum de progression ;
• aria-valuenow : définit la valeur numérique courante de progression. Avec NVDA, si l’utilisatrice choisit de faire restituer des « bips », la tonalité du bip changera en même temps que cette valeur : plus la valeur est proche du minimum, plus la tonalité est basse, plus la valeur est proche du maximum, plus la tonalité est haute. Cela donne une représentation sonore de la progression du plus bel effet ;
• aria-valuetext (optionnel) : définit une valeur alternative textuelle à aria-valuetext. Si elle est définie, c’est cette valeur qui devrait être restituée plutôt que celle d’aria-valuenow (peut dépendre du paramétrage du lecteur d’écran).

Côté JavaScript, il s’agit de mettre à jour la valeur d’aria-valuenow (et aria-valuetext si existante) de manière dynamique.

Ainsi, dans l’exemple donné ci-dessus, une simple boucle est créée sur un intervalle de X millisecondes et incrémente la valeur d’un pas de Y sans se soucier d’atteindre ou non la valeur d’aria-valuemax à la fin du chargement.

Si la valeur d’aria-valuenow atteint celle d’aria-valuemax avant que le chargement soit terminé, il suffit d’en reprendre l’incrémentation à partir de zéro.

Gestion du focus avec un rôle ARIA progressbar

Pour terminer, un dernier point d’attention est à accorder à la gestion du focus, qui se fait en deux temps :

1. au lancement du chargement, afin de s’assurer de la bonne restitution sur tous les lecteurs d’écrans, il faut déplacer le focus sur l’élément qui a le rôle progressbar ;
2. à l’issue du chargement, cet élément disparaît, causant l’interruption du signal sonore mais aussi la perte du focus de l’utilisateur. Il faut alors repositionner son focus sur un autre élément de façon à lui permettre de poursuivre sa navigation. Dans notre cas, le plus logique est de le repositionner sur le contenu qui vient d’être chargé.

Ressources

• Guide sur les lecteurs d’écrans pour la configuration et l’utilisation de lecteurs d’écrans
• RGAA : Critère 7.5
• WCAG : Critère de succès 4.1.3

Conclusion

Ceci conclut le premier article consacré aux live regions ARIA, à leur fonctionnement et à leur utilisation conformément au RGAA. Bien les connaître, bien les implémenter et ne pas oublier de les tester est important pour s’assurer que les personnes déficientes visuelles utilisant un lecteur d’écran soient au même niveau d’information que les autres.

Dans un prochain article, nous nous intéresserons aux tests de restitution qui, comme vous pourrez le constater, peuvent donner des résultats assez aléatoires, dépendant de plusieurs facteurs.