Règles d'utilisation de ARIA dans le HTML
Privilégier les éléments HTML natifs
ARIA propose beaucoup de rôles dont l'objectif sémantique est équivalent à celui des éléments HTML natifs, par exemple role="list", role="img" etc.
Par exemple :
<span role="heading" aria-level="1">Titre de niveau 1</span>
Cette utilisation des rôles heading et aria-level transforme un simple span en un titre de niveau 1 « virtuel » qui requiert l'utilisation d'une technologie d'assistance compatible pour être correctement restitué.
Or, la première règle d'ARIA stipule qu'il faut privilégier l'utilisation d'élément HTML natif, sauf exception :
If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Si vous pouvez utiliser des éléments HTML natifs ou des attributs dont la sémantique et le comportement recherchés sont déjà disponibles, plutôt que de redévelopper un élément et d'ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, faites-le.
Trois situations qui justifient le recours à ARIA peuvent être envisagées pour créer de toute pièce un élément HTML :
- si l'élément HTML n'est pas implémenté ou que son accessibilité est défaillante ;
- s'il existe des contraintes de présentation telles qu'elles sont irréalisables avec l'élément natif HTML ;
- si l'élément HTML n'existe simplement pas.
Une autre utilisation possible et qui peut justifier le recours à ARIA est de corriger un contenu HTML défaillant lorsqu'il n'est pas possible d'intervenir sur le HTML natif, même si cette utilisation ne devrait être faite qu'à titre provisoire. Par exemple, lors de l'utilisation d'un plugin qui génère du HTML et qu'on ne peut pas modifier.
Préserver la sémantique native des éléments
Beaucoup de fonctionnalités d'exploration et de manipulation de contenu offertes par les technologies d'assistance sont fondées sur la sémantique native des éléments HTML. La modifier, via ARIA, sans précautions, c'est prendre le risque de rendre ces fonctionnalités essentielles inopérables.
Ainsi, la seconde règle d'ARIA préconise :
Do not change native semantics, unless you really have to.
Ne changez pas la sémantique native d'un élément sauf en dernier recours.
Par exemple :
<h1 role="button">titre bouton</h1>
Ce titre transformé en bouton sera inatteignable avec le raccourci de navigation de titre en titre fourni par une technologie d'assistance. On devrait plutôt écrire :
<h1><button>titre bouton</button></h1>
En revanche, il est possible dans certains cas d'utiliser des éléments HTML natifs comme méthode de « fallback ». Par exemple, utiliser une liste HTML ul li pour implémenter un rôle tree dont le but est de créer une arborescence interactive.
Rendre opérables au clavier les éléments interactifs contrôlés par ARIA
Comme expliqué dans les chapitres précédents, ARIA se contente de décrire les éléments et les navigateurs n'implémentent pas tous les comportements ad hoc au clavier.
C'est pourquoi la troisième règle d'ARIA préconise :
All interactive ARIA controls must be usable with the keyboard.
Tous les contrôles interactifs ARIA doivent être utilisables au clavier.
Cette règle est implémentée comme une exigence formelle dans le RGAA via l'obligation, d'une part, de respecter les motifs de conception ARIA et, d'autre part, de rendre les composants interactifs utilisables au clavier lorsqu'il n'existe pas de tel motif de conception.
Ne pas inhiber la sémantique ou la restitution des éléments focusables visibles
ARIA propose un rôle presentation qui supprime la sémantique restituée.
Par exemple :
<table role="presentation">
<tr>
<td></td>
<td></td>
</tr>
</table>
À cause du role="presentation", ce tableau n'existera plus dans l'« accessible tree ». Cela peut-être utile pour supprimer la sémantique d'éléments utilisés comme fallback dans des composants complexes. En revanche, son utilisation sur des éléments focusables visibles va poser un problème car certains utilisateurs risquent de prendre le focus sur « rien », c'est à dire un élément inconnu en restitution.
De même, ARIA propose une propriété aria-hidden qui signale que l'élément ne doit pas être restitué. Cette propriété est généralement utilisée en conjonction avec des directives CSS d'affichage pour gérer les zones masquées d'un composant complexe.
Cette propriété peut également servir à empêcher la restitution d'un élément visible redondant ou inutile, par exemple dans certains cas de simulation de présentation de formulaire sous la forme de tableaux possédant des en-têtes visibles mais inutiles puisque chaque champ possède déjà un label valide.
En revanche, comme pour l'utilisation du rôle presentation, l'utilisation de la propriété aria-hidden sur un élément focusable visible peut poser des problèmes.
Ainsi, la quatrième règle préconise :
Do not use role="presentation" or aria-hidden="true" on a visible focusable element.
Ne pas utiliser role="presentation" ou aria-hidden="true" sur un élément focusable visible.
Cette règle devrait être toujours respectée.
Donner un nom accessible (accessible name) à tous les composants contrôlés par ARIA
Cette cinquième règle de bon sens est incontournable. Elle préconise :
All interactive elements must have an accessible name.
Tout élément interactif doit avoir un nom accessible.
Comme expliqué dans les chapitres précédents, fournir un accessible name, par exemple via les propriétés aria-labelledby ou aria-label, est la seule manière de garantir que l'élément en cours d'utilisation sera correctement identifié par les utilisateurs.
Cette règle est encadrée de manière rigoureuse par le RGAA via l'obligation de respecter les motifs de conception, l'obligation de tester les restitutions, et certains critères pour des cas plus spécifiques.
Utilisation de rôles ou de propriétés spécifiques de l'API ARIA
application vs. document
ARIA propose deux rôles qui vont impacter de manière fondamentale l'utilisation des contenus par les aveugles utilisateurs de lecteurs d'écran : les rôles application et document.
Pour comprendre l'utilisation de ces deux rôles, il faut décrire brièvement la manière dont les lecteurs d'écran s'interfacent entre l'utilisateur et le navigateur.
Les lecteurs d'écrans sous Windows, JAWS, NVDA, Window-Eyes, proposent deux modes d'interaction différents aux utilisateurs : le « mode navigation » et le « mode formulaire ».
Le mode navigation permet à l'utilisateur de naviguer dans le contenu, stocké sous la forme d'une copie en mémoire de la page, via des raccourcis clavier ou des fonctionnalités de navigation spécifiques.
Naturellement, dans ce contexte, le lecteur d'écran a besoin de récupérer l'ensemble des actions au clavier afin de les traiter par ses propres moyens. Dans ce mode d'interaction, le navigateur est totalement passif.
Mais dès que l'élément en cours de consultation doit être géré par le navigateur car il correspond à un type connu, le lecteur d'écran va donner le contrôle des touches du clavier au navigateur.
Mode navigation
Par exemple, la lecture ligne à ligne d'un contenu textuel ne requiert aucune action du navigateur et va donc être traitée par le lecteur d'écran de manière autonome. Il en va de même du parcours de titre en titre et de liste en liste, ou du parcours des éléments d'une liste ou des cellules d'un tableau par exemple.
Ce mode est appelé le « mode navigation ».
Mode formulaire
En revanche, si l'utilisateur rencontre dans sa navigation un élément interactif comme un lien ou un champ de formulaire, le lecteur d'écran va cesser de traiter le clavier : il va passer le relais au navigateur qui va alors actionner les contenus directement.
Par exemple, le navigateur va afficher le texte dans une boîte de saisie, afficher la page référencée dans un lien, parcourir la liste des options d'un élément select, positionner le focus sur le prochain élément focusable avec la touche tabulation, etc.
Dans ce contexte, le lecteur d'écran se contente de restituer les informations renvoyées par le navigateur et mises à jour via les APIs d'accessibilité et l'« accessible tree ».
Ce mode est appelé, par généralisation, le « mode formulaire ».
Ces changements de mode sont automatiques et transparents pour l'utilisateur qui en est informé par un signal sonore par exemple.
Avec ARIA, l'utilisation du rôle application va signaler au lecteur d'écran de passer en « mode formulaire », et inversement, le rôle document va signaler au lecteur d'écran de passer en « mode navigation ».
Cela a une conséquence majeure pour le développement : en effet, déclencher le « mode formulaire » signifie que c'est au développeur de prendre en charge l'intégralité de la gestion au clavier et de vérifier que les informations de mises à jour sont correctement transmises au lecteur d'écran.
Cela sera systématiquement le cas pour tous les composants d'interface qui bénéficient d'un motif de conception nécessitant des interactions au clavier, comme les rôles button, tabpanel, dialog, menu par exemple. D'où l'importance de respecter strictement les interactions au clavier définies par les motifs de conception.
Utilisation du rôle application
Vous ne devriez jamais utiliser le rôle application dans le cas général, c'est à dire l'utilisation de composants riches dans une application destinée à afficher des contenus.
La seule utilisation imaginable du rôle application serait le développement d'une véritable application web qui fonctionnerait exactement comme une application logicielle habituelle – ce qui est encore assez rare.
Utilisation du rôle document
Habituellement, une page web ayant un statut de document par défaut, vous n'aurez pas à utiliser le rôle document. Cela étant dit, ce rôle peut rendre quelques services.
Imaginons par exemple un système d'onglets qui affiche du contenu dans ses panneaux.
Du fait du rôle application par défaut, l'utilisateur ne pourra pas bénéficier de ses fonctionnalités de navigation dans les contenus des panneaux.
Si le panneau n'est constitué que d'éléments interactifs, par exemple des champs de formulaire ou des liens, même accompagnés d'un court texte de présentation, le rôle application restera efficace et simulera parfaitement une situation normale d'utilisation, comme la saisie d'un formulaire par exemple.
En revanche, si les panneaux contiennent des textes particulièrement riches, des titres, des paragraphes, des listes, etc., l'utilisation des fonctionnalités de navigation peut être utile.
Dans ce cas, l'implémentation d'un rôle document signalera au lecteur d'écran qu'il peut reprendre la main tant que le panneau est actif.
Par exemple :
<div id="pan0" aria-hidden="false" aria-expanded="true" aria-labelledby="tab0" role="tabpanel">
<div role="document">
[…]
</div>
<div>
Le raisonnement est identique avec une fenêtre modale dont on souhaite donner le contrôle du contenu à l'utilisateur, pour que ce dernier puisse utiliser les touches de navigation dans le contenu par exemple.
Les « live region »
ARIA possède une propriété particulière aria-live qui va permettre de faire remonter automatiquement les changements de contenus opérés via AJAX par exemple.
C'est la seule propriété dont le comportement est pris en charge par le navigateur.
Le fonctionnement est le suivant : dès que le navigateur détecte un changement de node (texte, élément ou attribut) dans le contenu spécifié, il remonte la modification au lecteur d'écran qui va vocaliser les contenus selon le paramétrage de la « live region ».
Les paramètres
aria-live="polite" : le contenu est vocalisé dès que l'utilisateur est disponible, c'est à dire dès qu'il ne réalise plus aucune action. aria-live="assertive" : le contenu est vocalisé immédiatement.aria-atomic="true" : toute la zone est vocalisée. aria-atomic="false" : seules les modifications sont vocalisées.aria-relevant sert à préciser les modifications qui seront vocalisées : addition pour les ajouts de contenus, removal pour les suppressions, all pour vocaliser tous les types de contenus, text pour ne vocaliser que les contenus de type texte.
À noter qu'ARIA propose également des rôles dont le comportement est similaire, comme les rôles alert, log ou progressbar par exemple.
Bien utilisée, cette propriété est une solution robuste et efficace pour gérer les zones de mise à jour dynamique, par exemple un panier d'achats affiché dans la page.
Mais attention : puisque la zone contrôlée par aria-live va être vocalisée, il convient de l'utiliser avec précaution dès que cette zone va contenir beaucoup de contenus.
Par exemple, imaginons un moteur de recherche qui afficherait ses résultats dans la même page via AJAX. L'utilisation de aria-live sur la zone mise à jour risque d'être particulièrement lourde et contre-indiquée. Préférez une prise de focus sur la zone mise à jour en résultat de la fonctionnalité de recherche afin de simuler un rechargement de page classique par exemple.
De même, l'utilisation simultanée de plusieurs « live region » dans une même page ou une même application pourrait donner des résultats difficilement interprétables.
Comme tout ce qui concerne ARIA, seuls des tests de restitution en situation réelle peuvent valider l'utilisation cohérente des « live region ».