Formulaires accessibles

C’est dans un formulaire qu’un visiteur devient client, abonné ou patient. C’est aussi là que beaucoup de sites perdent des gens sans s’en rendre compte. Un champ qui ne dit ce qu’il attend que jusqu’à ce qu’on commence à taper, une erreur signalée seulement par un contour rouge, une énigme impossible à résoudre : chacun de ces obstacles peut faire abandonner quelqu’un. Cet article passe en revue ce qui rend un formulaire facile pour tous, y compris pour les personnes qui utilisent un lecteur d’écran (un logiciel qui lit l’écran à voix haute), celles qui n’utilisent que le clavier et celles pour qui lire ou mémoriser est difficile. Vous y trouverez de courts exemples de code avant et après, pour votre développeur ou votre créateur de site par IA, ainsi que des listes de contrôle pour un formulaire de contact, une page de paiement et un formulaire d’inscription.

Pourquoi les formulaires posent si souvent problème

Les formulaires comptent parmi les points faibles les plus courants du web. Dans le WebAIM Million 2026, un contrôle automatique d’un million de pages d’accueil, 51 % des pages contenaient des champs de formulaire sans libellé. Et ce n’est que ce qu’une machine peut repérer sur une page d’accueil. Les étapes de paiement et d’inscription, où les enjeux sont plus importants, en contiennent souvent davantage.

La plupart des lois européennes sur l’accessibilité s’appuient sur les WCAG, les règles pour l’accessibilité des contenus web publiées par le W3C. En France, le RGAA les transpose en critères concrets. Plusieurs de ces exigences concernent les formulaires : les champs ont besoin d’un libellé ou d’instructions, les erreurs doivent être signalées en texte et des suggestions de correction doivent être proposées. Le tutoriel du W3C sur les formulaires les détaille. Voici la version pratique.

Chaque champ a un libellé visible

Un libellé est le texte qui dit à quoi sert un champ : « Adresse e-mail », « Code postal », « Message ». Il doit rester visible en permanence, se trouver juste à côté du champ et lui être relié dans le code, pour qu’un lecteur d’écran l’annonce quand quelqu’un arrive dans le champ. Un libellé relié offre un bonus : un clic dessus place le curseur dans le champ, ce qui rend les petites cases à cocher bien plus faciles à atteindre.

L’erreur la plus fréquente consiste à utiliser le texte indicatif (le texte gris affiché dans le champ, appelé « placeholder ») comme seul libellé. Il disparaît dès qu’on tape, si bien qu’on ne peut plus vérifier ce qui était demandé ; il est souvent trop pâle pour être lu ; et certains lecteurs d’écran ne l’annoncent pas. Le Nielsen Norman Group recense ces problèmes dans son article sur les méfaits des placeholders.

<!-- Avant : l'indication disparaît à la saisie, et rien ne nomme le champ -->
<input type="email" placeholder="Adresse e-mail" />

<!-- Après : un libellé visible, relié au champ par for et id -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email" />

Si vous voulez montrer le format attendu, placez l’exemple dans un court texte d’aide sous le libellé (« Par exemple : 1000 Bruxelles »), pas seulement dans le placeholder. Notre guide de correction sur les libellés montre la solution pas à pas.

Regroupez les choix qui vont ensemble

Les boutons radio (des boutons ronds qui permettent de choisir une seule option) et les groupes de cases à cocher ont besoin de deux sortes de libellés : un pour chaque option et un pour la question dans son ensemble. Sans la question, une personne qui utilise un lecteur d’écran risque d’entendre seulement « Oui, bouton radio, 1 sur 2 », sans savoir à quoi elle dit oui.

Dans le code, le groupe est un fieldset et la question sa legend :

<!-- Avant : la question est un simple texte, sans lien avec les options -->
<p>Comment souhaitez-vous être contacté ?</p>
<input type="radio" id="c-mail" name="contact" /> <label for="c-mail">E-mail</label>
<input type="radio" id="c-tel" name="contact" /> <label for="c-tel">Téléphone</label>

<!-- Après : les options sont regroupées et la question nomme le groupe -->
<fieldset>
  <legend>Comment souhaitez-vous être contacté ?</legend>
  <input type="radio" id="c-mail" name="contact" /> <label for="c-mail">E-mail</label>
  <input type="radio" id="c-tel" name="contact" /> <label for="c-tel">Téléphone</label>
</fieldset>

Il en va de même pour une date répartie en trois champs (jour, mois, année) ou pour un bloc d’adresse.

Champs obligatoires et instructions

Indiquez dès le départ quels champs doivent être remplis. Deux façons de faire fonctionnent bien :

Écrivez « (obligatoire) » dans le libellé de chaque champ obligatoire. C’est le plus clair.
Ou utilisez un astérisque (_) et expliquez-le une fois en haut du formulaire : « Les champs marqués d’un _ sont obligatoires. »

