ARIA: poison ou antidote ?

Aaron Leventhal

Qu'est-ce que ARIA ?

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

Il est parfois nécessaire d'ajouter des informations à la vérité ou même de "mentir" aux lecteurs d'écran sur ce qui se passe dans le contenu Web. Par exemple, "L'accent est vraiment ici !" ou "C'est vraiment un curseur !". C'est comme ajouter des notes adhésives magiques sur les outils et les widgets de votre établi. Ces notes autocollantes magiques font croire à tout le monde ce qui est écrit dessus.

Lorsqu'une note adhésive magique existe, elle remplace notre croyance sur ce que chaque outil est ou fait. Par exemple, si vous ajoutez ARIA qui indique "cet objet est un pistolet à colle". Même s'il s'agit d'une boîte bleue vide, la note adhésive magique nous indique qu'il s'agit d'un pistolet à colle. Vous pouvez également ajouter "et il est rempli à 30 %". Le lecteur d'écran indique désormais qu'un pistolet à colle est rempli à 30 %.

L'équivalent Web consiste à prendre un div simple avec une image à l'intérieur et à utiliser ARIA pour indiquer qu'il s'agit d'un curseur dont la valeur est de 30 sur 100. ARIA ne fait pas du div un curseur. Il indique simplement au lecteur d'écran qu'il s'agit d'un curseur.

ARIA n'a aucune incidence sur l'apparence d'une page Web ni sur le comportement d'un utilisateur de souris ou de clavier. Seuls les utilisateurs de technologies d'assistance remarquent l'impact d'ARIA. Les développeurs Web peuvent ajouter des éléments ARIA arbitraires sans affecter les utilisateurs qui n'exécutent pas de technologie d'assistance.

Vous avez bien lu: ARIA n'a aucun impact sur la sélection au clavier ni sur l'ordre des tabulations. Tout cela est fait en HTML, parfois modifié avec des éléments JavaScript.

Comment fonctionne ARIA ?

Un lecteur d'écran ou une autre technologie d'assistance demande aux navigateurs des informations sur chaque élément. Lorsque ARIA est présent sur un élément, le navigateur intègre les informations et modifie ce qu'il dit au lecteur d'écran à propos de cet élément.

Voici quelques cas d'utilisation courants d'ARIA.

• Ajoutez des composants spéciaux qui n'existent pas en HTML, comme la saisie semi-automatique, un arbre ou une feuille de calcul.
• Ajoutez des composants qui existent en HTML, mais que l'auteur a décidé de réinventer, peut-être parce qu'il voulait modifier le comportement ou l'apparence de l'élément standard. Par exemple, un élément HTML <input type="range"> est essentiellement un curseur, mais les auteurs souhaitent lui donner un aspect différent.
  • Dans la plupart des cas, vous pouvez résoudre ce problème avec CSS. Toutefois, pour range, le CSS est maladroit. Les auteurs peuvent créer leur propre curseur et utiliser role="slider" avec aria-valuenow pour indiquer au clavier la valeur actuelle.
• Incluez des régions en direct pour indiquer aux lecteurs d'écran les modifications pertinentes apportées à une zone d'une page.
• Créez des repères, tels que des titres. Les repères aident les utilisateurs de lecteurs d'écran à trouver plus rapidement ce qu'ils recherchent. Les repères peuvent contenir une zone entière associée. Par exemple, "ce conteneur est la zone principale de la page" et "ce conteneur ici est un panneau de navigation".

Pourquoi utiliser ARIA ?

Il peut être utile d'ajouter des éléments ARIA au code HTML qui fonctionne déjà. Par exemple, nous pouvons souhaiter qu'une commande de formulaire pointe vers une alerte de message d'erreur pour une entrée non valide. Nous pouvons également indiquer l'utilisation spécifique d'une saisie de texte. Ces ajustements peuvent rendre les sites Web ordinaires plus utilisables avec un lecteur d'écran.

Exemple de barre de menu

Imaginons que la boutique en ligne locale ne vende pas tous les widgets dont nous avons besoin. Mais nous sommes MacGyver. Nous pouvons simplement inventer nos propres widgets à partir d'autres widgets. Cela ressemble beaucoup à un auteur Web qui doit créer une barre de menu.

Bien que l'élément <nav> existe, les barres de menu sont souvent assemblées à l'aide de divs, d'images, de boutons, de gestionnaires de clics, de gestionnaires de frappe et d'ARIA.

Prendre en charge les utilisateurs de la souris

Créons ensemble une barre de menu. Nous affichons un certain nombre d'éléments dans des éléments de boîte génériques appelés divs. Chaque fois que notre utilisateur clique sur un div, il exécute la commande correspondante. Super, ça fonctionne pour les utilisateurs de la souris.

Ensuite, nous allons rendre l'interface plus attrayante. Nous utilisons le CSS pour aligner correctement les éléments et leur ajouter des contours visuels. Nous la faisons suffisamment ressembler aux autres barres de menu pour que les utilisateurs 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 tous les éléments sur lesquels la souris se trouve, ce qui fournit à l'utilisateur des commentaires visuels utiles.

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

