S’assurer que chaque élément du formulaire possède une étiquette
Les exigences en matière d’accessibilité du web stipulent que chaque élément de formulaire doit être associé à un élément d’étiquetage programmatique.
Pourquoi c’est important
Les étiquettes de formulaire sont nécessaires pour rendre les formulaires accessibles. Les utilisateurs de lecteurs d’écran ont besoin d’étiquettes utiles pour identifier les champs du formulaire.
En l’absence d’étiquettes, les utilisateurs ne comprennent pas quelles données ils doivent saisir.
L’absence d’étiquettes empêche également les champs d’être mis en évidence lorsqu’ils sont lus par des lecteurs d’écran. Il en résulte que les utilisateurs souffrant de troubles du contrôle moteur ne peuvent pas bénéficier d’une plus grande zone cliquable pour le contrôle, puisque le fait de cliquer sur l’étiquette active le contrôle.
Résolution du problème
Les développeurs doivent associer par programme des étiquettes à tous les contrôles de formulaire. La méthode recommandée pour la plupart des scénarios consiste à utiliser l’élément label et une association spécifique à l’aide des attributs for et id.
Il est également important de s’assurer que tous les éléments id sont uniques sur chaque page et que le texte de l’étiquette a un sens pour quelqu’un qui l’écoute à l’aide d’un lecteur d’écran.
Les éléments de formulaire qui doivent être étiquetés sont les suivants
Les champs de saisie de texte, par exemple <input type=”text”>, <input type=”password”> et <textarea>
Les boutons radio, <input type=”radio”>
Les cases à cocher, <input type=”checkbox”>
Les seules exceptions à cette exigence sont les suivantes :
Les boutons – les boutons sont auto-étiquetés
Entrées cachées – Entrées dont la valeur de l’attribut type est cachée (par exemple, type=”hidden”). Ces entrées sont cachées et ne peuvent être saisies par l’utilisateur. Elles n’ont donc pas besoin d’étiquette.
Bon exemple de code :
<label for=”firstname”>First name:</label> <input type=”text” id=”firstname”>
L’étiquette peut également être implicite en enveloppant l’élément <label> autour de l’entrée :
<label>First name: <input type=”text”></label>
Si l’entrée est déjà étiquetée visuellement d’une autre manière, par exemple au moyen d’une icône de loupe sur un bouton de soumission de recherche, il peut être acceptable d’utiliser aria-label pour créer une étiquette de texte invisible que les lecteurs d’écran pourront lire.
<input type=”text” aria-label=”Search”>
Une autre méthode (parfois utilisée lorsque l’ajout d’une balise <label> entraînerait une rupture de fonctionnalité ou de style, ou lorsque plusieurs étiquettes s’appliquent à la même entrée) consiste à utiliser aria-labelledby à la place :
<div id=”firstname”>First name:</div> <input type=”text” aria-labelledby=”firstname”>
<!–visual labels may be elsewhere in the content, such as in table headers–>
<div id=”temperature”>Temperature:</div>
<div id=”high”>High:</div>
<div id=”low”>Low:</div>
<!– the inputs –>
<input type=”text” aria-labelledby=”temperature low”>
<input type=”text” aria-labelledby=”temperature high”>
Enfin, un attribut « placeholder » peut être utilisé pour donner un nom accessible aux entrées de texte. Cette solution n’est pas recommandée car l’étiquette visuelle (le texte de remplacement) sera supprimée une fois que l’utilisateur aura saisi le texte dans l’entrée, ce qui l’empêchera de savoir à quoi sert l’entrée.
<input type=”text” placeholder=”Search”>
Mauvais exemple de code :
First name: <input type=”text” name=”fname”>
Cas de test
Pour plus d’exemples, visitez la bibliothèque des règles ATC du W3C sur GitHub.
