Le vaste monde des alternatives textuelles : les attributs ARIA : à n’utiliser qu’en connaissance de cause (6/6)

ARIA, Accessible Rich Internet Applications (en français, « Applications Internet riches accessibles »), est une spécification qui donne des moyens d’aider à rendre plus accessibles des interfaces web aux personnes handicapées. Elle aide notamment à rendre accessibles aux technologies d’assistance les contenus dynamiques utilisant des scripts. Elle est constituée d’un certain nombre d’attributs HTML commençant généralement par aria-.

Les attributs ARIA permettent uniquement aux utilisateurs et utilisatrices de lecteurs d’écran de mieux comprendre les informations qu’on essaye de transmettre sur un site web. Par conséquent, cela ne peut être la solution pour tout et n’importe quoi car les lecteurs d’écran ne sont pas utilisés par toutes les personnes handicapées (voir le bilan d’une étude menée en 2015).

Avant tout, notons bien qu’un attribut ARIA mal utilisé peut faire plus de mal que de bien. Prenez garde à vous entourer d’un ou une experte en accessibilité pour valider l’utilisation que vous en faites.

Il est intéressant de savoir que la spécification ARIA n’est pas encore complètement fonctionnelle avec tous les navigateurs et tous les lecteurs d’écran. Généralement, il y a des combinaisons à privilégier comme Jaws avec Firefox, NVDA avec Firefox, VoiceOver avec Safari. Avec le temps, les différences s’estompent et il devient de plus en plus possible d’utiliser ces trois lecteurs d’écran principaux avec n’importe quel navigateur. Malgré tout, il reste encore un peu de travail pour qu’ARIA soit bien prise en compte, comme en témoigne cette page en anglais de PowerMapper à propos de la compatibilité des lecteurs d’écran avec ARIA.

Dans la spécification ARIA, il existe trois attributs qui permettent d’ajouter du contexte textuel à des éléments : aria-label, aria-labelledby, aria-describedby. Parmi eux, seul l’attribut aria-label peut servir d’alternative textuelle car les deux autres attributs améliorent la compréhension en attachant du texte visible par toutes et tous à un élément. Je parle quand même des trois attributs ici afin de bien expliquer leurs ressemblances et différences.

Nommer un élément, un composant : aria-label, aria-labelledby

Les attributs aria-label et aria-labelledby permettent de donner un titre, un intitulé à un élément ou un composant. Ils ne s’utilisent pas tout à fait de la même façon mais exercent le même rôle.

Bon à savoir : lorsque ces attributs sont présents sur un élément HTML qui a déjà un texte à l’intérieur, les lecteurs d’écran ne restituent que le contenu de ces attributs et pas le texte présent dans l’élément HTML. Par exemple pour <button type="button" aria-label="Fermer">X</button>, le lecteur d’écran ne vocalisera pas le « X ». Il ne faut donc pas utiliser ces attributs pour donner uniquement un complément d’information, une description ; pour ce faire, on utilisera plutôt l’attribut aria-describedby (voir plus loin).

Ces attributs sont mieux restitués s’ils sont utilisés sur des balises sémantiques (notamment les éléments interactifs comme les liens, boutons, champs de formulaire) ou des balises possédant un attribut ARIA role qui permet justement d’ajouter de la sémantique.

Les attributs aria-label et aria-labelledby ne doivent jamais être vides : soit, ils sont renseignés de façon pertinente, soit, ils ne sont pas présents.

L’attribut aria-label

L’attribut aria-label prend pour valeur un texte : aria-label="Mon intitulé". Il permet d’expliciter un élément grâce à un texte non visible par ailleurs. Cet attribut sert donc d’alternative textuelle dans les cas où on n’a pas le choix car on ne peut pas rendre visible les libellés (souvent pour des raisons graphiques…).

On pourra se servir de l’attribut aria-label dans différents contextes.

Pour aller plus loin vous pouvez consulter la spécification WAI-ARIA sur l’attribut aria-label (en anglais).

Point d’attention suite à la mise à jour de WCAG en version 2.1 (5 juin 2018)

Le critère 2.5.3 des WCAG 2.1 (en anglais), intitulé « Label in name », tient désormais compte des utilisateurs et utilisatrices qui pilotent leur ordinateur à la voix. Comme l’attribut aria-label agit en remplacement de tout intitulé présent entre les balises ouvrantes et fermantes, l’intitulé visible doit impérativement être repris dans le nom ARIA. Ainsi, si j’ai un bouton dont l’intitulé visible est « OK » et que je lui mets un attribut aria-label pour le préciser, alors l’attribut aria-label devra ressembler à ceci : aria-label="OK, rechercher dans le site". Cela permettra à une personne pilotant à la voix de pouvoir demander à cliquer sur le bouton « OK ». En effet, cette personne ne pourra pas deviner le contenu d’un libellé invisible (l’aria-label).

