Accessibilité des formulaires avec le RGAA
Les critères du référentiel général d'amélioration de l'accessibilité
Les formulaires font partie des 13 grands thèmes abordés par le référentiel général d’amélioration de l’accessibilité version 4.1.2.
Vous devez respecter des critères très stricts pour que vos formulaires soient notamment accessibles à plusieurs types de publics en situation de handicap :
- Personnes malvoyantes utilisant une technologie d’assistance telle qu’un lecteur d’écran ;
- Internautes qui naviguent au clavier, utilisent un contacteur, un logiciel de commande vocale ou un autre système de pointage ;
- Utilisateurs avec des difficultés de compréhension de l’information, des troubles de la mémoire ou de la concentration ;
- Personnes malentendantes (en cas de captcha audio).
1. Les étiquettes des champs de formulaire
L’étiquette est le nom donné au texte proche du champ de formulaire, et qui permet d’en comprendre la nature et la finalité.
Chaque champ doit avoir une étiquette associée, visible et pertinente. Son nom doit être accessible aux technologies d’assistance.
Les noms accessibles d’une étiquette
Vous pouvez utiliser plusieurs solutions techniques pour donner un nom accessible à une étiquette de champ. Voici vos options, par ordre de priorité :
- Un
aria-labelledbyqui fait référence à un id ; - Un
aria-label; - Une balise
<label>avec une relationfor/id; - Un attribut
title; - Un bouton adjacent au champ associé à un élément
<label>visuellement caché ou l’un des attributs WAI-ARIA mentionnés au-dessus.
L’attribut title devient une description accessible si vous avez également renseigné l’une des autres options : il est lu à la suite du nom accessible.
Note : un placeholder n’est pas un nom accessible.
Voici des exemples de noms accessibles pour des étiquettes de champ de formulaire.
Avec aria-labelledby :
<p id="identite-label">Votre nom complet :</p>
<input type="text" aria-labelledby="identite-label" />
Avec aria-label :
<input type="search" aria-label="Rechercher sur le site" />
Avec la balise <label> :
<label for="email-user">Adresse électronique :</label>
<input type="email" id="email-user" name="email" />
Avec l’attribut title :
<input type="text" title="Saisissez votre code postal" />
N’oubliez pas les relations programmatiques. Par exemple, la balise <label> sans attribut for est non conforme au RGAA.
Une étiquette pertinente doit permettre de comprendre la fonction exacte du champ de formulaire qui lui est associé.
Gardez tout d’abord en tête que votre nom accessible doit forcément reprendre l’intitulé visible lorsque celui-ci est présent.
Évitez également les intitulés trop génériques, qui manquent de précision et peuvent induire en erreur. Prenons l’exemple d’un formulaire de candidature avec un champ sur les prétentions salariales :
- Rémunération souhaitée : non conforme car trop générique ;
- Rémunération souhaitée en euros HT : conforme, car apportant une précision importante.
Certains champs de formulaire remplissent une fonction identique, qu’ils soient répétés au sein d’une même page ou repris sur un ensemble de pages :
- La confirmation d’une adresse email ou d’un mot de passe ;
- La présence d’un moteur de recherche interne en tête de âge ;
- Etc.
Vous devez vous assurer que les intitulés visibles ainsi que les liens accessibles ne prêtent pas à confusion.
Cas conforme :
- Champ 1 : “Votre adresse e-mail” ;
- Champ 2 : “Confirmez votre adresse e-mail”.
La cohérence est respectée : l’utilisateur sait qu’il doit saisir la même information deux fois.
Cas non conforme :
- Champ 1 : “Votre adresse e-mail” ;
- Champ 2 : “Confirmez votre identifiant”.
Le changement de dénomination crée une confusion potentielle, qui peut gêner une personne souffrant de troubles cognitifs.
2. Les boutons des formulaires
Nous pouvons distinguer deux types de boutons :
- Les boutons destinés à fournir une étiquette à un champ, utilisés notamment lorsque le formulaire contient un seul champ ;
- Les boutons de validation d’un formulaire, qui exécutent l’action finale.
Plusieurs solutions techniques permettent de nommer un bouton, classées par ordre de priorité :
aria-labelledby="[id_texte]"(tous les boutons) ;aria-label="Intitulé du bouton"(tous les boutons) ;- Le texte de la balise
<button>; alt="Intitulé du bouton"(<input type=”image”>) ;value="Intitulé du bouton"(<input>) ;title="Intitulé du bouton"(tous les boutons).
Des noms pertinents pour vos boutons
Vous devez remplir deux conditions pour que le nom de votre bouton soit pertinent :
- L’intitulé de votre bouton doit reprendre le nom accessible afin qu’il puisse être exécuté par une commande vocale ;
- L’intitulé ne doit pas être trop générique et doit expliciter l’action attendue lors du clic.
Exemple de code conforme :
<input type="text" aria-label="Rechercher sur le site">
<button type="submit">Rechercher</button>
Le nom accessible reprendre l’intitulé du bouton et est explicite, car l’utilisateur comprend qu’il s’agit d’un champ de recherche.
Exemples de code non conforme :
<input type="text" title="Recherche">
<button type="submit">OK</button>
Dans ce second exemple, le bouton est trop générique. Il prend en plus le pas sur le title, plus pertinent, mais qui du coup ne sera pas le nom accessible.
<input type="text" aria-label="Trouver un site web">
<button type="submit">Rechercher</button>
Cette fois-ci, le nom accessible est explicite. La non-conformité vient du fait que ce nom accessible ne reprend pas l’intitulé du bouton.
Plusieurs méthodes permettent d’utiliser un bouton comme étiquette de champ :
1. Une balise <label> visuellement cachée
Vous utilisez une classe CSS (souvent appelée .sr-only ou .visually-hidden) pour masquer l’étiquette tout en la laissant vocalisable par les lecteurs d’écran.
<label for="search-input" class="sr-only">Rechercher sur le site</label>
<input type="text" id="search-input">
<button type="submit">Rechercher</button>
2. Avec l’attribut aria-labelledby
L’identifiant (id) du bouton est récupéré pour servir comme étiquette pour le champ.
<input type="text" aria-labelledby="btn-search">
<button type="submit" id="btn-search">Rechercher</button>
3. Un attribut aria-label
Le nom accessible repose sur l’attribut ARIA sur le champ, qui contient l’intitulé du bouton.
<input type="text" aria-label="Rechercher sur le site">
<button type="submit">Rechercher</button>
4. L’attribut title
Ce n’est généralement pas la solution privilégiée, mais elle est acceptée par le RGAA si le titre est explicite.
<input type="text" title="Rechercher sur le site">
<button type="submit">Rechercher</button>
Astuces et tutoriels sur l'accessibilité Web
3. Le regroupement des champs de même nature
Les champs de même nature partagent des informations pouvant être traitées comme des ensembles cohérents :
- Trois champs successifs pour une date (un pour le jour, un pour le mois et un pour l’année) ;
- Cinq champs successifs de deux chiffres pour un numéro de téléphone ;
- Un bloc destiné à saisir l’adresse d’expédition, et un second bloc destiné à saisir l’adresse de facturation (si différente) ;
- Un ensemble de boutons radio ou de cases à cocher pour répondre à une question ;
- Etc.
Les champs de même nature au sein d’un formulaire doivent être regroupés :
- Soit par une balise
<fieldset> - Soit par une balise avec un attribut WAI-ARIA
role="group"
Les champs de même nature de type radio (<input type="radio"> ou attribut WAI-ARIA role="radio" sont également regroupés dans une balise avec un attribut WAI-ARIA role="radiogroup" ou role="group".
Ils doivent également posséder une légende accessible et pertinente pour une conformité avec le RGAA.
Le critère 11.6 prévoit une légende en cas de regroupement de champs de même nature.
La réponse technique dépend du mode de regroupement :
- Élément
<fieldset>: il vous suffit d’ajouter un élément<legend>; - Attribut
role="group"ourole="radiogroup": vous utilisez un un attribut WAI-ARIAaria-labelouaria-labelledby.
Vous n’êtes cependant pas obligé d’utiliser les balises <legend> ou les attributs role="group" et role="radiogroup". Vous devez alors vérifier que l’étiquette de chaque champ de même nature (aria-labelledby, aria-describedby, aria-label ou title) fait référence à son appartenance au regroupement. Par exemple :
- Date de naissance : jour de naissance
- Date de naissance : mois de naissance
- Date de naissance : année de naissance
Cette solution alternative ne vous dispense pas d’un élément <fieldset> , d’un attribut role="group" et role="radiogroup". Ils sont en effet nécessaires pour répondre au critère 11.5.
La balise <optgroup> permet de regrouper plusieurs options dans une liste de choix lorsque les réponses sont rangées en plusieurs thématiques (11.8).
<select>
<optgroup label="Métiers du digital">
<option>Référenceur</option>
<option>Auditeur RGAA</option>
<option>...</option>
</optgroup>
<optgroup label="Métiers du commerce">
<option>Vendeur</option>
<option>Chef de rayon</option>
<option>...</option>
</optgroup>
</select>
N’oubliez pas l’attribut label="" pour nommer le regroupement !
4. La présentation visuelle des formulaires
Les étiquettes de champs visibles doivent être accolées à leur champ associé, immédiatement au-dessus ou à gauche de celui-ci (à droite pour les langues ou le sens de lecture est inversé).
Pour les étiquettes associées à des champs de type type checkbox ou radio ou à une balise avec un attribut role="checkbox", role="radio ou role="switch", l’étiquette visible de chaque bouton est accolée immédiatement au-dessous ou à droite du champ (à gauche pour un langue où le sens de lecture inversé).
Ce critère (11.4) permet aux personnes souffrant d’un déficit cognitif de bien comprendre le formulaire.
Vous devez vous assurer que les champs restent accolés pour toutes les tailles d’écran. Un utilisateur en situation de handicap sur smartphone ou tablette doit également avoir des étiquettes accolées aux champs.
5. Les indications et contrôles de saisie
Les critères d’accessibilité des formulaires concernent également les contrôles de saisie :
- Champs obligatoires
- Instructions et indications sur les formats attendus
- Messages d’erreur
- Etc.
Ces critères (11.10 et 11.11) sont importants pour les personnes présentant des difficultés de compréhension et les personnes utilisant des technologies d’assistance.
Vous devez indiquer de façon explicite le caractère obligatoire d’un champ avant la validation du formulaire :
- Soit de façon visuelle,
- avec un astérisque (pensez à donner la signification de l’astérisque en début de formulaire, avec une mention du type “Les champs accompagnés d’un astérisque sont obligatoires”) ;
- avec une phrase en début de formulaire, de type “Tous les champs sont obligatoires ;
- Soit en utilisant un attribut
aria-required="true"ouaria-required="required".
Dans le second cas, vous devez également avoir une indication de champ obligatoire visible, située dans l’étiquette associée ou dans le passage de texte associé.
Les champs qui demandent un type de données ou un format obligatoire doivent être accompagnés d’instructions claires, données avant la validation du formulaire, soit :
- En nommant le champ concerné pour faciliter son identification ;
- En mettant l’instruction dans l’étiquette ou le passage de texte associé.
Pensez à être le plus précis possible, en donnant bien le format.
La mise en conformité des messages d’erreur est importante.
Vous devez tout d’abord vous assurer que chaque message d’erreur peut facilement être associé au champ concerné :
- Soit en nommant de façon explicite le champ concerné ;
- Soit en utilisant un attribut
aria-invalid="true", avec en plus un message visible à l’écran, dans l’étiquette ou le passage de texte associé au champ.
En cas d’erreur de saisie sur un champ qui demande un format ou un type de données particulier, le message d’erreur doit donner un exemple concret. Par exemple, en cas d’erreur sur une adresse mail, donnez une illustration de type “Format attendu : nom@domaine.com, par exemple benjamin@gmail.com”.
Note : dans le cas d’un formulaire long, je vous conseille d’ajouter un récapitulatif des erreurs en début de formulaire.