Tout cela est assez inaccessible, comme c'est souvent le cas pour de nombreuses choses sur le Web.

Rendre la barre de menus accessible au clavier

Ajoutons l'accessibilité du clavier. Pour ce faire, vous devez uniquement modifier le code HTML, et non ARIA. N'oubliez pas qu'ARIA n'a aucune incidence sur les aspects fondamentaux tels que l'apparence, la souris ou le clavier pour les utilisateurs qui ne disposent pas de technologies d'assistance.

Tout comme une page Web peut répondre à la souris, elle peut également répondre au clavier. Notre code JavaScript peut écouter tous les frappes de touches et décider si elles sont utiles. Sinon, il le renvoie à la page comme un poisson trop petit pour être mangé. Voici quelques-unes de nos règles:

• Si l'utilisateur appuie sur une touche fléchée, examinons nos propres modèles de barre de menu interne et décidons de l'élément de menu actif. Nous allons effacer tous les surlignages actuels et mettre en surbrillance le nouvel élément de menu afin que l'utilisateur voyant sache où il se trouve. La page Web doit ensuite appeler event.preventDefault() pour empêcher le navigateur d'effectuer l'action habituelle (défilement de 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 effectuer une autre action, renvoyez-le sur la page. Par exemple, notre barre de menu n'a pas besoin de la touche Tabulation. Ce n'est pas facile à faire. Par exemple, la barre de menu nécessite les touches fléchées, mais pas Alt+Flèche ou Commande+Flèche. Il s'agit de raccourcis pour accéder à la page précédente et suivante de l'historique Web de votre onglet de navigateur. Si l'auteur n'est pas prudent, la barre de menu les engloutira. Ce type de bug se produit très souvent, et nous n'avons même pas encore commencé avec ARIA !

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

Notre barre de menu a été créée avec du ruban adhésif et des divs. Par conséquent, un lecteur d'écran n'a aucune idée de ce que cela signifie. La couleur d'arrière-plan de l'élément actif n'est qu'une couleur. Les divs des éléments de menu ne sont que 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 à 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 les utilisateurs voyants.

ARIA à la rescousse. ARIA nous permet de faire croire au lecteur d'écran que le focus est dans une barre de menu. Si l'auteur fait tout correctement, notre barre de menu personnalisée apparaîtra pour le lecteur d'écran comme une barre de menu dans une application pour ordinateur.

Notre premier mensonge ARIA est l'attribut aria-activedescendant. Définissez l'attribut 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". Le lecteur d'écran considère alors notre élément actif ARIA comme le focus, qui est lu à voix haute ou affiché sur un écran braille.

Explication des termes ancêtre, parent et descendant

Le terme descendant fait référence au fait qu'un élément est contenu dans un autre. Le terme opposé est "ancêtre", ce qui signifie qu'un élément est contenu par des ancêtres. Pour le conteneur suivant vers le haut/le bas, les termes plus spécifiques "parent/enfant" peuvent être utilisés. Par exemple, imaginons un document contenant un paragraphe avec un lien. Le parent du lien est un paragraphe, mais le document est également son ancêtre. Inversement, le document peut comporter de nombreux paragraphes enfants, chacun avec des liens. Les liens sont tous des descendants du document grand-père.

En utilisant aria-activedescendant pour pointer de la barre de menu sélectionnée vers un élément de menu spécifique, le lecteur d'écran sait maintenant où l'utilisateur s'est déplacé, mais rien d'autre sur l'objet. Qu'est-ce que c'est que ce div ? C'est là qu'intervient l'attribut "role". Nous utilisons role="menubar" sur l'élément contenant pour l'ensemble, puis role="menu" sur les groupes d'éléments et role="menuitem" sur…roulement de tambour… les éléments de menu individuels.

Et si l'élément de menu pouvait conduire à un sous-menu ? L'utilisateur doit le savoir. 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 lire automatiquement les images, du moins pour le moment. Nous pouvons ajouter aria-expanded="false" à chaque élément de menu extensible pour indiquer qu'il y a quelque chose qui peut être développé et qu'il n'est pas développé. En outre, l'auteur doit placer role="none" sur le triangle img pour indiquer qu'il s'agit d'un produit à usage esthétique uniquement. Cela empêche le lecteur d'écran de dire quoi que ce soit sur l'image qui serait redondant.

Correction de bugs liés au clavier

Bien que l'accès au clavier fasse partie du code HTML de base, il est facile de le remplacer. Exemple :

