ARIA: poison ou antidote ?

Comment mentir aux lecteurs d'écran guérit l'accessibilité, alors qu'il n'y ajoute pas de sel !

Aaron Leventhal

Qu'est-ce que les flux ARIA ?

ARIA permet aux auteurs Web de créer une réalité alternative, visible uniquement par les lecteurs d'écran 🤥

Parfois, il est nécessaire d'expliquer la vérité ou même de "mentir" complètement aux lecteurs d'écran ce qui se passe dans le contenu Web. Par exemple, "l'attention est vraiment là !" ou "C'est vraiment un curseur !". C'est comme si vous ajoutiez des notes magiques aux outils et aux widgets de votre établissement. Ces notes magiques autocollantes font croire à tout le monde ce qui est écrit dessus.

Chaque fois qu'une note magique existe, elle remplace notre croyance quant à ce qu'est chaque outil ou quelque chose à propos de l'outil. Exemple: "Ce truc ici est un pistolet à colle !". Même s'il s'agit encore d'une boîte bleue vide sur l'étable, la note magique nous fera voir qu'il s'agit d'un pistolet à colle. Nous pouvons également ajouter : "et il est rempli à 30 % !". Le lecteur d'écran indique maintenant qu'il y a un pistolet à colle à 30 %.

Pour le Web, l'équivalent consiste à prendre un élément de zone simple (un div) contenant une image, et à utiliser ARIA pour indiquer qu'il s'agit d'un curseur à la valeur 30 sur 100.

Qu'est-ce qui n'est pas ARIA ?

ARIA n'a aucune incidence sur l'apparence des pages Web ni sur le comportement d'un utilisateur de la souris ou du clavier. Seuls les utilisateurs de technologies d'assistance remarqueront les différences par rapport aux flux ARIA. Les développeurs Web peuvent ajouter n'importe quelle ARIA arbitraire sans affecter les utilisateurs qui n'utilisent pas de technologie d'assistance.

Bonne lecture: ARIA n'a aucun effet sur la sélection au clavier ou l'ordre de tabulation. Tout se fait en HTML, parfois avec des extraits de JavaScript.

Comment fonctionne ARIA ?

Un lecteur d'écran ou une autre technologie d'assistance demande aux navigateurs des informations sur chaque élément. Lorsque des éléments ARIA sont présents sur un élément, le navigateur reçoit les informations et modifie les informations fournies au lecteur d'écran à propos de cet élément.

Pourquoi utiliser les flux ARIA ?

Pourquoi mentirions-nous un jour à nos utilisateurs ?

Supposons que la boutique en ligne locale ne vend pas tous les widgets dont nous avons besoin. Mais nous sommes MacGyver. Nous pouvons simplement inventer nos propres widgets à partir d'autres widgets ! FWIW, les sept objets les plus utilisés par MacGyver sont les couteaux suisses, les chewing-gums, les cordons de chaussure, les allumettes, les trombones, les bougies d'anniversaire et le ruban adhésif. Il les utilise pour fabriquer des bombes et d'autres objets qui ne restent pas sur place. Ceci est assez similaire à un auteur web qui a besoin de créer une barre de menu. Les barres de menu sont tellement utiles que vous pensez qu'elles font partie du code HTML, mais ce n'est pas le cas. Eh bien ! Vous ne pensiez pas que les auteurs seraient satisfaits des liens et des boutons, n'est-ce pas ? L'auteur pourra donc les assembler à l'aide de ses outils préférés: div, images, style, gestionnaires de clics, gestionnaires de touches, spit et ARIA.

Parfois, plutôt que d'utiliser ARIA au maximum, nous l'utilisons simplement en tant qu'amélioration. Il peut être utile d'ajouter quelques éléments ARIA à du code HTML qui fonctionne déjà. Par exemple, nous pouvons faire en sorte qu'une commande de formulaire pointe vers une alerte de message d'erreur liée à une entrée non valide. Ou nous pourrions vouloir indiquer qu'une zone de texte est destinée à la recherche. Ces petits ajustements peuvent rendre les sites web ordinaires plus utilisables avec un lecteur d’écran.

