Le laissez-passer A-38 — Partie 1 : Poser la bonne question
Table des matières
Poser les bonnes questions
Tu te souviens de la maison qui rend fou dans Les Douze Travaux d'Astérix ? Astérix doit obtenir le laissez-passer A-38. Chaque guichet le renvoie ailleurs. Les formulaires n'ont pas d'intitulé. Chaque guichet lui dit quel formulaire il faut, mais l'envoie ailleurs pour l'obtenir. Il tourne en rond dans un labyrinthe de couloirs, de "files d'attente" et de renvois sans fin.
Remplace les guichets par des champs de saisie, les fonctionnaires par des messages d'erreur, les couloirs par un ordre de tabulation incohérent, et le laissez-passer A-38 par un bouton "Valider". Tu viens de décrire l'expérience de millions d'utilisateurs face aux formulaires du web.
Un formulaire, c'est une conversation. Chaque champ pose une question, chaque validation écoute la réponse, chaque message d'erreur guide vers la bonne. Quand cette conversation est cassée, questions muettes, réponses ignorées, corrections incompréhensibles, l'utilisateur tourne en rond. Exactement comme Astérix.
Ce premier article pose les fondations : comment poser les bonnes questions. Le suivant s'occupera d'écouter les réponses.
Le coût du silence
Les formulaires sont le dernier obstacle avant la conversion. Inscription, achat, contact, candidature. à chaque fois, un formulaire. Et à chaque fois, des utilisateurs qui abandonnent.
Selon le rapport WebAIM Million 2026, 33,1% des champs de formulaire sur le web ne sont pas correctement labellisés. Un tiers. Le Baymard Institute mesure un taux d'abandon de panier mondial de 70,19%, agrégé sur 49 études, suivi depuis 14 ans. 18% de ces abandons sont dus à un processus trop long ou trop compliqué, et le checkout moyen contient 23 éléments de formulaire quand l'idéal est 12. Corriger ces problèmes d'usabilité peut augmenter les conversions de 35%.
En Europe, une étude de la fondation ContentSquare sur le e-commerce en 2025 va dans le même sens : les formulaires affichent un taux d'échec moyen de 68%, faute de labels, d'autocomplétion et d'indication d'erreurs.
Ce n'est pas un problème d'accessibilité isolé. C'est un problème de design qui touche tout le monde. Et qui coûte de l'argent à chaque visite. Les utilisateurs de technologies d'assistance sont les premiers impactés, mais un formulaire mal conçu frustre aussi l'utilisateur mobile qui se bat avec un clavier inadapté, l'utilisateur pressé qui ne comprend pas ce qu'on lui demande, et l'utilisateur prudent qui abandonne au premier message d'erreur incompréhensible.
Le label est la question
Un champ de formulaire sans label, c'est un guichet sans pancarte. Le champ est là, le curseur clignote, mais personne ne dit ce qu'il attend.
Le <label> fait trois choses à la fois :
- Il dit à la technologie d'assistance ce que le champ attend. Sans label, le lecteur d'écran annonce juste "champ de saisie, vide"
- Il agrandit la zone de clic. Cliquer sur le texte du label active le champ, ce qui aide les utilisateurs avec des difficultés motrices
- Il reste visible pendant la saisie, contrairement au
placeholder
Ce dernier point est crucial. Le placeholder n'est pas un label :
<!-- Ne fais pas ça -->
<input type="email" placeholder="Adresse email">
<!-- Fais ça -->
<label for="email">Adresse email</label>
<input id="email" type="email" placeholder="ex: nom@domaine.fr">Le placeholder disparaît dès que l'utilisateur commence à taper. Si c'est ta seule indication, l'utilisateur ne sait plus ce qu'on lui demandait après le premier caractère. Et pour les lecteurs d'écran, le placeholder n'est pas annoncé de manière fiable. Son support varie selon les combinaisons navigateur/technologie d'assistance.
L'association <label> + <input> se fait par l'attribut for qui pointe vers l'id du champ. C'est un lien explicite, vérifiable, et que chaque technologie d'assistance comprend sans ambiguïté.
Guider avant la saisie
Le label dit quoi. Les attributs du champ disent comment.
Le bon type de champ
<input type="text"> <!-- générique — pas d'aide clavier -->
<input type="email"> <!-- touche @ sur le clavier mobile -->
<input type="tel"> <!-- pavé numérique, sémantique téléphone -->
<input type="url"> <!-- touche .com, touche / sur mobile -->
<input type="number"> <!-- quantités uniquement, pas de zéros initiaux -->
<input type="search"> <!-- style recherche, bouton effacer -->Chaque type adapte le clavier sur mobile et informe le lecteur d'écran du format attendu ; certains (email, url, number) activent en plus une validation native. Utiliser type="text" partout, c'est obliger l'utilisateur à taper une adresse email sur un clavier qui ne propose ni le @ ni le .com.
Attention à type="number" : il ajoute un stepper (flèches haut/bas) et supprime les zéros en début de valeur. Il convient aux quantités (nombre d'articles, nombre de participants), pas aux identifiants numériques (code postal, numéro de téléphone, carte bancaire). Et type="tel" a une sémantique de numéro de téléphone. Le lecteur d'écran l'annonce comme tel. Ne l'utilise pas comme raccourci pour obtenir un clavier numérique.
Le bon clavier sur mobile
Quand type ne suffit pas, inputmode prend le relais :
<!-- Un code postal : saisie numérique -->
<input type="text" inputmode="numeric" pattern="[0-9]*">inputmode contrôle le clavier affiché sur mobile sans changer la sémantique du champ. C'est la solution propre pour les codes postaux, les codes de vérification, les numéros de sécurité sociale. Des champs numériques qui ne sont ni des quantités ni des numéros de téléphone.
Le navigateur sait déjà
L'attribut autocomplete est probablement le plus sous-utilisé du HTML. Il dit au navigateur quel type de donnée le champ attend, et le navigateur le remplit automatiquement si l'utilisateur l'a déjà saisi ailleurs.
<label for="name">Nom complet</label>
<input id="name" type="text" autocomplete="name">
<label for="email">Adresse email</label>
<input id="email" type="email" autocomplete="email">
<label for="tel">Téléphone</label>
<input id="tel" type="tel" autocomplete="tel">
<label for="address">Adresse</label>
<input id="address" type="text" autocomplete="street-address">Sur mobile, ça transforme un formulaire de 2 minutes en 10 secondes de validation. Pour les utilisateurs avec des difficultés motrices, c'est la différence entre un formulaire remplissable et un formulaire abandonné.
La liste complète des valeurs autocomplete couvre le nom, l'email, le téléphone, l'adresse, la carte bancaire, la date de naissance, et bien plus.
Grouper pour clarifier
Quand un formulaire dépasse 3-4 champs, la structure devient aussi importante que les labels individuels. C'est le rôle de <fieldset> et <legend>. Grouper les champs liés et donner un titre au groupe.
<fieldset>
<legend>Adresse de livraison</legend>
<label for="street">Rue</label>
<input id="street" type="text" autocomplete="shipping street-address">
<label for="city">Ville</label>
<input id="city" type="text" autocomplete="shipping address-level2">
<label for="zip">Code postal</label>
<input id="zip" type="text" inputmode="numeric" autocomplete="shipping postal-code">
</fieldset>
<fieldset>
<legend>Adresse de facturation</legend>
<!-- mêmes champs, préfixe autocomplete différent : billing -->
</fieldset>Sans <fieldset>, un lecteur d'écran annonce "Rue, champ de saisie", mais l'utilisateur ne sait pas si c'est la rue de livraison ou de facturation. Avec <fieldset> et <legend>, il annonce "Adresse de livraison, Rue, champ de saisie." Le contexte est immédiat.
Et la légende doit être pertinente. "Informations" ne dit rien. "Adresse de livraison" dit tout. Une légende vague, c'est un panneau indicateur qui pointe dans toutes les directions.
Le label, lui, doit être visuellement accolé à son champ — au-dessus ou à gauche en lecture occidentale. Un label à l'autre bout de la ligne, ou séparé par un élément décoratif, c'est une devinette pour tout le monde. Et pour un utilisateur qui zoome à 200%, la distance se multiplie.
Le même principe s'applique aux groupes de boutons radio et de cases à cocher :
<fieldset>
<legend>Mode de livraison</legend>
<label>
<input type="radio" name="shipping" value="standard">
Standard (3-5 jours)
</label>
<label>
<input type="radio" name="shipping" value="express">
Express (24h)
</label>
</fieldset>Sans le <fieldset>, le lecteur d'écran annonce "Standard 3-5 jours, bouton radio". L'utilisateur ne sait pas quel mode il choisit. Avec le <fieldset>, il annonce "Mode de livraison, Standard 3-5 jours, bouton radio." Une phrase, tout le contexte.
Pour les listes de choix longues, <optgroup> fait le même travail que <fieldset> pour les champs : il structure les options en groupes nommés.
<label for="country">Pays</label>
<select id="country" autocomplete="country">
<optgroup label="Europe">
<option value="FR">France</option>
<option value="DE">Allemagne</option>
<option value="ES">Espagne</option>
</optgroup>
<optgroup label="Amérique du Nord">
<option value="US">États-Unis</option>
<option value="CA">Canada</option>
</optgroup>
</select>Le lecteur d'écran annonce "Europe, France" au lieu de laisser l'utilisateur deviner dans un menu de 50 pays sans repères. Sans <optgroup>, une liste longue est une soupe linéaire, exactement le même problème que les soupes de div.
Les critères d'ensemble
Le RGAA encadre les formulaires à travers de nombreux critères. Pour cette première partie :
- Critère 11.1 — chaque champ a-t-il une étiquette ?
- Critère 11.2 — l'étiquette est-elle pertinente ?
- Critère 11.4 — chaque étiquette est-elle visuellement accolée au champ qu'elle décrit ?
- Critère 11.5 — les champs de même nature sont-ils regroupés ?
- Critère 11.6 — chaque regroupement a-t-il une légende ?
- Critère 11.7 — chaque légende de regroupement est-elle pertinente ?
- Critère 11.8 — chaque liste de choix est-elle structurée de manière pertinente ?
- Critère 11.13 — l'autocomplétion est-elle activée pour les données personnelles ?
La partie 2 couvrira les critères de validation, d'erreurs et de correction. La partie 3 couvrira les formulaires multi-étapes.