Comment donner un nom accessible à un champ de formulaire ?

Qu’est-ce que le nom accessible d’un champ de formulaire ?

Le nom accessible d’un champ de formulaire est l’intitulé qui sera restitué par les technologies d’assistance : vocalisé par les lecteurs d’écran et utilisé pour le contrôle vocal.

Méthode simple pour créer le nom accessible d’un champ : l’étiquette visible

Si votre champ de formulaire possède une étiquette visible, bonne nouvelle : créer un nom accessible est facile.

Qu’importe que votre champ de formulaire soit un champ texte, une liste de choix, une case à cocher ou un bouton radio, la technique native pour relier l’étiquette visible à son champ est la même : la balise label.

Cependant, l’utilisation seule de la balise label ne suffit pas : vous devez aussi utiliser un attribut for qui cible l’attribut id du champ. Cet id doit, entre autres, être unique dans la page.

Par exemple :

<label for="name-field ">Nom</label>
<input id="name-field " type="text" />

Attention, si vous avez pour habitude d’imbriquer l’élément input dans la balise label, n’oubliez pas non plus la liaison « for / id », car certaines technologies d’assistance peuvent en avoir besoin (notamment le contrôle vocal).

Par exemple :

<label for="name-field">
    Nom
    <input id=" name-field» type="text » />
</label>

Un autre avantage de la liaison « for / id » est qu’elle va permettre au champ ciblé de prendre le focus si l’utilisateur clique sur sa balise label.

Avec cette technique native, accessible et robuste, vous devriez être en mesure de couvrir la grande majorité des besoins d’accessibilité dans vos formulaires.

Autres méthodes pour donner un nom accessible à un champ de formulaire

Cependant, il existe des situations spécifiques où vous aurez besoin d’utiliser une autre technique que la balise label, par exemple : un écran applicatif, des contraintes techniques ou encore certains choix graphiques.

Or, il est important de savoir que chaque technique a ses spécificités et n’a pas le même poids lors du calcul du nom accessible.

Priorité de chaque méthode par rapport aux autres

En effet, le nom accessible sera calculé par le navigateur, par priorité, en fonction des attributs et balises HTML présents dans le code, selon l’algorithme suivant :

1. La propriété aria-labelledby qui a pour valeur l’identifiant id du texte, ou les identifiants id de plusieurs textes, qui doivent servir de nom accessible au champ :

   <p id="name-tx">Nom</p>
   <input type="text" aria-labelledby="name-tx" />
2. La propriété aria-label qui va contenir directement le contenu de l’étiquette à restituer :

   <input type="text" aria-label="Nom" />
3. La balise label, qui doit être reliée au champ par une liaison entre son attribut for et l’attribut id du champ, comme nous l’avons vu :

   <label for="name">Nom</label>
   <input id="name" type="text" />
4. L’attribut title, qui fera apparaître une infobulle au survol pour les personnes qui utilisent un pointeur (une souris ou un trackpad par exemple) :

   <input title="Nom" type="text" />

Attention : dans ce dernier cas, l’infobulle créée par l’attribut title s’affichera seulement au survol sur la plupart des navigateurs. Les personnes qui naviguent au clavier, sans souris, ne pourront donc peut-être jamais la consulter, à moins que vous n’implémentiez une solution comme AccessTooltip.

Que faire si vous cumulez plusieurs méthodes ?

Il peut arriver que vous utilisiez plusieurs méthodes en même temps au sein d’un même formulaire : par exemple, une propriété aria-label sur un champ correctement relié à sa balise label.

Dans ce cas, c’est l’ordre défini par l’algorithme de calcul qui déterminera le nom accessible, c’est-à-dire l’étiquette de champ qui sera effectivement restituée aux utilisateurs et utilisatrices de technologies d’assistance. Les autres éléments seront simplement ignorés !

Remarque : dans les cas les plus courants, il n’y a aucune raison de cumuler les méthodes de définition du nom accessible. Cela est bien souvent une source d’erreur, voire une dette technique. Cette surcharge ne doit intervenir que s’il y a une contrainte technique qui l’exige.

<label for="field1">Nom</label>
<input id="field1 type="text" aria-label="Name" />

Dans cet exemple, le champ aura pour étiquette visible « Nom », mais son nom accessible sera « Name », car la propriété aria-label est prioritaire pour le calcul du nom accessible.

La seule exception concerne l’attribut title : lorsqu’il est cumulé avec une autre méthode, par exemple avec une propriété aria-label, il pourra être utilisé pour définir la description du champ.

Nous reparlerons des descriptions de champ dans un prochain article dédié aux aides à la saisie.

Le placeholder n’est pas une méthode accessible

L’avez-vous remarqué ? L’attribut placeholder n’est pas utilisé par l’algorithme qui calcule le nom accessible d’un champ de formulaire.

En effet, l’attribut placeholder pose plusieurs problèmes d’accessibilité.

C’est pourquoi un placeholder ne suffit pas pour nommer un champ de manière accessible.

Si un placeholder est prévu sur la maquette graphique, il est essentiel d’implémenter dans le code, en plus du placeholder, une des quatre méthodes prévues par le RGAA que nous avons détaillées plus tôt dans cet article.

Le placeholder peut néanmoins être utilisé pour doubler l’information, par exemple pour fournir le format de saisie d’un champ attendant une adresse e-mail :

Que faire si le champ contient un placeholder et qu’il n’y a pas d’étiquette visible ?

