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

Les propriétés aria-labelledby et aria-describedby

La propriété aria-labelledby

Cette propriété va être utilisée de manière quasi permanente dans l’élaboration des composants JavaScript. Elle permet d’associer un passage de texte à un composant pour constituer son nom accessible par exemple pour un champ de formulaire :

<p id="foo">nom</p>
<input type="text" aria-labelledby="foo"/>

Lorsqu’elle est utilisée dans le contexte d’un composant défini par un motif de conception, elle sert par exemple à donner un nom accessible à une fenêtre modale ou à un panneau d’un système d’onglets en le liant à l’intitulé de l’onglet :

<div role="tablist">
<div role="tab" id="foo" [...]>onglet 1</div>
[...]
</div>
<div role="tabpanel" aria-labelledby="foo" [...]>
[...]
</div>

aria-labelledby remplace toute autre déclaration de nom. Autrement dit, s’il existe d’autres liaisons comme un aria-label, un title ou même un intitulé dans le cas d’un lien, ils seront ignorés et remplacés par le passage de texte lié par aria-labelledby.

Vous pouvez consulter à ce sujet le document Accessible Name and Description: Computation and API Mappings 1.1 qui décrit les algorithmes de résolution de nom pour chaque élément.

La propriété aria-describedby

Cette propriété fonctionne de la même manière pour lier des passages de texte que l’on souhaite restituer en complément d’un composant. Par exemple :

<p id="foo">nom</p>
<input type="text" aria-labelledby="foo" aria-describedby="foo1"/>
<p id="foo1">message d'aide</p>

Cette propriété est devenue indispensable dans le contexte des formulaires, c’est la solution la plus simple et la plus rapide pour associer des messages aux champs de formulaire tout en conservant la maîtrise totale du style et du positionnement des messages.

On peut également l’utiliser pour créer des bulles d’aide, notamment.

Support

Ces deux propriétés ont un support quelquefois inconstant.

aria-labelledby fonctionne très correctement dans le cas d’un composant défini par un motif de conception ou dans le cas d’un composant interactif comme les liens, les boutons, les champs de formulaire.

En revanche sur certains types d’éléments non-interactifs cela ne fonctionne pas encore. C’est le cas pour les tableaux, les listes, les images…

aria-describedby pose plus de problèmes, cela fonctionne très bien avec les boutons et les champs de formulaires et dans le cadre de certains motifs de conception mais c’est à peu près tout. Cela ne fonctionne pas encore sur certains éléments comme les tableaux ou les images.

Ainsi, il faut toujours vérifier soigneusement que les restitutions utilisant aria-describedby sont correctes.

Lier plusieurs passages de texte

Il est tout à fait possible de lier plusieurs passages de textes avec aria-labelledby et aria-describedby, il suffit d’associer les id en les séparant d’un espace :

<label for="saisie" id="foo">Quantité</label>
<input type="text" aria-labelledby="foo foo1" />
<span id="foo1">Kilo</span>

Dans cet exemple l’effet recherché est de pouvoir vocaliser « Quantité kilo » avant la saisie. aria-describedby fonctionnera exactement de la même manière.

Le cas d’Internet-Explorer

Ce mécanisme fonctionne très bien mais, dans le cas d’IE, de IE5 à IE11, il est nécessaire que les éléments liés soient considérés comme des éléments « accessibles », faute de quoi seul le premier passage de texte sera restitué.

Si le passage de texte lié fait partie d’un élément interactif il n’y aura rien à faire, en revanche dans le cas inverse il faudra ajouter un attribut tabindex sur les éléments non-interactifs que l’on veut lier :

<label for="saisie" id="foo">Quantité</label>
<input type="text" aria-labelledby="foo foo1"/>
<span tabindex="-1" id="foo1">Kilo</span>

Focus sur l’utilisation de contenus cachés liés

Les textes liés par les propriétés aria-labelledby ou aria-describedby font partie des propriétés de l’élément, ils sont donc toujours disponibles, y compris lorsqu’ils sont cachés par CSS avec display:none, visibility:hidden ou par l’attribut HTML hidden.

Cela a pour conséquence que vous ne pouvez pas, par exemple, prépositionner des messages d’erreur liés par aria-labelledby ou aria-describedby dans le code et les masquer par CSS car ils seront restitués au moment de la prise de focus qu’il y ait erreur ou pas.

Vous devez insérer dynamiquement les messages ou ajouter les propriétés ARIA uniquement au moment des erreurs afin d’assurer une restitution correcte.

Que dit le RGAA ?

Le RGAA prend en compte ces deux propriétés chaque fois qu’elles peuvent être utilisées comme méthode alternative, et plus particulièrement dans la thématique formulaire, par exemple pour créer une étiquette de formulaire ou pour lier une indication de champ obligatoire ou un message d’aide.

Le rôle application

Certains lecteurs d’écran, particulièrement sur Windows, utilisent deux modes d’interaction différents : le mode navigation (ou curseur virtuel) et le mode formulaire.