Il y a eu une discussion très intéressante au début du mois de janvier 2019, initiée par Steve Faulkner sur Twitter, où il se demandait si ce code était conforme au critère 2.5.3 des WCAG 2.1 : <button type="button" aria-label="Fermer">X</button>. Il arrive souvent, dans les modales (ou popins), d’avoir ce cas ou même d’avoir le signe « multiplier » (×) en guise d’icône de fermeture. En soi, il s’agit d’un texte qui, si on se réfère strictement au critère WCAG, devrait être repris dans l’attribut aria-label. Cependant, je pense que cela impliquerait (si on pousse la logique jusqu’au bout) de faire de même avec les vraies icônes qu’il est parfois difficile de nommer clairement et cela rendrait les libellés de boutons incompréhensibles : « X, fermer » ou « Loupe, rechercher dans le site » ne sont pas vraiment pertinents. Par ailleurs, je ne sais pas, à l’heure actuelle, si les personnes pilotant à la voix diraient de cliquer sur le bouton « X » ou de cliquer sur le bouton « Fermer ». Je n’arrive donc pas à trancher.

Je pense que, de manière générale, il faut vraiment que l’on essaye d’éviter d’utiliser uniquement des icônes ou des lettres en guise d’icônes pour faire des boutons. Leur associer un libellé visible permettrait aux personnes qui pilotent à la voix de piloter n’importe quel bouton sans se poser de question. Cela permettrait également de ne pas avoir à deviner ce qui se cache derrière une icône pas très claire.

Quelques exemples d’utilisation de l’attribut aria-label

Un bouton avec un intitulé non pertinent

Il arrive de rencontrer des boutons de fermeture avec la lettre « X » à l’intérieur. Ce n’est pas pertinent pour un utilisateur à qui le lecteur d’écran lira bien « X » et non pas « Fermer ». L’attribut aria-label sera d’un grand secours.

<button type="button" aria-label="Fermer la fenêtre">
	X
</button>

Petite précision suite au retour de Claire Bizingre dans les commentaires : si dans le bouton, on a une icône affichée en CSS uniquement, alors cette technique n’est pas valide. En effet, le bouton deviendra invisible en cas de désactivation des feuilles de styles CSS (critère du RGAA sur les feuilles de style désactivées). Il faudra utiliser la technique du texte masqué en CSS dans ce cas (voir l’article 5/6 de cette série).

D’ailleurs, je vous conseille d’éviter carrément d’utiliser l’attribut aria-label pour les liens et boutons car, mal paramétré, il peut rendre ces éléments totalement inaccessibles. Utilisez plutôt la technique du texte masqué en CSS, elle est plus sûre et moins nocive en cas de mésusage.

<!-- Ceci est un mauvais exemple -->
<button type="submit" aria-label="Rechercher dans le site">
	<span class="icon-search" aria-hidden="true"></span>
</button>

Un autre exemple est celui d’un bouton « Rechercher » : si vous avez plusieurs formulaires de recherche dans votre site, on pourra préciser l’intitulé du bouton via l’attribut aria-label :

<button type="button" aria-label="Rechercher un itinéraire">
	Rechercher
</button>

Sinon, vous aurez peut-être un bouton « OK » quelque part. Rien de tel qu’un petit attribut aria-label pour expliciter un peu plus ce bouton (et pour le pilotage à la voix, on reprendra « OK » dans l’attribut) :

<button type="button" aria-label="OK, confirmer mon inscription à la newsletter">
	OK
</button>

Mais, préférez quand même d’avoir un intitulé de bouton explicite directement.

Un champ de formulaire sans élément <label> associé

L’usage de l’attribut aria-label sur un champ de formulaire est conditionné, selon le test 11.1.3 du RGAA, au fait :

• qu’il soit accompagné d’un passage de texte visible (ou visible à la prise de focus, mais là, on ne comprend pas bien l’intérêt pour le pilotage à la voix…) et accolé au champ permettant de comprendre la nature de la saisie attendue ;
• ou que le champ possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue. Et là, on ne comprend pas non plus l’intérêt pour le pilotage à la voix, pour les écrans tactiles ou la navigation clavier où l’affichage de cet attribut maudit n’est pas géré.

Cela peut être le cas, par exemple, si l’outil (pourri) que vous utilisez pour faire des formulaires ne permet pas l’usage de l’élément <label> mais vous permet de mettre des textes simples en guise de libellé visible (mais non attachés techniquement).

Par conséquent, l’usage de l’élément <label> rattaché au champ via son attribut for et visible au-dessus du champ est vivement conseillé plutôt que cet exemple :

<input type="search" placeholder="Recherche dans le site" title="Recherche dans le site" aria-label="Recherche dans le site" />

Dans le code ci-dessus, l’attribut placeholder reprenant le nom accessible du champ (aria-label), cela permet au moins qu’on puisse l’atteindre via pilotage à la voix mais cela a le défaut de s’effacer à la saisie. Toutefois, il faudra veiller au contraste de cet attribut (souvent insuffisant par défaut).

