On trouve des formulaires sur tous les sites et applications. Ils sont très utilisés, mais souvent mal conçus et implémentés. L’accessibilité n’est pas prise en compte dans le développement des formulaires alors qu’ils sont essentiels dans le parcours de navigation. Nous allons voir comment développer des formulaires accessibles.
Vous trouverez dans cet article :
- Label des champs
- Boutons
- Fieldset
- Liste de choix
- Aide à la saisie et messages d’erreur
- Champs obligatoires
- Données sensibles et modifications
- Identifier la nature des champs de formulaires
- CAPTCHA
- Utiliser le formulaire au clavier
- Tester le formulaire avec un lecteur d’écran
Label des champs
Chaque champ de formulaire doit avoir un label visible et pertinent. Pour associer un label à son champ, utilisez la balise <label>
avec l’attribut for
correspondant à l’id
du champ.
Par exemple :
<label for="name">Nom :</label> <input id="name" type="text"> <input type="checkbox" name="subscribe" id="subscribe"> <label for="subscribe">S’inscrire à la newsletter</label>
Avoir un label pertinent associé au champ permet aux technologies d’assistance de restituer correctement l’information. L’utilisateur comprend la saisie qui est attendue dans le champ.
Les labels doivent également être visuellement accolés, c’est-à-dire que le label et son champ sont à proximité immédiate. Ainsi, l’utilisateur n’aura pas de difficulté pour comprendre et remplir le champ.
Cela correspond au critère 11.4 du RGAA
Dans le cas d’un champ de recherche, un bouton “Rechercher” accolé au champ suffit pour lui attribuer un label pertinent.
L’attribut title
permet de renseigner un label sur un champ de recherche comme sur le site Légifrance. Ceci génère une étiquette visible au survol du champ.
Le nom accessible est déterminé par la méthode d’implémentation du label. Il est utilisé par les technologies d’assistance. Pour modifier le nom accessible, ajouter aria-label
ou aria-labelledby
.
<label for="name">Nom</label> <input id="name" type="text" aria-label="Veuillez saisir votre nom" /> <p id=”description”>Saisissez votre nom</p> <input aria-labelledby=”description” type="text" id="name">
Veillez à ce que le contenu du nom visible soit repris dans le nom accessible.
Boutons
Cela correspond au critère 11.9 du RGAA
Pour nommer un bouton, plusieurs méthodes existent en fonction du type de bouton :
- contenu texte entre la balise
<button>
- attribut
alt
pour les boutons type image value
title
aria-label
aria-labelledby
Exemples d’implémentations :
<button>Valider</button> <input type="image" alt="Valider" /> <input type="submit" value="Valider" /> <input type="submit" title="Valider" /> <p id="id-valid">Valider</p> <input type="button" aria-labelledby="id-valid" /> <input type="button" aria-label="Valider" />
L’intitulé de chaque bouton doit être suffisamment explicite : l’utilisateur doit comprendre sans ambiguïté l’action qu’il y a derrière le bouton.
Fieldset
Les champs de même nature doivent être regroupés à l’aide de la balise <fieldset>
. En effet, la sémantique est aussi importante dans un formulaire. Par exemple, les champs pour saisir une date de naissance ou une adresse postale doivent être dans une balise <fieldset>
.
<fieldset> <legend>Langages de programmation</legend> <input type="radio" name="language" value="html" id="html"> <label for="html">HTML</label> <input type="radio" name="language" value="css" id="css"> <label for="css">CSS</label> <input type="radio" name="language" value="javascript" id="javascript"> <label for="javascript">Javascript</label> </fieldset>
Le contenu de la balise <legend>
ne doit pas être trop long, car les lecteurs d’écran peuvent répéter ce qu’il y a dans la balise <legend>
avec l’intitulé de chaque champ.
Liste de choix
Il peut être nécessaire de regrouper les options d’une liste avec la balise <optgroup>
. Ceci permet une meilleure lisibilité du contenu.
Cela correspond au critère 11.8 du RGAA
<select> <optgroup label="Fruits"> <option>Pomme</option> <option>Fraise</option> … </optgroup> <optgroup label="Légumes"> <option>Courgette</option> <option>Carotte</option> … </optgroup> </select>
Aide à la saisie et messages d’erreur
Si un champ nécessite un format de valeur attendue, alors il faut en informer explicitement l’utilisateur. Prenons l’exemple d’un champ date de naissance :
<label for="birthday">Date de naissance :</label> <input id="birthday" type="text">
Le format de saisie attendu est jj/mm/aaaa. Il faut l’indiquer de manière visible avant de soumettre le formulaire.
<label for="birthday">Date de naissance (Format jj/mm/aaaa) :</label> <input id="birthday" type="text">
Cela correspond au critère 11.10 du RGAA
L’utilisation du placeholder seul n’est pas une implémentation conforme. En effet, le placeholder disparaît à la prise de focus sur le champ. Par conséquent, l’utilisateur ne sait pas quel est le format attendu.
Pour corriger cela, il y a plusieurs solutions :
- ajouter sur le champ un attribut
title
identique au contenu du placeholder - ajouter un texte visible à proximité du champ associé par l’attribut
aria-describedby
Les messages d’erreurs indiquent un exemple réel de saisie, afin d’aider l’utilisateur à comprendre le format de donnée attendue.
Cela correspond au critère 11.11 du RGAA
Exemple conforme sur laposte.fr :
Champs obligatoires
Les champs obligatoires d’un formulaire doivent être visiblement identifiés. Plusieurs méthodes existent :
- un texte informatif avant le formulaire : “tous les champs sont obligatoires”
- mention d’un astérisque avant le formulaire : “* : champs obligatoires”
- mention dans le nom visible et le nom accessible de chaque champ : “Nom (obligatoire) : “
Cela correspond au critère 11.10 du RGAA
Si le formulaire ne comporte qu’un seul champ, ces méthodes ne s’appliquent pas.
Les attributs required
et aria-required
n’informent que les utilisateurs aveugles, il faut également un texte visible pour identifier les champs obligatoires.
Données sensibles et modifications
Cela correspond au critère 11.12 du RGAA
Dans le cas de formulaires modifiant ou supprimant des données personnelles, financières ou juridiques :
- L’utilisateur a la possibilité de récupérer ses données via un historique ou une fonctionnalité de restauration
- Ou une demande de confirmation explicite de la modification ou suppression est proposée (par exemple une modale de confirmation)
Dans le cas de formulaires modifiant ou supprimant des données, transmettant des réponses à un test ou un examen, ou dont la validation a des conséquences financières ou juridiques :
- L’utilisateur peut modifier ou annuler les données et les actions effectuées sur ces données après la validation
- Ou l’utilisateur peut vérifier et corriger les données avant la validation
- Ou un mécanisme de confirmation explicite (case à cocher, étape supplémentaire) est présent.
Identifier la nature des champs de formulaires
Cela correspond au critère 11.13 du RGAA
Lorsqu’un formulaire collecte des informations personnelles sur l’utilisateur, le type de chaque champ est déterminé avec l’attribut autocomplete
.
Ceci permet au navigateur de remplir automatiquement les champs avec les valeurs attendues. Par exemple, le nom, prénom, adresse, numéro de téléphone sont des données qui peuvent être saisies automatiquement grâce à l’autocomplete.
Liste des valeurs autorisées pour l’attribut autocomplete.
L’autocomplete permet :
- de faire gagner du temps à l’utilisateur en accélérant la saisie
- limiter les fautes de frappe et erreurs de saisie
- de venir en aide aux personnes ayant des difficultés motrices
CAPTCHA
Le système de CAPTCHA est une fonctionnalité de sécurité permettant de différencier les robots des humains et ainsi rejeter la soumission du formulaire qui serait réalisée par un ordinateur.
Le CAPTCHA pose malheureusement beaucoup de difficultés d’accessibilité. En effet, qu’il soit visuel, audio ou textuel, le CAPTCHA va inévitablement bloquer certains utilisateurs aveugles, handicapés moteur, mentaux ou cognitifs.
L’alternative qui peut être proposée au CAPTCHA est d’envoyer le code par email ou sms. L’utilisateur peut ainsi valider le formulaire en renseignant le code reçu ou en cliquant sur un lien par exemple.
Utiliser le formulaire au clavier
Assurez-vous que le formulaire que vous développez est fonctionnel uniquement en utilisant le clavier. En effet, les personnes qui n’utilisent pas la souris, par exemple, doivent pouvoir remplir le formulaire à l’aide du clavier. La prise de focus doit être visible sur chacun des champs du formulaire.
Tester le formulaire avec un lecteur d’écran
Utilisez les technologies d’assistance NVDA ou VoiceOver par exemple, pour remplir le formulaire et assurez-vous que celui-ci soit fonctionnel et compréhensible.
Afin de développer des formulaires accessibles, le RGAA (Référentiel général d’amélioration de l’accessibilité) vous permet de vérifier que chacun des critères de la thématique 11 sur les formulaires soient respectés.
Vous avez maintenant toutes les informations pour rendre vos formulaires accessibles !
Sources
- Labels visibles et noms accessibles – Concevoir des formulaires accessibles
- Grouping Controls
- Creating Accessible Forms
- Using Style Guides for Accessibility
- General good form example
- A beginner’s complete guide to form accessibility
- Les CAPTCHAs et l’accessibilité
- Changer de fournisseur de téléphone : une démarche accessible… Ou presque ! – Access42
- 8 conseils pour rendre votre contenu accessible
- Image de vector4stock sur Freepik