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

Cet article fait partie d’une série sur le vaste monde des alternatives textuelles :

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 en situation de handicap. 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- (se référer au glossaire pour en savoir plus).

Les attributs ARIA permettent uniquement aux utilisateurs et utilisatrices de lecteurs d’écran (voir glossaire) 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 en situation de handicap (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·e expert·e 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 Internet Explorer, 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 : les lecteurs d’écran ne restituent que le contenu de ces attributs lorsqu’ils sont présents sur une balise qui a déjà un texte à l’intérieur. 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 ; dans ce contexte, 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 documentation de MDN en français à propos de l’attribut aria-label.

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) (voir glossaire), 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 – voir glossaire). Il faudra utiliser la technique du texte masqué en CSS dans ce cas (voir l’article 5/6 de cette série).

<!-- 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>
Un champ de formulaire sans balise <label> associée

L’usage de l’attribut aria-label sur un champ de formulaire est conditionné au fait qu’il soit « si nécessaire, accompagné d’un passage de texte visible et accolé au champ permettant de comprendre la nature de la saisie attendue » (voir critère 11.1 du RGAA). Cela peut être le cas, par exemple, si l’outil que vous utilisez pour faire des formulaires ne permet pas l’usage de la balise <label> mais vous permet de mettre des textes simples en guise de libellé visible (mais non attachés techniquement).

Le « si nécessaire » permet d’utiliser également :

  • un attribut title, en plus de l’attribut aria-label ; ce qui permettrait aux personnes utilisant une souris d’avoir également le libellé (mais pensons aux écrans tactiles…) ;
  • un attribut placeholder, en plus de l’attribut aria-label ; à condition qu’il soit suffisamment contrasté et qu’il fasse bien office de libellé (on mettrait donc le même texte que dans l’attribut aria-label pour faire plus simple). Attention dans ce cas, à ne pas mettre de libellé trop long car, alors, en vue mobile ou en agrandissant la taille de police du texte, le placeholder pourrait se retrouver automatiquement tronqué dans le champ. Ainsi, il ne serait plus forcément possible de savoir ce qu’il faut saisir dans le champ.

Par conséquent, l’usage de la balise <label> rattachée 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" aria-label="Recherche dans le site" />

Merci à goetsu pour son retour sur ce sujet.

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 documentation de MDN en français à propos de l’attribut aria-labelledby.

Quelques exemples :

Un groupe de champs de formulaire

Il arrive, malheureusement, qu’on ne puisse pas utiliser le couple de balises 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 24ème 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

<p id="internal-nav">Les alternatives textuelles</p>
<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 documentation de MDN en français à propos de l’attribut aria-describedby.

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 (voir le paragraphe sur le support dans la technique ARIA15 (en anglais)). En décembre 2018, 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>

6 commentaires... Et vous, qu'en pensez-vous ?

  1. Bonjour,

    Pour :

    <button type="submit" aria-label="Rechercher dans le site">
      <span class="icon-search" aria-hidden="true"></span>
    </button>

    Il faut du texte dans la balise button, le aria-label ne peut pas remplacer le texte d’un bouton. Dans ce cas là, il faut un texte caché.

    Le bouton doit être aussi utilisable si CSS est désactivé (exigence RGAA). Ici, si CSS est désactivé, l’icône n’est plus visible et pas de texte de remplacement.

  2. Bonjour Claire,

    Merci pour ton retour. J’avoue que ça m’a effleuré l’esprit mais je n’ai pas suffisamment relu cet article avant de le publier visiblement !

    Tu as raison.

    Je vais changer mon exemple et ajouter cette précision. J’ai vu d’autres exemples avec un « X » dans un bouton de fermeture ; même si ce n’est pas pertinent, cela fonctionnerait dans ce cas.

  3. Oui pour un bouton de fermeture avec un X, en effet tu peux mettre le aria-label comme tu l’indiques dans ton exemple.

    Dans ce cas, on a le X si CSS est désactivé, le bouton n’est pas vide et le aria‐label précise l’intitulé du bouton :)

    Et merci pour cet article :)

  4. Bonjour,

    Merci pour l’article.

    Petite remarque (marginale) : aria-label dans un span n’est pas intercepté par Firefox.

  5. Bonjour Ludovic,

    J’imagine que dans la phrase « dans un span », c’était plutôt « sur » qui était entendu ?

    Effectivement, j’ai justement mis un paragraphe en évidence dans mon article précisant que c’était mieux restitué en utilisation sur des balises sémantiques ; ce que n’est ni le <span> ni la <div>.

    Lorsqu’on écrit <span aria-label="truc">Chose</span>, c’est effectivement « Chose » qui est lu par le lecteur NVDA avec Firefox. C’est peut‐être le cas avec d’autres lecteurs d’écran. En tout cas, ce n’est pas une construction suffisamment robuste pour être utilisée en l’état.

  6. Bonjour Julie,

    « Dans » la balise d’ouverture du span, « sur » celui‐ci donc, oui :)

Les commentaires sont fermés.