• Une case à cocher utilise la barre d'espace pour l'activation/deactivation, mais l'auteur a oublié d'appeler preventDefault(). La barre d'espace permet désormais d'activer/de désactiver la case à cocher et de faire défiler la page vers le bas, ce qui correspond au 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. Si l'auteur oublie d'autoriser spécifiquement Ctrl+Tab pour ouvrir un nouvel onglet dans la boîte de dialogue, cela ne fonctionnera pas comme prévu.
• Un auteur crée une liste de sélection et implémente des touches de défilement vers le haut et vers le bas. Toutefois, l'auteur doit toujours ajouter les touches Accueil, Fin, Page Haut, Page Bas ou 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 avec le mode navigateur virtuel désactivé. Vous pouvez détecter des bugs de clavier sans lecteur d'écran, car l'accès au clavier est implémenté avec HTML, et non avec ARIA. Après tout, ARIA n'affecte pas le comportement du clavier ni de la souris. Au lieu de cela, il ment au lecteur d'écran sur le contenu de la page Web, sur l'élément actuellement sélectionné, etc.

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

Pourquoi y en a-t-il autant ?

Un auteur peut mal utiliser ARIA de nombreuses façons. Chaque erreur entraîne une rupture complète ou des différences subtiles. Les problèmes subtils peuvent être pires, car l'auteur est peu susceptible de les détecter avant la publication.

Après tout, à moins que l'auteur ne soit un utilisateur expérimenté de lecteur d'écran, quelque chose va mal se passer dans ARIA. Dans notre exemple de barre de menu, l'auteur pouvait penser que le rôle "option" devait être utilisé alors que "menuitem" était correct. Il peut oublier d'utiliser aria-expanded, d'oublier 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 de menu ? En règle générale, les lecteurs d'écran présentent les éléments de menu avec une information telle que "Élément 3 sur 5" pour que l'utilisateur sache où il se trouve. Ce nombre est généralement compté automatiquement par le navigateur, mais dans certains cas, et dans certaines combinaisons de navigateurs et de lecteurs d'écran, des nombres incorrects peuvent être calculés, et l'auteur doit remplacer ces nombres par aria-posinset et aria-setsize.

Et ce ne sont que des barres de menu. Pensez au nombre de types de widgets. Consultez la spécification ARIA ou les bonnes pratiques d'écriture si vous le souhaitez. Pour chaque modèle, il existe une douzaine de façons dont ARIA peut être utilisé de manière abusive. ARIA repose sur les auteurs pour savoir ce qu'ils font. Que se passe-t-il si la plupart des auteurs ne sont pas des utilisateurs de lecteurs d'écran ?

En d'autres termes, il est absolument nécessaire que les utilisateurs de lecteurs d'écran réels testent les widgets ARIA avant qu'ils ne soient considérés comme livrables. Il y a trop de nuances. Idéalement, tout devrait être testé avec plusieurs combinaisons de navigateurs et de lecteurs d'écran, en raison des nombreuses particularités d'implémentation, en plus de quelques implémentations incomplètes.

Résumé

ARIA peut être utilisé pour remplacer ou ajouter tout ce que le code HTML indique. Il peut apporter de légères modifications à la présentation de l'accessibilité ou créer une expérience complète. C'est pourquoi ARIA est à la fois incroyablement puissant et dangereux entre les mains de nos développeurs qui ne sont pas des utilisateurs de lecteurs d'écran.

ARIA est une couche de balisage qui remplace les autres choix. Lorsqu'un lecteur d'écran demande ce qui se passe, si ARIA existe, l'utilisateur obtient la version ARIA de la vérité.

Ressources supplémentaires

Les pratiques d'écriture ARIA du W3C documentent les caractéristiques importantes de la navigation au clavier de chaque exemple et fournissent du code JavaScript, CSS et ARIA fonctionnel. Les exemples se concentrent sur ce qui fonctionne aujourd'hui et ne couvrent pas les appareils mobiles.

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

Une API d'accessibilité permet à un lecteur d'écran ou à une autre technologie d'assistance de savoir ce qu'il se passe sur la page. MSAA, IA2 et UIA en sont des exemples. Une API d'accessibilité se compose de deux éléments:

• "Arbre" d'objets représentant une hiérarchie de conteneurs. Par exemple, un document peut contenir un certain nombre de paragraphes. Un paragraphe peut contenir du texte, des images, des liens et des décorations de texte. Chaque élément de l'arborescence des objets peut avoir des propriétés, telles que le rôle (que suis-je ?), un nom ou un libellé, une valeur saisie par l'utilisateur, une description et des états booléens, tels que la possibilité de sélection, la sélection, l'obligation et la vérification. ARIA peut remplacer n'importe laquelle de ces propriétés.
  • Les lecteurs d'écran utilisent l'arborescence pour aider les utilisateurs à naviguer en mode tampon virtuel, par exemple "Passez à l'en-tête suivant, s'il vous plaît".
• Série d'événements qui se produisent et décrivent les modifications apportées à l'arborescence, par exemple "le focus est maintenant ici !". Le lecteur d'écran utilise des événements pour indiquer à l'utilisateur ce qui vient de se passer. Lorsqu'une balise HTML ou ARIA importante change, un événement est déclenché pour indiquer au lecteur d'écran que quelque chose a changé.

Le code HTML se marie bien avec ces API d'accessibilité. Lorsque le code HTML ne suffit pas, vous pouvez ajouter ARIA pour que le navigateur remplace la sémantique HTML avant d'envoyer l'arborescence d'objets ou les événements au lecteur d'écran.