Lorsqu'il s'agit de remplir un formulaire en ligne, nous recherchons tous à peu près la même chose : des instructions claires, une procédure rapide et une expérience fluide.
Pour les personnes en situation de handicap, ce genre d'expérience positive n'est possible que si quelqu'un a pris la peine de rendre le formulaire accessible.
En tant qu'expert en accessibilité, lorsque je remplis un formulaire en ligne, je réfléchis toujours à l'expérience utilisateur. Les instructions étaient-elles faciles à suivre ? Le processus était-il clair et simple ? Une personne souffrant d'un handicap visuel ou moteur vivrait-elle la même expérience que moi ?
L'autre jour, j'ai essayé de remplir un formulaire sur un site de voyage. J'ai été impressionné par la qualité de l'expérience. Grâce à un outil d'accessibilité, j'ai pu remplir toutes les informations demandées sur ce site en moins de cinq minutes, sans aucune confusion ni erreur.
Savez-vous ce qui a permis d'y parvenir ?
En effet, ce formulaire comportait des libellés descriptifs cohérents et toujours présents. Il indiquait clairement tous les champs obligatoires, fournissait des instructions faciles à suivre, regroupait les champs pertinents de manière à définir clairement leur fonction et utilisait un nombre minimal de texte de remplacement donnant les indications nécessaires. Surtout, il communiquait le rôle, le nom et l'état des contrôles du formulaire à la technologie d'assistance que j'utilisais.
Dans cet article, nous allons découvrir quelques techniques permettant de créer ce type d'expériences accessibles. Mais avant de commencer, je vous recommande de lire deux de nos articles déjà publiés sur ce sujet :
- Anatomie des formulaires accessibles : le problème des valeurs par défaut
- Anatomie des formulaires accessibles : les champs obligatoires
Dans l'article d'aujourd'hui, nous allons passer en revue tous les éléments nécessaires à la création d'un formulaire accessible offrant la meilleure expérience utilisateur possible à tous les utilisateurs. Nous aborderons chaque aspect de la création d'un formulaire accessible, nous expliquerons pourquoi chaque étape est importante et nous verrons en quoi elle a un impact sur les personnes en situation de handicap ou sur les utilisateurs en général.
Utiliser du code HTML natif
La première règle pour créer un formulaire véritablement accessible consiste à utiliser autant que possible les contrôles de formulaire HTML natifs. La plupart d'entre eux sont accessibles par défaut avec toutes les technologies d'assistance et sont sémantiquement corrects.
Voyons quelques exemples d'éléments de formulaire natifs :
<input type=”text”> <input type=”radio”> <input type=”checkbox”> <button>Submit</button>
Comme nous utilisons les contrôles HTML natifs, le nom, le rôle et l'état des éléments sont communiqués par défaut à toutes les technologies d'assistance. En revanche, si nous créons un contrôle personnalisé à l'aide des techniques WAI-ARIA, tous ces éléments doivent être définis manuellement à l'aide de divers attributs ARIA tels que `aria-label`, `aria-checked` et `role="radio"`.
Apposer une étiquette bien visible
L'étape suivante consiste à attribuer des libellés visibles à chaque élément de formulaire. Sans ces libellés, les éléments de formulaire ne sont pas utilisables par les utilisateurs, et encore moins par les personnes en situation de handicap. Un libellé visible est simplement un texte situé à proximité immédiate de l'élément de formulaire qu'il désigne.
<strong>First Name</strong> <input type=”text”> <strong>Terms & Conditions</strong> <input type=”checkbox”>
Dans l'exemple de code ci-dessus, j'ai utilisé une balise « strong » pour mettre en évidence les libellés afin que les utilisateurs puissent les distinguer facilement.
Puisque nous parlons d'étiquettes visibles, nous devrions également aborder la question des attributs de remplacement.
Pour certains types de champs de saisie, on peut utiliser l'attribut « placeholder », mais cela ne revient pas à fournir une étiquette visible ! Le texte de l'attribut « placeholder » disparaît dès que l'utilisateur saisit des données dans le formulaire. Pour en savoir plus sur les pièges liés à l'utilisation des attributs « placeholder », vous pouvez consulter l'article « The Anatomy of Accessible Forms: The Problem with Placeholders ».
Inclure des étiquettes programmatiques
Maintenant que nous avons compris pourquoi il est nécessaire d'utiliser des libellés visibles, nous devons également les associer par programmation à leurs contrôles de formulaire. Sans cette association programmatique des libellés, les utilisateurs de technologies d'assistance ne peuvent pas identifier la fonction du champ du formulaire.
Lorsqu'un utilisateur place le curseur dans un champ de texte, celui-ci est lu comme « champ d'édition » sans que le nom d'accessibilité qui lui a été attribué ne soit annoncé. Pour garantir que le nom d'accessibilité visible soit bien annoncé aux utilisateurs, nous devons associer par programmation l'étiquette visible à un champ de formulaire.
<label for=”firstname”>First Name</label> <input type=”text” name=”firstname” id=”firstname”> <label for=”lastname”>Last Name</label> <input type=”text” name=”lastname” id=”lastname”>
Dans l'exemple ci-dessus, nous avons utilisé la méthode « for et id » pour associer le champ du formulaire à son libellé visible. Bien qu'il existe plusieurs façons de réaliser cette association par programmation, il est recommandé d'utiliser la méthode « id ».
Ajouter des étiquettes descriptives
Maintenant que nous avons ajouté des libellés visibles et que nous les avons associés à leurs champs de formulaire respectifs, l'étape suivante consiste à vérifier si ces libellés sont suffisamment explicites. L'utilisateur sera-t-il capable de lire le libellé, d'en comprendre l'objectif et d'effectuer l'action demandée avec succès ? Par exemple :
<label>Name</label> <input type=”text”> <input type=”text”>
Dans l'exemple ci-dessus, on constate que, pour les deux champs du formulaire, le libellé affiché est « nom ». Ce libellé n'est pas suffisamment descriptif pour permettre aux utilisateurs d'effectuer l'action requise. Chaque champ du formulaire doit comporter son propre libellé affiché, qui doit être descriptif. Nous pouvons améliorer l'exemple ci-dessus en ajoutant des libellés affichés pour les deux champs du formulaire et en précisant où il faut saisir le prénom et le nom :
<label for=”fname”>First Name</label> <input type=”text” name=”firstname” id=”fname”> <label for=”lname”>Last Name</label> <input type=”text” name=”lastname” id=”lname”>
Contrôles de formulaire groupés
Il arrive parfois qu'un ensemble de contrôles de formulaire appartienne à un groupe et soit accompagné d'une étiquette visible au niveau du groupe afin de fournir un contexte. Cette étiquette visible au niveau du groupe transmet les informations nécessaires aux utilisateurs pour qu'ils puissent effectuer une action. Voyons cela à l'aide d'un exemple :
<p>Do you have a passport</p> <input type=”radio” name=”passport” id=”yes”> <label for=”yes”>Yes</label> <input type=”radio” name=”passport” id=”no”> <label for=”no”>No</label>
Dans l'exemple ci-dessus, on constate que « Avez-vous un passeport ? » est l'étiquette visible principale au niveau du groupe pour l'ensemble des boutons radio. Cependant, lorsque les utilisateurs de technologies d'assistance accèdent à ces boutons radio, ils ne perçoivent pas l'information essentielle fournie par l'étiquette visible principale au niveau du groupe, car celle-ci ne reçoit pas le focus du clavier via la touche Tab.
De plus, les éléments « Oui » et « Non », lorsqu’ils sont lus isolément par une technologie d’assistance, n’ont aucun sens. Pour remédier à ce problème en HTML, nous utilisons les attributs `fieldset` et `legend` afin de regrouper les contrôles de formulaire au niveau du groupe. Ces attributs seront annoncés aux utilisateurs de technologies d’assistance comme prévu. Voici le même exemple avec les attributs `fieldset` et `legend` :
<fieldset> <legend>Do you have a passport</legend> <input type=”radio” name=”passport” id=”yes1”> <label for=”yes1”>Yes</label> <input type=radio” name=”passport” id=”no1”> <label for=”no1”>No</label> </fieldset>
Dans l'exemple ci-dessus, on constate que l'élément `fieldset` regroupe les contrôles du formulaire au sein d'un groupe et que l'attribut `legend` sert d'étiquette principale visible au niveau du groupe ; celle-ci s'affiche lorsque l'utilisateur d'une technologie d'assistance place le focus sur le premier bouton radio, que ce soit via la navigation par tabulation ou par la combinaison Maj+Tab.
Donner des instructions
Certains champs du formulaire nécessitent des instructions supplémentaires pour permettre de saisir correctement les données. Ces instructions doivent être accessibles aux utilisateurs à tout moment, sous forme d'étiquettes visibles. Nous pouvons associer ces instructions aux champs du formulaire à l'aide de l'attribut `aria-describedby`.
<label for=”dob”>Date of Birth</label> <input type=”text” aria-described=”dob1” id=”dob”> <span id=”dob1”>MM/DD/YYYY</span>
Dans l'exemple ci-dessus, l'instruction figure sous le champ du formulaire et est associée à ce dernier via l'attribut `aria-describedby`. Si l'instruction n'est pas associée aux champs du formulaire, les utilisateurs de technologies d'assistance qui naviguent à l'aide de la touche Tab risquent de passer à côté d'informations essentielles.
Identification de la finalité des champs de saisie d'un formulaire
La saisie précise d'informations dans les champs d'un formulaire peut s'avérer difficile, en particulier pour les personnes présentant des troubles cognitifs. L'objectif d'un champ de texte destiné à collecter des données spécifiques à l'utilisateur peut être identifié par programmation à l'aide de l'attribut HTML « autocomplete ». Cette technique peut également contribuer à personnaliser l'interface en remplaçant ou en complétant les libellés des champs du formulaire par des mots issus d'un vocabulaire défini, voire par des symboles graphiques.
<label for=”fname”>First Name</label> <input type=”text” name=”firstname” id=”fname”> autocomplete=”given-name”>
Dans l'exemple ci-dessus, l'attribut « autocomplete » du champ de saisie du formulaire aide l'agent utilisateur à se souvenir du prénom. Cela facilite le remplissage des formulaires et réduit le risque d'erreurs, en particulier pour les personnes qui peuvent avoir des difficultés à se souvenir, à lire ou à saisir correctement certaines informations.
Indiquer un nom accessible
Certains champs de formulaire peuvent nécessiter un nom programmatique afin de mieux comprendre leur fonction et d’effectuer des actions indépendamment des libellés textuels visibles. Cependant, il faut veiller à ce que ce nom programmatique ne remplace pas complètement le libellé textuel visible. Il doit venir compléter et améliorer l’expérience utilisateur, en particulier pour les utilisateurs de la saisie vocale qui tentent d’utiliser le libellé textuel visible comme moyen de navigation ou de sélection lorsqu’ils interagissent avec les champs de formulaire :
<label for=”bday”>Date of Birth (MM/DD/YYYY)</label> <input type=”text” aria-label=”Birthday” id=”bday”>
Dans l'exemple ci-dessus, non seulement l'utilisateur ne reçoit pas d'instructions importantes, mais il risque également de ne pas savoir quelle est la valeur à saisir dans ce champ de formulaire. Nous devons inclure le libellé visible dans le nom d'accessibilité, et il est recommandé de commencer par ce libellé visible.
<label for=”search”>Search</label> <input type=”text” aria-label=”Search by City, State or Zipcode” id=”search”>
Dans l'exemple ci-dessus, le nom d'accessibilité complète l'étiquette textuelle visible et aide les utilisateurs à mieux comprendre la fonction du champ du formulaire ainsi que les informations à saisir.
Résumé
En suivant les bonnes pratiques décrites ci-dessus, vous pourrez créer un formulaire convivial et accessible à tous les utilisateurs. Et n'oubliez pas : le HTML natif est la clé pour offrir une expérience utilisateur positive !