Exemple de barre de menu

Aider les internautes qui cliquent sur la souris

Créons une barre de menu ensemble. Nous affichons plusieurs éléments dans des éléments de zone génériques appelés "div". Chaque fois que l'utilisateur clique sur un élément div, il exécute la commande correspondante. Cool, il fonctionne pour les utilisateurs de clics de souris !

Ensuite, nous rendons le joli. Nous utilisons des CSS, c'est-à-dire des styles, en alignant bien les choses et en les entourant de contours visuels. Nous la faisons ressembler à d'autres barres de menu pour que les visiteurs sachent intuitivement qu'il s'agit d'une barre de menu et comment l'utiliser. Notre barre de menu utilise même une couleur d'arrière-plan différente pour chaque élément sur lequel la souris passe, ce qui donne à l'utilisateur un retour visuel utile.

Certains éléments de menu sont des éléments parents. Ils génèrent des sous-menus enfants. Chaque fois que l'utilisateur pointe sur l'un d'entre eux, une animation qui fait glisser le sous-menu enfant s'affiche.

À l'évidence, tout cela est plutôt inaccessible, comme c'est le cas habituellement pour de nombreuses choses sur le Web, en grande partie parce que les assistants des standards HTML n'ajoutaient pas tout ce dont un auteur Web a besoin. Et même si c'était le cas, les auteurs Web voudraient toujours inventer leur propre version spéciale de toute façon.

Rendre le clavier de la barre de menu accessible

Pour commencer, ajoutons l'accessibilité au clavier. Cette partie utilise uniquement HTML, et non ARIA. N'oubliez pas qu'ARIA n'affecte pas des aspects fondamentaux tels que l'apparence, la souris ou le clavier pour les utilisateurs sans technologies d'assistance.

Tout comme une page Web peut répondre à la souris, elle peut également répondre au clavier. Notre code JavaScript écoute toutes les frappes et détermine si elles sont utiles. Si ce n'est pas le cas, il la renvoie sur la page comme un poisson trop petit pour être mangé. Nos règles sont quelque chose comme:

• Si l'utilisateur appuie sur une touche fléchée, examinons nos propres plans internes de barre de menu et décidons du nouvel élément de menu actif. Nous allons effacer tous les points forts actuels et mettre en évidence le nouvel élément de menu afin que l'utilisateur voyant sache visuellement où il se trouve. La page Web doit ensuite appeler event.preventDefault() pour empêcher le navigateur d'effectuer l'action habituelle (faire défiler la page, dans ce cas).
• Si l'utilisateur appuie sur la touche Entrée, nous pouvons la traiter comme un clic et effectuer l'action appropriée (ou même ouvrir un autre menu).
• Si l'utilisateur appuie sur une touche qui doit faire autre chose, ne mangez pas ça ! Renvoyez-le sur la page comme prévu. Par exemple, la barre de menu n'a pas besoin de la touche Tabulation, alors annulez cette action ! C'est difficile à comprendre, et les auteurs font souvent l'erreur. Par exemple, la barre de menu doit contenir des touches fléchées, mais pas Alt+Flèche ni Commande+Flèche. Ce sont des raccourcis pour accéder à la page précédente/suivante dans l'historique Web de l'onglet de votre navigateur. Si l'auteur ne fait pas attention, la barre de menu les mangera. Ce genre de bug arrive souvent, et nous n'avons même pas encore utilisé les flux ARIA.

Accès à notre barre de menu par le lecteur d'écran

Notre barre de menu a été créée avec du ruban adhésif et des éléments div. Par conséquent, les lecteurs d'écran ne savent pas de quoi il s'agit. La couleur d'arrière-plan de l'élément actif n'est qu'une couleur. Les divisions d'élément de menu sont des objets simples sans signification particulière. Par conséquent, un utilisateur de notre barre de menu ne reçoit aucune instruction sur les touches sur lesquelles appuyer ni sur l'élément sur lequel il se trouve.

