ARIA: poison ou antidote ?

Qu'est-ce que le protocole 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'étendre 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 un peu comme ajouter des notes autocollantes aux outils et widgets de votre établi. Ces notes autocollantes magiques font croire à tout le monde ce qui est écrit dessus.

Lorsqu'une note autocollante magique existe, elle remplace nos croyances concernant chaque outil. 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 nous dit qu'il s'agit d'une pistolet à colle. Nous pouvons également ajouter « et il est plein à 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 n'importe quel ARIA arbitraire 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 se fait en HTML, parfois avec des bits 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 ARIA est présent sur un élément, le navigateur exploite les informations et modifie ce qu'il indique 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, ce problème peut être résolu avec le 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 points de repère aident les utilisateurs de lecteurs d'écran à trouver ce qu'ils veulent, plus rapidement. Les repères peuvent englober 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 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 regroupées à l'aide de div, d'images, de boutons, de gestionnaires de clics, de poignées d'appui sur une touche et d'ARIA.

Prendre en charge les utilisateurs de souris

Créons ensemble une barre de menu. Nous affichons plusieurs éléments dans des éléments "box" génériques, appelés "div". Chaque fois que l'utilisateur clique sur un élément div, la commande correspondante est exécutée. 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 visuels 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'une de ces options, 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. Vous ne devez modifier que le code HTML, pas le fichier 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é. Nos règles sont quelque chose comme:

• 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-la à la page. Par exemple, la barre de menu n'a pas besoin de la touche Tabulation. Vous pouvez donc la renvoyer. C'est difficile à faire. Par exemple, la barre de menu a besoin des touches fléchées, mais pas du raccourci Alt+Flèche ni 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, le lecteur d'écran n'a aucune idée de ce que l'un de ces éléments est. 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, les utilisateurs de notre barre de menu ne reçoivent pas d'instructions sur les touches sur lesquelles appuyer ni sur l'élément sur lequel elles se trouvent.

Mais ce n'est pas juste ! La barre de menu fonctionne très bien pour les personnes voyantes.

ARIA à la rescousse. ARIA nous permet de faire semblant au lecteur d'écran que le curseur se trouve dans une barre de menu. Si l'auteur se charge de tout, notre barre de menu personnalisée s'affiche sur le lecteur d'écran comme une barre de menu dans une application de bureau.

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.

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. C'est quoi ce truc div ? C'est là qu'intervient l'attribut "role". Nous utilisons role="menubar" sur l'élément contenant pour l'ensemble de l'élément, puis nous utilisons role="menu" sur des groupes d'éléments et role="menuitem" sur... les rouleaux de tambour... les éléments de menu individuels.

Et si l'élément de menu pouvait mener à 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 à ce stade. 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 activer/désactiver, 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é des lecteurs d'écran, un problème est survenu dans l'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. Ils peuvent 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 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 pratiques de création 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. Elle peut apporter de petites modifications à la présentation d'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 une version 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 Accessibility ?

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:

• "Arborescence" 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.