En mode navigation, les touches du clavier sont interceptées par le lecteur d’écran afin de permettre à l’utilisateur de bénéficier des raccourcis clavier dédiés à la navigation rapide dans le document.

En mode formulaire, c’est l’inverse : les touches du clavier sont passées au navigateur. C’est par exemple le cas lorsque qu’un champ de saisie prend le focus afin de permettre à l’utilisateur de saisir du texte ou d’interagir avec un composant complexe, comme une liste de sélection.

Les deux modes sont gérés automatiquement ou activables manuellement selon la nature des éléments rencontrés.

Le rôle application a un effet similaire au mode formulaire : les touches du clavier sont passées au navigateur, privant éventuellement l’utilisateur de la possibilité de naviguer dans le contenu autrement que par les méthodes implémentées par le développeur.

Pour en savoir plus vous pouvez lire cet excellent article de Léonie Watson que nous avons traduit : Comprendre les modes d’interaction des lecteurs d’écran.

Quand utiliser le rôle application ?

Vous ne devez utiliser le rôle application que lorsque vous êtes dans un contexte purement applicatif et parce que vous avez besoin de capturer le clavier pour offrir à l’utilisateur des interactions riches et spécifiques aux composants que vous développez.

Dans un contexte de contenu web et plus particulièrement sur les composants natifs ou développés en utilisant un motif de conception ARIA, vous ne devriez jamais utiliser le rôle application.

Certains composants développés en utilisant un motif de conception ARIA, comme les rôles dialog ou tab par exemple, déclenchent automatiquement un rôle application. Dans ce contexte, vous pouvez redonner la possibilité à l’utilisateur de lecteur d’écran de naviguer dans le(s) contenu(s) contrôlé(s) en surchargeant chaque zone de contenu avec le rôle document. Vous pouvez le faire par l’intermédiaire d’un div contenant l’ensemble du contenu.

Le rôle document est le rôle par défaut d’un contenu Web. Cela correspond au mode Navigation des lecteurs d’écran, ce qui permettra à l’utilisateur de pouvoir bénéficier des fonctionnalités de navigation avancées.

Si votre contenu ne contient que des éléments interactifs (liens, formulaires) c’est inutile. Mais si votre contenu ne contient que des éléments de contenu (titres, listes, tableaux, etc.) ou un mélange d’éléments interactifs et d’éléments de contenu, cela peut s’avérer très utile. La bascule avec le rôle application se fera automatiquement dès que l’utilisateur se déplacera sur les zones applicatives.

<div role="dialog" tabindex="-1" aria-labelledby="titre">
        <button>fermer</button>
        <div role="document" tabindex="0">
                <h1 id="titre">Titre de la fenêtre</h1>
                [contenu de la fenêtre]
        </div>
</div>

Dans cet exemple, le contenu est implémenté dans un div avec un rôle document.

L’utilisation d’un tabindex="0" sur le div déclaré comme « document » est indispensable pour donner accès au contenu. En effet, comme le rôle application a pour conséquence que le lecteur d’écran ne gère plus le clavier, les flèches de direction n’auront aucun effet pour lire le contenu de la fenêtre. Elle se contenteront de scroller la page, leur comportement par défaut.

L’accès au contenu par la tabulation, en prenant le focus sur le div englobant, permettra alors de déclencher le rôle document : l’utilisateur retrouvera l’usage habituel des flèches de direction pour parcourir le contenu.

Dans certains lecteurs d’écran, l’utilisateur peut basculer à la demande entre les deux modes. Par exemple, si on ne met pas de rôle document, l’utilisateur pourrait basculer en mode revue (rôle document) pour parcourir le contenu. C’est le cas avec NVDA et les touche NVDA + ESPACE par exemple.

Les utilisateurs avertis utilisent assez souvent cette possibilité lorsqu’ils rencontrent des problèmes mais ce n’est pas le cas de tous les utilisateurs ce qui rend cette adaptation particulièrement utile.

Dans tous les cas : vous devez tester vos composants ou votre application web avec les différents lecteurs d’écran de la base de référence afin de vérifier leur utilisabilité.

Que dit le RGAA ?

Le RGAA teste l’utilisation du rôle application par l’intermédiaire d’un test spécifique du critère 7.1 [A] :
Test 7.1.6 : Chaque composant d’interface qui utilise un rôle ARIA application respecte-t-il une de ces conditions ?

• Le composant d’interface est correctement restitué par les technologies d’assistance ;
• Une alternative accessible permet d’accéder aux mêmes fonctionnalités.

Conclusion

Cet article clôt cette série sur la note d’utilisation d’ARIA dont on ne répètera jamais assez qu’elle devrait faire partie des outils du quotidien de tous développeurs de composants ARIA.

Le RGAA cadre de manière la plus complète possible l’utilisation d’ARIA mais aucun référentiel ne peut être suffisamment étendu et précis dans un contexte de développement de composants riches ou d’applications web.

En revanche le RGAA propose beaucoup de ressources qui pourront vous être utiles, par exemple des tests de bibliothèques de composants, que vous pourrez retrouver sur le dépôt Github de la DINSIC : dépot des ressources RGAA de la DINISC.