Développer des formulaires accessibles

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.

Cela correspond aux critères 11.1, 11.2 et 11.3 du RGAA.

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

Source : Using Style Guides for Accessibility, Webdesign.tutsplus.com

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>.

Cela correspond aux critères 11.5, 11.6, 11.7 du RGAA

<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