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

Dans cette deuxième 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.

Exemple

Vous aurez sans doute l’occasion de rencontrer régulièrement cette implémentation pour un système d’onglets :

<ul role="tablist">
<li role="presentation"><button role="tab" aria-controls="@id" aria-selected="false">onglet </button></li>
[...]
</ul>

Dans cette implémentation, le rôle tablist surcharge la liste ul utilisée pour structurer la liste d’onglets et le rôle presentation, appliqué sur les li, supprime la sémantique des items de liste, remplacée par le rôle tab appliqué sur les boutons. On obtient donc une liste de tab dans une tablist, c’est parfait.

À noter : l’utilisation de bouton comme en-tête des onglets n’est qu’un moyen pratique d’économiser la gestion des évènements JavaScript déclencheurs (enter et espace) nativement utilisés par un bouton.

Avec la petite difficulté de devoir gérer les évènements déclencheurs, il aurait été possible de ne pas avoir recours au rôle presentation, en utilisant les li directement :

<ul role="tablist">
<li role="tab" aria-controls="@id" aria-selected="false" tabindex="0">onglet 1</li>
[...]
</ul>

Enfin, l’utilisation d’une liste ul est une sorte d’atavisme de développeur. Fonctionnellement, une simple succession de div correctement traitée fait tout aussi bien l’affaire.

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 développé chez Access42 un petit 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.

Exemple

La propriété aria-hidden="true" est particulièrement intéressante dans le cas de l’utilisation de fonte-icônes associées à des textes masqués, comme dans cette implémentation que vous pouvez retrouver sur AccesSlide :

<button type="button" id="next" title="Suivant">
        <span class="icon-fallback-text">
                <span class="icon icon-next" aria-hidden="true"></span>
                <img src="img/next.png" alt="Suivant" class="text">
        </span>
</button>

Dans cette implémentation, la propriété aria-hidden="true" permet de ne pas restituer la fonte-icône qui reste malgré tout visible, au profit de l’alternative masquée, ici constituée d’une image.

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 le 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 ?

Exemple

Il est important de bien retenir que les propriétés ARIA qui permettent de labelliser un élément sont restituées selon un ordre précis. Par exemple, pour un champ de formulaire de type text l’ordre sera :

1. aria-label
2. aria-labelledby
3. label
4. title

Concrètement, cela veux dire que dans cette implémentation :

<label for="ident">Nom et prénom</label>
<input id="ident" type="text" aria-label="Votre identité" />

Le nom restitué sera « Votre identité » et pas « Nom et prénom ».

Vous pouvez consulter le détail des calculs de restitution dans le document « HTML Accessibility API Mappings 1.0 ».

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.

Ne manquez pas la troisième partie de ce kit de survie ARIA précise d’autres subtilités à l’utilisation d’ARIA.