Utiliser le rôle application ARIA
Attention ! Cet article a été écrit en 2016. Son contenu a peut-être besoin d’une mise à jour. Complétez votre veille avec des articles plus récents, par exemple en consultant les nouveautés de notre blog accessibilité numérique, ou en lançant une recherche pour trouver des articles similaires, mais à jour.
Ce billet est une traduction d’un article de Léonie Watson, Using the ARIA application role, publié le 23 avril 2016 sur son blog The Tink Tank.
Il décrit un cas où cette propriété ARIA est utilisée avec succès.
Access42 remercie chaleureusement Léonie pour son autorisation de partager sur notre site la traduction de son article.
Le rôle application ARIA modifie la façon dont les lecteurs d’écran interagissent avec les contenus web. Plusieurs bons articles expliquent, à juste titre, pourquoi le rôle application doit être utilisé avec prudence, ce billet analyse ici un cas dans lequel le rôle application est utilisé à bon escient.
Parfois, les lecteurs d’écran interceptent les touches tapées au clavier pour les réaffecter à des tâches spécifiques aux lecteurs d’écran, comme la navigation dans le contenu via les en-têtes ou la lecture d’une ligne de texte. Le rôle application empêche le lecteur d’écran d’intercepter les frappes et les renvoie au navigateur comme si le lecteur d’écran n’était pas actif.
Ce comportement d’interception implique que certains lecteurs d’écran, en particulier ceux fonctionnant sous Windows, ne fonctionnent pas avec les raccourcis clavier fournis via JavaScript. Le lecteur d’écran intercepte lesdits raccourcis clavier et les utilise à ses propres fins, au lieu de les passer au navigateur et au JavaScript en attente. Lire l’article Time to revisit accesskey pour plus d’informations.
La réponse semble simple à ce stade. Utiliser le rôle application pour empêcher le lecteur d’écran d’intercepter les raccourcis clavier, afin que le JavaScript puisse faire son travail. Le problème, c’est que ça empêchera le lecteur d’écran d’intercepter toutes les frappes, pas seulement celles qui ont pour but d’être utilisées comme raccourcis clavier. En d’autres termes, aucun des raccourcis clavier utilisés pour naviguer et interagir avec le contenu ne sera disponible pour l’utilisateur. Cela diminue sérieusement sa capacité à lire et interagir avec le contenu de façon normale.
La décision d’utiliser le rôle application doit donc être prise avec précaution. Il doit être uniquement utilisé lorsque l’utilisateur de lecteur d’écran n’a pas besoin de se servir des commandes clavier standards mises à sa disposition. Autrement dit, si vous utilisez le rôle application, vous avez la responsabilité de fournir toute l’interaction au clavier.
C’est le cas de l’outil de présentation Shower Presentation Engine de Vadim Makeev. Il s’agit d’un outil basé sur HTML, CSS, ARIA et JavaScript permettant de créer une présentation. Il offre la possibilité d’afficher les diapositives en mode galerie ou mode diaporama et de basculer entre les modes d’affichage grâce au clic, tap ou clavier.
Lorsqu’on est en mode diaporama, l’ensemble des interactions attendues est limité : aller à la diapo suivante/précédente ou aller à la première/dernière diapo. L’outil Shower Engine fournit des raccourcis clavier pour chacune de ces interactions, mais il le fait à l’aide de JavaScript, ce qui entraîne le problème décrit plus haut pour les utilisateurs de lecteurs d’écran sous Windows.
En mode galerie, l’utilisateur d’un lecteur d’écran peut vouloir naviguer dans les diapos via les titres, listes ou autres types d’éléments ou rechercher du contenu par mot, ligne ou paragraphe. Mais lorsqu’on est en mode diaporama et que l’on fait une présentation, on n’a (pratiquement) pas besoin d’utiliser les commandes standards du lecteur d’écran.
Il y a une exception, l’utilisateur de lecteur d’écran doit pouvoir demander le titre de chaque diapo et éventuellement le contenu de chaque diapo lorsqu’elle apparaît. Au lieu de fournir un raccourci clavier spécifique permettant aux utilisateurs de lecteurs d’écran d’effectuer cette action, en mode diaporama, Shower Engine utilise une live region ARIA, qui déclenche automatiquement la lecture du titre et du contenu de chaque diapo lorsqu’elle apparaît.
Le mode diaporama est un cas exceptionnel, c’est l’endroit approprié pour utiliser le rôle application. Il y a un ensemble d’interactions clairement défini, avec un support complet du clavier fourni par JavaScript, sans besoin d’utiliser les commandes standards du lecteur d’écran pendant qu’on fait une présentation.
Grâce à la contribution de Dan Hopkins, Shower Engine utilise le rôle application sur l’élément à chaque fois que le mode diaporama est activé. Lorsqu’on retourne au mode galerie, le rôle application est supprimé et le comportement standard du lecteur d’écran est réactivé.
Les commentaires sont désormais fermés, mais vous pouvez toujours nous contacter pour réagir à cet article !