Mais ce n'est pas juste ! La barre de menu fonctionne très bien pour l'utilisateur voyant.

ARIA à la rescousse. ARIA nous permet de faire semblant d'utiliser le lecteur d'écran dans une barre de menu. Si l'auteur fait tout correctement, notre barre de menu personnalisée ressemblera à une barre de menu dans une application de bureau pour le lecteur d'écran.

La première, ARIA, consiste à utiliser l'attribut aria-activedescendant et à le définir sur l'ID de l'élément de menu actif, en veillant à le mettre à jour chaque fois qu'il change. Exemple : aria-activedescendant="settings-menuitem". Ce petit mensonge blanc amène le lecteur d'écran à considérer notre élément ARIA actif comme le focus, qui est lu à voix haute ou affiché sur une plage braille.

Explication de l'ancestor, du ancestor et du ancestor

Le terme descendant fait référence au fait qu'un élément est contenu quelque part à l'intérieur d'un autre. Le terme opposé est "ancêtre", qui signifie qu'un élément est contenu dans des ancêtres. Pour le conteneur suivant, vous pouvez utiliser les termes plus spécifiques "parent/enfant". Par exemple, imaginez un document contenant un paragraphe contenant un lien. Le parent du lien est un paragraphe, mais il a également le document en tant qu'ancêtre. À l'inverse, le document peut avoir de nombreux enfants de paragraphe, chacun avec des liens. Les liens sont tous les descendants du document grand-parent.

Retour à aria-activedescendant. En l'utilisant pour pointer de la barre de menu active vers un élément de menu spécifique, le lecteur d'écran sait désormais où l'utilisateur s'est déplacé, mais rien d'autre sur l'objet. Qu'est-ce que le tag div ? C'est là que l'attribut de rôle entre en jeu. Nous utilisons role="menubar" sur l'élément contenant l'ensemble, puis nous utilisons role="menu" sur des groupes d'éléments et role="menuitem" sur le roulement de tambour... les éléments de menu individuels.

Et que se passe-t-il si l’élément de menu peut mèner à un menu enfant ? L’utilisateur doit le savoir, n’est-ce pas ? Pour un utilisateur voyant, il peut y avoir une petite image d'un triangle à la fin du menu, mais le lecteur d'écran ne sait pas comment lire automatiquement les images, du moins à ce stade. Nous pouvons ajouter aria-expanded="false" à chaque élément de menu extensible pour indiquer que 1) un élément peut être développé et 2) qu'il n'est pas développé actuellement. Pour ajouter une touche, l'auteur devrait ajouter role="none" sur le triangle "img" pour indiquer qu'il s'agit uniquement d'une création à des fins de mise en forme. Cela empêche le lecteur d'écran d'indiquer quoi que ce soit à propos de l'image, au mieux redondant et potentiellement agaçant.

Gérer les bugs

Bugs de clavier (HTML!)

Bien que l'accès au clavier fasse partie du langage HTML de base, les auteurs font souvent des erreurs, soit parce qu'ils n'utilisent pas beaucoup la navigation au clavier, soit parce qu'il y a beaucoup de nuances à faire.

Exemples de bugs:

• Une case à cocher utilise la barre d'espace pour activer/désactiver, mais l'auteur a oublié d'appeler preventDefault(). La barre d'espace activera à la fois la case à cocher et la page vers le bas, ce qui est le comportement par défaut du navigateur pour la barre d'espace.
• Une boîte de dialogue modale ARIA souhaite piéger la navigation par onglet à l'intérieur, et l'auteur oublie d'autoriser spécifiquement les commandes Ctrl+Tabulation jusqu'au navigateur. Désormais, les touches Ctrl+Tabulation naviguent simplement dans la boîte de dialogue et ne changent pas d'onglet dans le navigateur comme prévu. Y'en a marre !
• Un auteur crée une liste de sélection et implémente la navigation haut/bas, mais n'implémente pas "accueil/fin/pageup/page suivante" ni la navigation par première lettre.