Ne comptez pas sur la couleur seule, comme des libellés rouges pour les champs obligatoires : les personnes qui distinguent mal les couleurs passeront à côté. Dans le code, ajoutez l’attribut required pour que les lecteurs d’écran annoncent aussi « obligatoire ».

Gardez les instructions courtes et placez-les avant le champ qu’elles concernent, pas après le bouton d’envoi. Une règle de mot de passe comme « Au moins 12 caractères » a sa place sous le libellé du mot de passe, là où on la voit avant de taper.

Ne demandez que ce dont vous avez vraiment besoin. Chaque champ en plus est une occasion de plus d’abandonner. Et n’obligez pas les gens à saisir deux fois la même information dans un même parcours : les WCAG 2.2 ont ajouté l’exigence Redundant Entry (saisie redondante), qui demande que les informations déjà fournies soient préremplies ou proposées au choix. La case « Adresse de facturation identique à l’adresse de livraison » en est l’exemple classique.

Des messages d’erreur qui aident à corriger

Tout le monde se trompe en remplissant un formulaire. L’important est de pouvoir corriger vite. Un bon message d’erreur :

Est écrit en toutes lettres, pas seulement signalé par un contour rouge ou une icône. Les personnes qui distinguent mal certaines couleurs peuvent manquer un contour rouge, et les lecteurs d’écran n’annoncent pas du tout les couleurs.
Se trouve à côté du champ concerné, pour qu’on le trouve, et lui est relié dans le code, pour qu’il soit lu quand on revient au champ.
Explique comment corriger, pas seulement qu’il y a un problème. « Saisissez une adresse e-mail au format nom@exemple.fr » aide ; « Saisie invalide » non.
Conserve ce qui a déjà été saisi. Vider tout le formulaire après une seule erreur pousse à partir.

Pour les longs formulaires, ajoutez après l’envoi un court récapitulatif en haut de page qui liste chaque erreur sous forme de lien vers le champ concerné, et placez le focus clavier (l’endroit où va la saisie) sur ce récapitulatif. Le GOV.UK Design System du gouvernement britannique en montre une version éprouvée.

<!-- Avant : seulement un contour rouge, rien qu'un lecteur d'écran puisse annoncer -->
<input type="email" id="email" class="contour-rouge" />

<!-- Après : un message en texte, relié au champ -->
<label for="email">Adresse e-mail</label>
<p id="email-erreur" class="erreur">Saisissez une adresse e-mail au format nom@exemple.fr</p>
<input
  type="email"
  id="email"
  name="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-erreur"
/>

aria-describedby relie le message au champ, et aria-invalid signale aux technologies d’assistance que le champ demande une correction.

Laissez le navigateur remplir ce qu’il connaît

Les navigateurs et les gestionnaires de mots de passe peuvent remplir automatiquement votre nom, votre adresse, votre e-mail et votre numéro de téléphone, à condition que le formulaire indique ce qu’est chaque champ. Tout le monde y gagne du temps, et cela change beaucoup pour les personnes ayant un handicap moteur, des troubles de la mémoire ou une dyslexie. Les WCAG appellent cela Identify Input Purpose, identifier la finalité des champs.

C’est l’attribut autocomplete qui s’en charge. Valeurs courantes :

name, ou given-name et family-name pour des champs prénom et nom séparés
email et tel
street-address, postal-code, address-level2 (la commune ou la ville) et country-name
organization pour le nom d’une entreprise
new-password à l’inscription et current-password à la connexion
one-time-code pour un code reçu par SMS

Utilisez aussi le bon type de champ : type="email" et type="tel" affichent le clavier adapté sur téléphone.

Boutons, clavier et vérifications de sécurité

Des boutons qui disent ce qu’ils font

Le bouton d’envoi doit être un vrai bouton avec un texte clair : « Envoyer le message », « Valider la commande », « Créer un compte ». Pas un simple « Valider », et jamais une flèche sans nom. Si un bouton n’affiche qu’une icône, il lui faut un nom masqué que le lecteur d’écran pourra annoncer.

<!-- Avant : une zone cliquable avec une icône, sans nom ni accès au clavier -->
<div class="envoyer" onclick="envoyer()"><svg>...</svg></div>

<!-- Après : un vrai bouton avec un nom -->
<button type="submit">Envoyer le message</button>

Notre guide de correction sur les noms de boutons traite aussi des boutons à icône.

Tout fonctionne au clavier

Une personne qui n’utilise que le clavier doit pouvoir atteindre chaque champ avec Tab, choisir les options avec les flèches ou la barre d’espace, ouvrir les listes déroulantes personnalisées et envoyer avec Entrée. Méfiez-vous des sélecteurs de date, des listes déroulantes faites maison et des zones où l’on glisse un fichier : elles ne fonctionnent souvent qu’à la souris. Notre test au clavier en dix minutes explique comment le vérifier vous-même.

Les CAPTCHA et leurs alternatives