Si le placeholder est la seule indication visible sur la maquette, voici une façon de réparer l’accessibilité :

• doublez l’attribut placeholder avec un attribut title, à ajouter sur le champ. Le title doit reprendre exactement la même valeur que le placeholder. En effet, le placeholder n’est pas reconnu comme une étiquette visible par le RGAA. De plus, il n’est plus visible dès que l’utilisateur commence sa saisie.
   <input type="text" title="Nom" placeholder="Nom" />
• demandez à l’équipe design de vérifier, et corriger si besoin, que le placeholder présente un rapport de contraste conforme avec la couleur d’arrière-plan. (Pour rappel : rapport de contraste de 3:1 ou 4,5:1 selon la taille et la graisse du texte, conformément au critère 3.2 du RGAA.)

Solutions avec les propriétés WAI-ARIA aria-labelledby et aria-label

Rappelez-vous ce principe d’ARIA : préférez toujours la méthode native HTML à une technique ARIA, quand vous en avez la possibilité.

Quand utiliser une balise label n’est pas possible, les propriétés ARIA aria-labelledby et aria-label permettent de fournir un nom accessible aux champs de formulaires concernés.

Avec la propriété aria-labelledby

La propriété aria-labelledby permet de relier un ou plusieurs textes présents sur la page à votre champ de formulaire.

Avant d’utiliser cette méthode, si vous n’avez pas de contrainte de combinaison d’étiquettes, nous vous conseillons de reconsidérer la possibilité d’utiliser la méthode native.

Exemples d’intégration avec aria-labelledby aria-labelledby

aria-labelledby pour utiliser un texte visible comme nom accessible

Il est très rare d’avoir besoin de cette technique, car en théorie, rien ne vous empêche d’utiliser une balise label pour définir l’étiquette de votre champ de formulaire.

Cependant, si l’étiquette du champ est également un titre (par exemple, un titre h1), vous pouvez utiliser une propriété aria-labelledby pour ne pas répéter « Nouveau mot de passe » et conserver sa sémantique de titre de niveau 1.

<h1 id="new-pwd-label">Nouveau mot de passe</h1>
<input type="text" aria-labelledby="new-pwd-label" />

aria-labelledby pour rendre accessibles plusieurs textes visibles

aria-labelledby est la seule technique qui permet de relier plusieurs étiquettes visibles au même champ. Il est possible de combiner plusieurs identifiants en les séparant avec un espace. Dans l’exemple suivant, le champ est défini par deux textes visibles : « Prix » et « en euros ».

Pour l’accessibilité, il est essentiel de restituer ces deux textes. Ainsi, les personnes aveugles ou malvoyantes seront au même niveau d’information que les autres.

Dans ce type de cas, aria-labelledby est tout indiqué :

<p id="prix-label">Prix : </p>
<input type="text" aria-labelledby=" prix-label prix-unité" />
<p id=" prix-unite">en euros</p>

Attention ! Les lecteurs d’écran s’appuient sur l’ordre des identifiants indiqués en valeur de la propriété aria-labelledby pour déterminer l’ordre de la restitution.

La propriété aria-labelledby présente un avantage par rapport à la propriété aria-label : en effet, si les textes ciblés sont mis à jour, vous n’aurez rien à modifier, tant que les identifiants ciblés par aria-labelledby ne changent pas.

En revanche, voici ce que la propriété aria-labelledby ne permet pas : si l’utilisateur clique sur le texte ciblé par la propriété aria-labelledby, le focus ne sera pas remplacé sur le champ de formulaire, contrairement au clic sur une balise label correctement reliée.

Avec la propriété aria-label

La propriété aria-label prend comme valeur le nom accessible que vous souhaitez définir.

Puisque votre champ de formulaire doit avoir une étiquette visible, nous n’avons pas besoin de cette propriété en théorie puisque la balise label nous apporte la solution.

Mais si pour diverses raisons, vous ne pouvez faire autrement, alors la règle est que la valeur de la propriété aria-label doit contenir l’étiquette visible (critère 11.2.5 du RGAA).

Exemple d’intégration avec aria-label

Dans cet exemple, une étiquette visible jouant également le rôle de titre de niveau 1 est reprise dans une propriété aria-label afin de définir un nom accessible au champ texte :

<h1 id="new-pwd-label">Nouveau mot de passe</h1>
<input type="text" aria-label="Nouveau mot de passe" />

Encore une fois, dans la plupart des cas, vous utiliserez une balise label pour donner une étiquette au champ.

Mais si, à cause d’une contrainte technique, vous ne pouvez pas ajouter un identifiant sur votre étiquette (indispensable à l’utilisation de la propriété aria-labelledby), alors la technique avec aria-label peut s’avérer utile.

Conclusion

Vous savez maintenant comment concevoir et intégrer des étiquettes de formulaire accessibles.

La balise label, correctement reliée à son champ via un attribut for, reste la solution à privilégier dans la plupart des cas.

Réservez les propriétés ARIA aria-labelledby et aria-label à des cas spécifiques, quand vous ne pouvez pas faire autrement.

Les formulaires sont un sujet critique en accessibilité : il y a encore trop de formulaires inutilisables par les personnes en situation de handicap, faute de développement accessible.

Il reste encore beaucoup de points à aborder pour faire le tour des formulaires. Nous continuerons cette série avec les aides à la saisie lors d’un futur article.