Un menu de navigation

Il peut être utile de nommer une navigation car il y en a souvent plusieurs dans une page.

<nav role="navigation" aria-label="Menu principal">
	<ul>
		<li><a href="#">Élément 1</a></li>
		<li><a href="#">Élément 2</a></li>
	</ul>
</nav>

L’attribut aria-labelledby

L’attribut aria-labelledby prend pour valeur l’identifiant d’un autre élément (sans le dièse #) : aria-labelledby="identifiant". Cet attribut peut prendre plusieurs valeurs ; celles-ci seront alors séparées par une espace : aria-labelledby="identifiant1 identifiant2". Il permet de rattacher un texte visible à un élément afin que les technologies d’assistance puissent bien rattacher les informations entre elles. Ce n’est donc pas vraiment une alternative textuelle mais il est important de l’évoquer pour faire la distinction avec l’attribut aria-label.

Pour aller plus loin vous pouvez consulter la spécification WAI-ARIA sur l’attribut aria-labelledby (en anglais).

Quelques exemples :

Un groupe de champs de formulaire

Il arrive, malheureusement, qu’on ne puisse pas utiliser le couple d’éléments sémantiques <fieldset> et <legend> afin de regrouper des champs de formulaire. Dans ce cas, il existe une technique avec ARIA pour que ce groupe soit malgré tout accessible (cf. mon retour sur le 24e séminaire AccessiWeb).

<div role="group" aria-labelledby="field-legend-1">
	<p id="field-legend-1">L’accessibilité, c’est important !</p>
	
	<label for="true">Vrai</label>
	<input type="radio" id="true" name="radio-group-1" value="vrai" />
	
	<label for="false">Faux</label>
	<input type="radio" id="false" name="radio-group-1" value="faux" />
<div>

Un menu de navigation avec un titre visible

<h2 id="internal-nav">Les alternatives textuelles</h2>
<nav role="navigation" aria-labelledby="internal-nav">
	<ul>
		<li><a href="#">Élément 1</a></li>
		<li><a href="#">Élément 2</a></li>
	</ul>
</nav>

Décrire un élément, un composant : aria-describedby

L’attribut aria-describedby permet d’ajouter une information complémentaire, une description à un élément. Il ne sert pas de libellé et est donc différent d’une alternative textuelle. Cependant, en rattachant via cet attribut un texte descriptif à un composant, on peut grandement aider les personnes utilisant des technologies d’assistance à comprendre l’information donnée. Son écriture est similaire à celle de l’attribut aria-labelledby.

Il prend pour valeur l’identifiant d’un autre élément (sans le dièse #) : aria-describedby="identifiant". Cet attribut peut prendre plusieurs valeurs ; celles-ci seront alors séparées par une espace : aria-describedby="identifiant1 identifiant2". Il permet de rattacher un texte visible à un élément afin que les technologies d’assistance puissent bien rattacher les informations entre elles.

L’attribut aria-describedby ne doit jamais être vide : soit, il est renseigné de façon pertinente, soit, il n’est pas présent.

Pour aller plus loin vous pouvez consulter la spécification WAI-ARIA sur l’attribut aria-describedby (en anglais).

Un champ de formulaire avec un message d’aide

Dans une validation avec un lecteur d’écran, à l’arrivée dans un formulaire, il se met en « mode formulaire ». Dans ce cas, il devient compliqué d’obtenir les informations qui se trouvent à proximité des champs, dans des paragraphes, par exemple. Par conséquent, il est important d’attacher ces informations aux champs concernés avec ARIA afin qu’elles puissent être lues.

<label for="tel-field">Numéro de téléphone</label>
<input type="tel" id="tel-field" aria-describedby="help-message-tel" />
<p id="help-message-tel">Votre numéro de téléphone sera utilisé uniquement pour vous rappeler suite à ce message. En aucun cas, il ne sera transmis à un tiers.</p>

Une image avec une description longue

En théorie, on devrait pouvoir associer une description longue à son image via l’attribut aria-describedby. Cependant, le support n’est pas parfait à l’heure actuelle. En décembre 2018 puis mai 2020, j’ai réalisé des tests de restitution avec les lecteurs d’écran de description longue pour des images avec les attributs longdesc et aria-describedby. Nous sommes encore loin de pouvoir utiliser le code suivant :

<img src="mon-image.jpg" alt="Plage braille" aria-describedby="long-desc-image" />
<p id="long-desc-image">Une plage braille est un outil qui ressemble à une petite tablette numérique qui se branche à un ordinateur. Des petits picots se lèvent ou s’abaissent sur la tablette pour former l’écriture braille au fur et à mesure de la lecture. Elle est utilisée par des personnes aveugles qui savent lire le braille.</p>

PowerMapper a également réalisé des tests en septembre 2022 qui concluent toujours au même résultat.