Les auteurs doivent suivre des modèles connus. Pour en savoir plus, consultez la section Ressources.

Pour les problèmes d'accès au clavier, il est également utile d'essayer sans lecteur d'écran ou en désactivant le mode de navigateur virtuel. Les lecteurs d'écran ne sont généralement pas nécessaires pour détecter les bugs du clavier, et l'accès au clavier est en fait implémenté avec le langage HTML, et non ARIA. Après tout, ARIA n'affecte pas des éléments de base tels que le comportement du clavier ou de la souris. Seul le lecteur d'écran peut accéder au contenu de la page Web, au contenu sélectionné, etc.

Les bugs du clavier sont presque toujours des bugs dans le contenu Web, en particulier dans leur code HTML et JavaScript, et non dans les flux ARIA.

Bugs ARIA: pourquoi y en a-t-il autant ?

Il existe de nombreux cas où les auteurs peuvent fausser les flux ARIA, et chacun entraîne une rupture complète ou des différences subtiles. Les plus subtils sont probablement pires, car l'auteur ne les détectera pas tous avant de les publier.

Après tout, sauf si l'auteur est un utilisateur expérimenté de lecteur d'écran, il y a un problème dans les flux ARIA. Dans notre exemple de barre de menu, l'auteur pourrait penser que le rôle « option » devait être utilisé lorsque « menuitem » était correct. Il peut oublier d'utiliser aria-expanded, de définir et d'effacer aria-activedescendant au bon moment ou d'oublier d'avoir une barre de menu contenant les autres menus. Et qu'en est-il du nombre d'éléments du menu ? Habituellement, les éléments de menu sont présentés par des lecteurs d'écran avec quelque chose comme "élément 3 sur 5" afin que l'utilisateur sache où ils se trouvent. Ces chiffres sont généralement comptabilisés automatiquement par le navigateur, mais dans certains cas, et dans certains cas, ainsi que dans des combinaisons de lecteurs d'écran, des nombres incorrects peuvent être calculés, et l'auteur doit remplacer ces chiffres par aria-posinset et aria-setsize.

Et ce ne sont que les barres de menu. Pensez au nombre de types de widgets qu’il existe. Consultez les spécifications ARIA ou les pratiques de création si vous le souhaitez. Pour chaque format, ARIA peut être utilisé de manière abusive dans des dizaines de cas. ARIA s'appuie sur les auteurs pour savoir ce qu'ils font. Quels problèmes pourriez-vous rencontrer, étant donné que la plupart des auteurs n'utilisent pas de lecteur d'écran ?

En d'autres termes, les véritables utilisateurs de lecteurs d'écran doivent tester les widgets ARIA avant qu'ils ne soient expédiés. Il y a trop de nuances. Idéalement, vous devriez tout faire avec plusieurs combinaisons de navigateur et de lecteur d'écran, en raison des nombreuses particularités de l'implémentation, en plus de quelques implémentations incomplètes.

Résumé

Pour résumer, la magie ARIA peut être utilisée pour remplacer ou compléter tout ou partie de tout contenu HTML. Elle peut être utilisée pour apporter de petites modifications à la présentation d'accessibilité ou pour créer une expérience complète. C'est pourquoi les flux ARIA sont à la fois extrêmement puissants et dangereux entre les mains de nos rédacteurs Web locaux qui n'utilisent généralement pas de lecteurs d'écran eux-mêmes.

ARIA n'est qu'une couche de balisage de vérité simple. Lorsqu'un lecteur d'écran demande ce qui se passe, s'il existe des flux ARIA, il obtient la version ARIA de la vérité plutôt que de la vérité sous-jacente réelle.

Avenant 1: Ressources supplémentaires