Un CAPTCHA est un test censé prouver que vous n’êtes pas un robot : recopier des lettres déformées ou cliquer sur des photos. Pour beaucoup de gens, c’est un mur. Le W3C décrit ces problèmes dans sa note sur l’inaccessibilité des CAPTCHA. Les WCAG 2.2 ont aussi ajouté Accessible Authentication (authentification accessible) : se connecter ne doit pas dépendre de la mémorisation ou de la recopie d’informations, sauf si une aide existe, comme l’acceptation des gestionnaires de mots de passe et du copier-coller.

Il existe des moyens plus doux d’arrêter le spam : des vérifications invisibles qui tournent en arrière-plan, un champ caché que seuls les robots remplissent, ou une limite au nombre de messages par visiteur. Si un test visible est inévitable, proposez-en plusieurs sortes, par exemple une version audio à côté de la version visuelle. Et n’empêchez jamais le collage dans les champs de mot de passe ou de code.

Les limites de temps

Si un formulaire expire, les personnes qui lisent ou tapent lentement risquent de perdre leur travail. L’exigence Timing Adjustable (réglage du délai) demande que l’on puisse désactiver ou prolonger une limite de temps. Une façon courante de faire : un avertissement avant la fin du délai, avec au moins 20 secondes pour le prolonger par une action simple. La vente de billets et les enchères peuvent faire exception.

La confirmation

Après l’envoi, affichez un message clair à l’écran et assurez-vous que les lecteurs d’écran l’annoncent aussi, par exemple en y déplaçant le focus. Pour les commandes, les réservations et tout ce qui a des conséquences juridiques ou financières, laissez les gens relire leurs réponses avant l’étape finale, et dites ce qui va se passer : « Merci. Nous avons envoyé une confirmation à nom@exemple.fr. »

Listes de contrôle pour les formulaires courants

Formulaire de contact

Chaque champ a un libellé visible qui reste affiché pendant la saisie.
Les champs obligatoires sont signalés en texte, pas seulement par la couleur.
Les champs nom, e-mail et téléphone ont la bonne valeur autocomplete.
Les erreurs apparaissent en texte à côté du champ et expliquent quoi faire.
Le bouton indique « Envoyer le message » ou une formule équivalente.
La protection contre le spam ne demande pas de résoudre une énigme visuelle.
Une confirmation s’affiche après l’envoi et elle est annoncée.

Paiement

Les champs d’adresse utilisent autocomplete, et « Identique à l’adresse de livraison » évite de tout retaper.
Les choix de livraison et de paiement sont regroupés sous une question claire.
Les erreurs dans les champs de carte ou d’adresse sont expliquées avec des mots.
On peut relire la commande avant de payer.
Le dernier bouton indique « Payer » ou « Valider la commande », pas « Suivant ».
Une éventuelle limite de temps peut être prolongée.
La page de confirmation dit ce qui a été commandé et ce qui va se passer.

Inscription et connexion

Les champs e-mail et mot de passe ont des libellés visibles et les bonnes valeurs autocomplete.
Les règles du mot de passe sont affichées avant la saisie.
Le collage et les gestionnaires de mots de passe fonctionnent.
Les codes reçus par SMS ou par e-mail peuvent être collés.
Le bouton qui affiche le mot de passe est un vrai bouton avec un nom.
Les messages d’erreur disent ce qui ne va pas sans révéler quels comptes existent.

Ce qu’ibin peut contrôler dans vos formulaires, et ce qu’il ne peut pas

Un contrôle automatique trouve les champs sans libellé, les boutons sans nom et les textes trop peu contrastés. ibin montre chaque problème avec un gros plan de l’endroit concerné et un guide de correction, et le bouton « Copier les instructions pour un outil d’IA » vous donne une consigne prête à l’emploi pour Lovable, Bolt, v0 et les outils similaires. Les contrôles automatiques ne trouvent toutefois qu’environ un tiers à la moitié des problèmes d’accessibilité. Un message d’erreur est-il utile, les étapes sont-elles logiques, un CAPTCHA bloque-t-il des gens : il faut une personne pour en juger. Remplissez votre propre formulaire uniquement au clavier, faites exprès une erreur et observez ce qui se passe.

Vérifiez vos formulaires

Contrôlez gratuitement votre page de contact ou de paiement avec ibin pour trouver les libellés manquants et les boutons sans nom. Parcourez ensuite les listes de contrôle ci-dessus et les guides de correction. En vous connectant, vous pouvez contrôler jusqu’à 200 pages du même site, et les contrôles hebdomadaires vous préviennent quand une modification d’un formulaire casse quelque chose.

Voyez où en est votre site

Vérifiez gratuitement une page, sans compte. Vous recevez une liste claire de ce qu’il faut corriger en premier, avec des images de l’endroit où se trouve chaque problème.

Formulaires accessibles : des libellés, des erreurs et des boutons qui marchent pour tous