Live regions ARIA : comment garantir leur restitution par les lecteurs d’écran ?

Vous avez particulièrement intérêt à tester la restitution des propriétés ARIA par les lecteurs d’écran lorsque ces propriétés s’intègrent dans des implémentations utilisant JavaScript.

C’est le cas lorsque vous mettez en place des live regions ou « messages de statut », que ce soit avec les propriétés aria-live et aria-atomic, ou avec un role="alert/status/log" : vous utilisez JavaScript pour déclencher l’apparition du message.

Si votre message de statut n’est pas restitué, alors il n’est pas conforme au regard du RGAA, même si vous avez utilisé les bonnes propriétés ARIA.

Des implémentations différentes pour des résultats identiques ?

Prenez un scénario très classique : un utilisateur appuie sur un bouton, et cela déclenche l’apparition d’un message de notification.

Techniquement, vous utiliserez JavaScript pour détecter l’action de l’utilisateur sur le bouton et déclencher le comportement attendu : faire apparaître le message.

Pour l’apparition du message, vous pourriez opter pour deux approches différentes : créer le message en JS et l’insérer dans le code HTML au moment voulu, ou définir le message dans le code HTML et utiliser CSS pour en contrôler l’affichage.

De plus, que vous utilisiez JS ou CSS, vous pouvez ou bien choisir d’intégrer la live region, vide, dans le DOM dès le chargement de la page, ou bien l’y ajouter en même temps que son contenu au moment où vous faites apparaître le message.

Enfin, vous avez également plusieurs possibilités concernant les propriétés ARIA à utiliser pour la définition de la live region :  role="alert/status/log" ou aria-live (associé si nécessaire à aria-atomic).

Au bout du compte, visuellement, le résultat sera le même quel que soit votre choix d’implémentation : les utilisateurs ne constateront aucune différence. Vous devez maintenant vérifier que c’est également le cas si on utilise un lecteur d’écran.

Tester avec les lecteurs d’écran

Pour vous démontrer l’importance de tester vos implémentations de live regions, nous avons créé deux pages de tests.

Pour tester vous-mêmes :

1. rendez-vous sur la page de test de votre choix :
   • Insertion dynamique du contenu en JS
   • Contrôle de l’affichage avec la propriété CSS display
2. lancez le lecteur d’écran souhaité ;
3. testez les différentes démonstrations de messages de statut.

Vous pourrez constater par vous-mêmes les écarts de restitutions selon les méthodes utilisées.

Si vous ne disposez pas de lecteur d’écran, vous pouvez directement consulter les sections « Résultats des tests de restitution » des pages de tests ».

Nous vous encourageons tout de même à réaliser vos propres tests : en effet, les nôtres datent de février 2024. Comme les navigateurs et les lecteurs d’écran évoluent, les résultats de ces tests pourraient très bien changer (en bon ou en moins bon) au fil du temps.

De plus, nous n’avons pas testé toutes les implémentations possibles : certaines spécificités de code pouvent donner de mauvaises surprises lors de la restitution par les lecteurs d’écran.

Note sur les lecteurs d’écran utilisés pendant nos tests

Le RGAA encadre les tests de restitution avec précision.

En effet, le document « Environnement de test » décrit les combinaisons de système d’exploitation/navigateur/lecteur d’écran à utiliser pour évaluer la conformité de certains critères, dont le critère 7.5 qui concerne les messages de statut.

Dans le cadre de cet article, nous avons testé la restitution de nos pages de démonstration avec les combinaisons de navigateurs et lecteurs d’écran décrites par le RGAA, mais nous avons aussi ajouté d’autres combinaisons afin d’inclure les navigateurs Chrome et Edge sur ordinateur.

Constat

1. Environnement de bureau versus mobile

Carton plein pour l’environnement mobile puisqu’on ne relève aucun problème de restitution, quelle que soit la méthode utilisée pour déclencher l’apparition du message de statut.

En environnement bureau, les choses sont bien différentes. Nous détaillons ci-dessous…

2. JavaScript versus CSS

Pour chaque test effectué, on obtient strictement le même résultat de restitution avec les deux méthodes : insertion de la live region dans le code HTML au moyen de JavaScript, ou affichage de la live region au moyen de CSS.

Le choix de la méthode n’a donc aucune importance, contrairement au fait que la live region existe dans le DOM dès le chargement de la page ou soit au contraire ajoutée au moment de l’activation du bouton…

3. Présence de la live region dans le DOM au chargement versus insertion à l’activation du bouton

On constate de nombreux problèmes de restitution lorsque la live region (c’est-à-dire l’élément qui possède le  role="alert/status/log" ou la propriété aria-live) est insérée en même temps que son contenu dans le DOM.

Pour les démonstrations que nous avons montées, 75 % des tests effectués échouent en environnement bureau.

À l’inverse on obtient de très bons résultats lorsque la live region existe dans le DOM avant que son contenu n’y soit ajouté. Pour les démonstrations que nous avons montées, tous les tests réussissent SAUF avec le couple JAWS/Firefox.

4. role versus aria-live

Enfin, deux spécificités ressortent des tests effectués :

• Uniquement avec le couple JAWS/Firefox, on constate que pour les live region définies avec la propriété aria-live, les messages de statut ne sont jamais restitués si la valeur d’aria-atomic est définie à true. Si la valeur d’aria-atomic est définie à false, alors le message est bien restitué.
• Enfin, on observe que lorsqu’on utilise un role="alert" pour définir une live region, le message de statut est toujours restitué, quels que soit la méthode d’insertion, la présence ou non de la live region dans le DOM au chargement, et le couple lecteur d’écran/navigateur.

Conclusion

La principale conclusion que vous devez tirer de ces tests, c’est que vous devez impérativement tester l’implémentation de vos live region avec des lecteurs d’écran afin de vous assurer que les mises à jour dynamiques de contenus sont bien restituées, puisque les cas d’échec de restitution sont assez nombreux.

Techniquement, le plus important est que la live region soit présente dans le DOM au chargement de la page, ou du moins avant que son contenu y soit inséré. Dans le cas contraire, la restitution vocale est largement compromise.

Si c’est impossible, alors l’utilisation du role="alert" vous sauvera la mise puisqu’il valide 100 % des tests effectués.

À ce sujet : le RGAA recommande d’utiliser rôle="alert" uniquement pour les messages de statut « qui présentent une suggestion ou avertissent de l’existence d’une erreur » ^[1].

Cependant, les messages définis avec role="alert" et role="status" ayant une restitution très similaire ^[2], on peut raisonnablement choisir de les utiliser indifféremment lorsqu’il s’agit de traiter un problème de restitution : mieux vaut une restitution dont la sémantique ne colle pas tout à fait au type de message plutôt que pas de restitution du tout !

Dernier point d’attention : évitez d’utiliser la propriété aria-atomic avec la valeur true, car elle met en échec la restitution du message de statut avec le couple JAWS/Firefox, et rendra donc non conforme le critère 7.5 du RGAA.

Enfin, si les live region ARIA sont très pratiques pour résoudre des problèmes de perte d’informations en temps réel, elles peuvent également nuire à l’expérience utilisateur ou carrément poser des problèmes bloquants si elles sont mal utilisées. C’est ce que nous verrons dans un prochain article !