Documentation de référence hybride avec informations sur le clavier et exemples de code

• W3C's ARIA Authoring Practices (Pratiques de création ARIA de W3C) : ce document documente les caractéristiques importantes de navigation au clavier de chaque exemple et fournit un code JS/CSS/ARIA fonctionnel. Les exemples se concentrent sur ce qui fonctionne aujourd'hui et ne couvrent pas les mobiles.

Avenant 2: À quoi les flux ARIA sont-ils les plus utilisés ?

Les flux ARIA peuvent remplacer ou compléter des vérités petites ou grandes, ce qui est généralement utile pour indiquer des éléments importants pour le lecteur d'écran.

Voici quelques exemples d'utilisations courantes des flux ARIA.

• des widgets spéciaux qui n'existent pas en HTML, comme une barre de menus, la saisie semi-automatique, une arborescence ou une feuille de calcul ;
• Des widgets qui existent en HTML, mais dont l'auteur a tout de même inventé le sien, peut-être parce qu'ils avaient besoin de modifier le comportement ou l'apparence du widget normal. Par exemple, un élément HTML <input type="range"> est essentiellement un curseur, mais les auteurs veulent lui donner un aspect différent. Dans la plupart des cas, vous pouvez utiliser CSS. Toutefois, pour input type="range", il est gênant. Un auteur peut créer son propre curseur et utiliser role="slider" sur celui-ci avec aria-valuenow pour indiquer la valeur actuelle.
• Les zones en ligne indiquent aux lecteurs d'écran "dans cette zone de la page, tout ce qui change et mérite d'être signalé à l'utilisateur".
• Points de repère (le code HTML a désormais des équivalents). Ils s'apparentent à des en-têtes, dans la mesure où ils aident les utilisateurs de lecteurs d'écran à trouver plus rapidement ce qu'ils veulent. Cependant, ils sont différents en ce sens qu’ils contiennent l’ensemble de la zone connexe. Par exemple, "ce conteneur est la zone principale de la page" et "ce conteneur est un panneau de navigation".

Avenant 3: Qu'est-ce qu'une API d'accessibilité ?

Une API d'accessibilité permet à un lecteur d'écran ou à une autre TA de savoir ce qu'il y a sur la page et ce qui se passe en ce moment. Exemples : MSAA, IA2 et UIA. Et ce n'est que Windows ! Une API d'accessibilité se compose de deux parties:

• Une "arborescence" d'objets qui représente une hiérarchie de conteneurs. Ceux-ci sont comme les poupées russes, mais chaque poupée peut contenir plusieurs autres poupées. Par exemple, un document peut contenir plusieurs paragraphes et un paragraphe peut contenir du texte, des images, des liens, du gras, etc. Chaque élément de l'arborescence des objets peut avoir des propriétés telles qu'un rôle (qui suis-je ?), un nom/libellé, une valeur saisie par l'utilisateur, une description, ainsi que des états booléens tels que sélectionnable, ciblé, obligatoire et coché. ARIA peut remplacer n'importe laquelle de ces propriétés. Le lecteur d'écran utilise l'arborescence pour aider l'utilisateur à naviguer en mode de tampon virtuel, par exemple "passer à l'en-tête suivant s'il vous plaît".
• Série d'événements qui se produisent et décrivant les modifications apportées à l'arborescence, comme "Le focus est maintenant terminé !". Le lecteur d'écran utilise les événements pour indiquer à l'utilisateur ce qui vient de se passer. Lorsque des modifications importantes du balisage HTML ou ARIA sont apportées, un événement est déclenché pour indiquer au lecteur d'écran que quelque chose a changé.

Généralement, les auteurs utilisent simplement le langage HTML, qui correspond bien à ces API d'accessibilité. Lorsque le code HTML ne suffit pas, ARIA est utilisé et le navigateur ignore la sémantique HTML avant d'envoyer l'arborescence d'objets ou les événements au lecteur d'écran.