Kit de survie du développeur ARIA (2/3)

La documentation Notes on Using ARIA in HTML devrait être entre les mains de tout développeur soucieux d’implémenter ARIA. Illustrée d’exemples, elle permet de comprendre les bases fondamentales d’une utilisation raisonnée de l’API.

Cet article en trois partie détaille les cinq règles de base et l’utilisation spécifique de certaines propriétés en s’appuyant notamment sur leurs conséquences pour l’utilisateur.

Dans cette seconde partie, nous aborderons les deux dernières règles :

  • ne pas supprimer la sémantique ou empêcher la restitution d’un élément ;
  • associer un nom à chaque composant.

Ne pas supprimer la sémantique ou empêcher la restitution des éléments interactifs

N’utilisez pas le rôle présentation ou la propriété aria-hidden="true" sur des éléments interactifs visibles. (Source : Fourth rule of ARIA use)

Cette règle est particulièrement complexe. Toutefois son but initial est relativement simple à comprendre : il s’agit de s’assurer que les éléments interactifs visibles sont effectivement restitués.

Conséquences sur l’utilisateur

ARIA possède deux propriétés qui peuvent avoir des conséquences catastrophiques si elles sont mal utilisées.

Le rôle presentation

Le rôle presentation permet d’annuler la sémantique associée à un élément. Par exemple, un titre HTML (hx) sur lequel on implémente un rôle presentation sera restitué comme un simple texte.

On fait souvent appel à ce rôle pour annuler la sémantique des éléments HTML utilisés comme fallback, par exemple afin d’annuler la sémantique d’une liste servant à structurer un système d’onglets.

Utiliser à mauvais escient le rôle presentation peut avoir pour conséquence de rendre l’élément incompréhensible et de supprimer les fonctionnalités permettant à l’utilisateur d’interagir.

Attention : la suppression de la sémantique sera effective pour l’élément lui-même et tous ses enfants, par exemple un role="presentation" sur un ul supprimera également la sémantique des li.

La propriété aria-hidden

La propriété aria-hidden est plus subtile mais tout aussi impactante : il s’agit simplement d’interdire la restitution de l’élément aux technologies d’assistance.

Cette propriété est indépendante de l’état affiché ou masqué de l’élément ; qu’il soit visible ou non, il ne sera pas restitué. C’est donc une propriété à risque qu’il faut employer avec minutie, surtout si elle vient en complément de directives CSS comme display:none. On ne le dira jamais assez : c’est inutile, la directive CSS fait très bien le travail et le risque est grand d’oublier la mise à jour de la propriété aria-hidden.

Toutefois, on peut avoir besoin de masquer aux lecteurs d’écran des éléments interactifs visibles parce qu’ils sont simplement inutiles.

Nous avons par exemple sur la page d’accueil d’Access42 un carrousel dont les contenus sont parcourus normalement avec un lecteur d’écran sans le recours aux éléments de navigation. En conséquence, ces derniers sont affectés d’une propriété aria-hidden="true" afin de ne pas perturber les utilisateurs de lecteurs d’écran. Difficile dans ces circonstances d’interdire l’utilisation de aria-hidden sur les composants visibles.

Que dit le RGAA ?

Le RGAA n’implémente pas directement cette règle dont l’application est très contextuelle. En revanche, en obligeant à tester systématiquement tous les dispositifs JavaScript/ARIA avec les lecteurs d’écran de la base de référence, le RGAA s’assure que l’utilisation inappropriée du rôle presentation ou de la propriété aria-hidden est vérifiée.

Test 7.1.5 : Chaque script qui génère ou contrôle un composant d’interface via des rôles, des états ou des propriétés définis par l’API ARIA respecte-t-il une de ces conditions ?

Associer un nom à chaque élément interactif

Chaque élément interactif doit avoir un nom accessible. (Source : Fifth rule of ARIA use)

Cette règle est une application directe d’un critère WCAG :

4.1.2 : pour tout composant d’interface utilisateur (comprenant mais n’étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l’utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d’assistance. (Source : 4.1.2 - nom, rôle, valeur)

L’accessible name est le nom associé à un élément tel qu’il sera mis à disposition dans l’accessible tree par les navigateurs.
Pour savoir quel est le nom associé, le navigateur s’appuie sur la spécification HTML et sur les règles de calcul définies dans ce document : Accessible Name and Description : Computation and API Mappings 1.1 qui règle les cas de concurrence entre plusieurs noms possibles.

Conséquences pour l’utilisateur

Nativement les éléments HTML possèdent tous un nom : intitulé de lien, label d’un champ de formulaire, intitulé d’un bouton sont autant d’exemples de nom accessible.

On comprend bien que si un élément n’a pas de nom associé, l’utilisateur ne saura pas de quel élément il s’agit.

Lorsque vous développez vos propres composant avec JavaScript et ARIA vous devez leur associer un nom, cette règle ne souffre aucune exception.

Vous avez le choix de la méthode : propriété aria-labelledby, aria-label, attribut title ou encore un intitulé défini par un motif de conception comme l’intitulé d’un onglet, par exemple.

Que dit le RGAA ?

Dans le RGAA cette problématique est reprise autant de fois que nécessaire par plusieurs critères comme la présence et la pertinence des labels de formulaire.

Pour ce qui concerne les composants développés avec JavaScript et ARIA, l’obligation est double : vous devez respecter les motifs de conception et tester les restitutions avec les lecteurs d’écran de la base de référence. Critère 7.1 [A] Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ?

En résumé

Un bon développeur d’applications web doit :

  • Privilégier les éléments natifs HTML lorsque c’est possible ;
  • Ne modifier la sémantique des éléments natifs que lorsque nécessaire et sans conséquences pour l’utilisateur ;
  • S’assurer que les composants sont opérables au clavier et à la souris ;
  • Vérifier que la suppression de la sémantique ou la désactivation de la restitution vocale d’un élément HTML n’a pas de conséquences pour l’utilisateur ;
  • S’assurer que chaque composant a un nom correctement lié au composant.

Avec l’habitude, ces règles deviennent de simples réflexes de développeur et permettent à vos applications de disposer d’un socle de base accessible.

Conclusion

Si les principes qu’elles illustrent sont clairs, ces règles fondamentales peuvent poser des problèmes d’application qui justifient qu’elles ne soient pas toujours suivies à la lettre. C’est en comprenant bien les mécanismes sur lesquels elle s’appuient, la logique du développement ARIA et ses conséquences sur l’utilisateur que le développeur pourra arbitrer et choisir la bonne approche pour ses composants.

Une troisième partie viendra compléter cet article afin de préciser d’autres subtilités à l’utilisation d’ARIA.