form-design

Conception de formulaires

Un formulaire est une conversation dans laquelle l'organisation demande quelque chose et la personne paie en temps, en effort et en risque. Il fonctionne lorsque chaque question a sa place, chaque réponse peut être donnée dans les termes de la personne, et chaque erreur est détectée tôt, expliquée sur place et corrigeable sans perdre de travail. L'échec de modèle le plus courant est un formulaire qui semble fini et ne l'est pas : étiquettes dans les espaces réservés, champs obligatoires inventés, type="number" pour les numéros de carte, pas d'autocomplete, erreurs uniquement sous forme de bulles du navigateur ou de bordures rouges, un bouton d'envoi qui dit "Envoyer" et un chemin de réussite qui était le seul chemin testé.

Appliquez les principes hiérarchisés de interface-guidelines (tout le monde peut l'utiliser > ça dit la vérité > ça veut dire ce que ça dit > la réponse vient en premier > les erreurs sont réparables > ça reste en place > le possible est visible > la convention > le polissage). Si cette compétence est installée, lisez d'abord son SKILL.md. Sa section 3 de references/human-interface.md contient les règles de base pour les formulaires (étiquettes visibles, marquage facultatif, collage, moment de validation, bouton d'envoi désactivé, comportement de sauvegarde) ; cette compétence va plus loin et ne les répète pas.

Brief

Répondez à ces questions avant de dessiner un champ. Notez-les si le formulaire comporte plus de cinq questions.

• À quoi sert chaque réponse ? Nommez la décision ou l'action qui l'utilise. Un champ sans utilisation nommée est supprimé.
• Qui répond, à quelle fréquence, sur quel appareil ? Un candidat unique dans sa vie sur un téléphone, ou un employé saisissant 200 enregistrements par jour à un bureau. Cela décide une chose par page contre une page dense.
• À qui appartiennent les données ? À la personne elle-même (l'autofill s'applique, WCAG 1.3.5 s'applique) ou à quelqu'un d'autre (un destinataire, un patient, un client saisi par le personnel).
• La personne a-t-elle la réponse sous la main ? Numéro de passeport, identifiant de police, revenu de l'année dernière. Si non, dites à l'avance ce qu'il faut rassembler et autorisez la sauvegarde.
• Combien coûte une mauvaise réponse, et qu'est-ce qui est irréversible une fois soumis (paiement, déclaration légale, publication publique) ?
• Où se trouvent les répondants ? Pays, écritures, formats d'adresse, formats de téléphone, structures de noms.
• Que peut déjà savoir le système ? Ne le demandez jamais (WCAG 3.3.7).
• Lecteur agent : un agent remplira-t-il cela pour quelqu'un (extensions d'autofill, agents navigateurs, assistants) ? Supposez oui pour tout ce qui est public.

Règles

Demander moins

• Coupez les champs avant de les concevoir. Chaque champ doit avoir une utilisation nommée maintenant, pas "pourrait être utile". Baymard constate que le panier moyen comporte 11,3 champs là où 8 suffisent ; le nombre de champs nuit plus que le nombre d'étapes. [P: Baymard 2024]
• Collectez le nom complet en un seul champ sauf si les parties déclenchent un comportement spécifique (tri, adresse formelle). De nombreux noms ne se divisent pas en prénom et nom de famille. Ne demandez jamais un nom de famille obligatoire. [S: W3C i18n ; P: Baymard]
• Cachez les champs rarement utilisés derrière un lien, pas une entrée obligatoire : ligne d'adresse 2, entreprise, code promo. [P: Baymard]
• Par défaut, l'adresse de facturation est celle de livraison avec une case cochée qui masque les champs de facturation. [P: Baymard]
• Proposez la création de compte après la transaction, pas comme un obstacle avant. [P: Baymard]
• Autorisez "Je ne sais pas" là où c'est une réponse valide, plutôt que de forcer une supposition. [S: Pages de questions GOV.UK]
• Dérivez ce que vous pouvez : ville et région à partir du code postal là où c'est fiable, type de carte à partir du numéro, pays à partir de la recherche d'adresse. Gardez les valeurs dérivées visibles et modifiables. [P: Baymard]

Structure et flux

• Choisissez la forme à partir du brief, pas par habitude. Tâches rares, stressantes ou inconnues : une question par page, avec la question en h1/legend. Saisie experte fréquente : une page, regroupée, rapide au clavier. GOV.UK commence chaque service par une chose par page et ne fusionne que lorsque la recherche le dit. [S: Structure de formulaire GOV.UK]
• Ordonnez les questions comme la personne y pense, les plus faciles et les plus certaines en premier, et créez des branches pour que personne ne voie une question qui ne peut pas s'appliquer. [S: GOV.UK ; J]
• Dites ce dont la personne aura besoin avant de commencer (documents, temps, coût) et ce qui se passe après. [S: Pages de démarrage GOV.UK]
• Les formulaires longs en plusieurs sessions reçoivent une liste de tâches avec des statuts simples et une sauvegarde et un retour. Utilisez-en un seulement lorsque les gens ne peuvent pas terminer en une seule séance ou doivent choisir leur propre ordre. [S: Liste de tâches GOV.UK]
• Le bouton Retour fonctionne. Incluez un lien Retour sur les pages de questions et ne cassez jamais le bouton Retour du navigateur ; le retour montre les réponses précédentes préremplies. [S: GOV.UK]
• Terminez les flux conséquents par une page de vérification des réponses : chaque réponse avec un lien Modifier dont le nom accessible nomme le champ ("Modifier la date de naissance"), revenant au résumé après la modification. [S: GOV.UK vérifier les réponses ; WCAG 3.3.4]
• Les dispositions multi-colonnes brisent l'ordre de lecture pour les personnes et les agents. Une colonne, à l'exception des champs courts naturellement appariés (mois et année d'expiration, ville et code postal). [P: Baymard ; Wroblewski ; J]

Étiquettes, indices et regroupement

• Étiquette au-dessus du champ. L'avantage de vitesse rapporté par Penzo 2006 provient d'un petit test de suivi oculaire informel et a été contredit par Das 2008 ; choisissez des étiquettes en haut car elles survivent aux écrans étroits, aux longues traductions et au zoom, pas parce qu'elles sont les plus rapides prouvées. [E, faible : Penzo 2006, Das 2008]
• Les indices vont entre l'étiquette et le champ et sont liés avec aria-describedby. Les exemples de format ("Par exemple, 27 3 2007") appartiennent à l'indice, jamais à l'espace réservé. [S: GOV.UK]
• Regroupez les contrôles associés avec fieldset et legend : chaque ensemble de boutons radio, chaque ensemble de cases à cocher et chaque réponse en plusieurs parties (date, expiration de carte). La légende est la question. [S: WCAG 1.3.1 ; GOV.UK]
• Sur une page à une question, l'étiquette ou la légende est le titre de la page afin que les lecteurs d'écran l'entendent une fois. [S: Pages de questions GOV.UK]
• Marquez les champs facultatifs avec "(facultatif)" et n'utilisez pas d'astérisques pour les obligatoires. Si la plupart des champs sont facultatifs, demandez-vous s'ils sont nécessaires. [S: GOV.UK]

Types de saisie et autofill

• Définissez autocomplete sur chaque champ concernant la personne, avec le jeton exact WHATWG (given-name, email, postal-code, cc-number, one-time-code, new-password). Cela alimente l'autofill du navigateur, les gestionnaires de mots de passe et le remplissage par agent, et c'est une exigence WCAG 1.3.5. autocomplete="off" sur des données personnelles est un défaut. [S: WHATWG autofill ; WCAG 1.3.5]
• Utilisez type pour le sens et inputmode pour le clavier. type="email", type="tel", type="url" là où ils s'appliquent. Les identifiants composés de chiffres (carte, code postal, compte, code) sont de type="text" inputmode="numeric", jamais type="number", ce qui supprime les zéros non significatifs, change au défilement, arrondit les longues valeurs et confond les logiciels de dictée. [S: GOV.UK 2020 ; MDN]
• Contrôles natifs en premier. select pour une liste fermée d'environ une douzaine d'options, des boutons radio pour quelques options que les gens doivent comparer, une boîte combo avec saisie semi-automatique pour les longues listes comme les pays. Les menus déroulants personnalisés cachent leurs options aux agents. [S: APG ; P: sonde dans interface-guidelines]
• Les dates mémorables sont trois champs de texte (jour, mois, année) avec des jetons bday-* pour les dates de naissance, acceptant les noms de mois. Les sélecteurs de date conviennent uniquement aux dates que les gens choisissent par rapport à un calendrier. [S: Saisie de date GOV.UK]
• Dimensionnez le champ à la réponse attendue. Une boîte de code postal aussi large qu'une boîte de rue induit en erreur. [S: GOV.UK ; J]
• Acceptez les réponses dans le format de la personne : espaces et tirets dans les numéros de carte et de téléphone, toute casse dans les codes postaux, noms de mois, espaces en début ou fin. Normalisez sur le serveur. [S: GOV.UK]
• Les modèles champ par champ (noms, adresses par pays, téléphone, argent, cartes, fichiers) se trouvent dans references/fields.md.

Validation et erreurs

• Validez à l'envoi par défaut ; en ligne seulement après que la personne a quitté un champ qu'elle a terminé, et effacez une erreur dès qu'elle est corrigée. Ne signalez jamais à la première frappe. Les preuves sont contradictoires : Bargas-Avila 2007 a constaté que les erreurs listées après la fin étaient meilleures que les erreurs immédiates ; Wroblewski 2009 a constaté que la validation en ligne au flou aidait (n=22). GOV.UK valide à l'envoi ; Baymard recommande au flou et supprime les erreurs à la correction. Décidez en fonction de la longueur du formulaire et de la vérifiabilité du champ seul. [E: Bargas-Avila 2007 ; E, faible : Wroblewski 2009 ; S: GOV.UK ; P: Baymard]
• Lors d'un échec d'envoi : conservez chaque réponse, placez un résumé des erreurs en haut avec un lien par problème vers son champ, déplacez le focus vers le résumé, préfixez le titre de la page avec "Erreur : ", et affichez le même libellé à côté de chaque champ. [S: Résumé d'erreur GOV.UK ; WCAG 3.3.1]
• Lie chaque message à son champ avec aria-describedby (ajoutez aria-errormessage si vous le souhaitez ; sa prise en charge par les lecteurs d'écran est encore inégale) et définissez aria-invalid="true". Le message doit être un texte visible : les sérialiseurs d'agent suppriment aria-invalid mais conservent le texte adjacent. [S: WCAG 3.3.1 ; P: Roselli 2023 ; P: sonde dans interface-guidelines]
• Désactivez les bulles de validation du navigateur (novalidate) et affichez les messages dans la page. Les bulles disparaissent, ne peuvent pas être liées à partir d'un résumé et ne sont pas du texte de la page. La validation côté serveur reste faisant autorité. [S: Validation GOV.UK]
• Écrivez des erreurs qui disent comment les corriger, spécifiques à la cause : "Entrez une date de naissance dans le passé", pas "Date invalide". Un message par cause (vide, mauvais format, hors plage), dans les mots du formulaire. [S: Message d'erreur GOV.UK ; WCAG 3.3.3]
• Une condition que la personne ne peut pas corriger en modifiant (inéligible, compte verrouillé, service indisponible) est une page avec la raison et la prochaine étape, pas une erreur de champ. [S: GOV.UK]

Connexion, mots de passe, clés d'accès

• Laissez les gestionnaires de mots de passe et le collage fonctionner. autocomplete="username" et current-password ou new-password ; ne bloquez jamais le collage ; pas de maxlength inférieur à 64 ; proposez Afficher le mot de passe ; supprimez le champ de confirmation du mot de passe lorsque Afficher est proposé. [S: NIST SP 800-63B-4 3.1.1.2 ; Saisie de mot de passe GOV.UK ; WCAG 3.3.8]
• Pas de règles de composition, pas d'expiration périodique, pas d'indices. Vérifiez les nouveaux mots de passe par rapport aux listes de fuites connues et dites pourquoi un a été refusé. [S: NIST SP 800-63B-4]
• Proposez les clés d'accès sans forcer un choix au préalable : conservez le champ de nom d'utilisateur, ajoutez autocomplete="username webauthn" et une demande WebAuthn conditionnelle, puis proposez la création de clé d'accès après une connexion par mot de passe. [S: WHATWG autofill ; P: web.dev passkey autofill]
• Codes à usage unique : un champ, autocomplete="one-time-code", inputmode="numeric", collage accepté. Les boîtes à un seul chiffre qui rejettent un code collé violent WCAG 3.3.8. [S: WCAG 3.3.8]
• Ne dites pas si c'est le nom d'utilisateur ou le mot de passe qui était faux. [S: Mots de passe GOV.UK]
• Ne bloquez pas la connexion par un CAPTCHA de puzzle. Les puzzles de texte et de logique violent WCAG 3.3.8 sans alternative non cognitive. [S: WCAG 3.3.8]

Envoi

• Le bouton d'envoi nomme le résultat : "Créer un compte", "Payer 42,00 €", "Envoyer la demande". "Continuer" entre les étapes ; "Enregistrer et continuer" seulement si cela a été enregistré. [S: Bouton GOV.UK ; base]
• Les soumissions légales, financières et de suppression de données sont réversibles, vérifiées ou confirmées avec une étape de vérification (WCAG 3.3.4). La vérification montre exactement ce qui sera envoyé et ce que cela coûte. [S: WCAG 3.3.4]
• L'envoi est idempotent : désactivez la ressaise pendant l'exécution, montrez la progression sur le bouton et protégez sur le serveur avec une clé d'idempotence. Une nouvelle tentative après un délai d'attente ne doit pas débiter deux fois. [S: Bouton GOV.UK ; P: Idempotence Stripe]
• La page de confirmation indique ce qui s'est passé, un numéro de référence et la suite, et survit à un rechargement. Un toast n'est pas un reçu. [S: Pages de confirmation GOV.UK ; base]

Pour le lecteur agent

• Chaque contrôle a un nom programmatique qui correspond à son étiquette visible, et ses choix sont énumérables (select natif, boutons radios visibles). [J]
• Les contraintes sont un texte visible avant la soumission (format, longueur, valeurs autorisées), pas seulement dans un attribut pattern. [J]
• Les erreurs sont un texte à côté du champ et dans un résumé, stables jusqu'à ce qu'elles soient corrigées. [J]
• L'URL ou le titre de chaque étape indique où se trouve l'agent dans le flux ; les chemins Retour et Modifier existent. [J]
• Le texte écrit par des personnes extérieures (prérempli à partir d'un e-mail, une note de référence) est affiché comme des données citées, jamais comme une étiquette ou une instruction. [J]
• Les soumissions conséquentes conservent l'autorité sur le serveur : une page de vérification des réponses aide les personnes ; elle n'arrête pas un agent qui clique à travers. [J]

Ordre de construction

1. Listez les questions avec l'utilisation de chaque réponse ; supprimez celles sans.
2. Choisissez la forme : une page, une chose par page ou une liste de tâches. Esquissez les branchements.
3. Rédigez le texte : questions, indices, chaque message d'erreur par cause, libellés des boutons, confirmation.
4. Construisez avec des éléments natifs : label for, fieldset/legend, type correct, inputmode, autocomplete, novalidate.
5. Validation côté serveur et envoi idempotent, puis validation côté client en utilisant les mêmes messages.
6. État d'erreur : résumé, focus, préfixe de titre, messages en ligne, saisie conservée.
7. Pages de vérification des réponses et de confirmation ; sauvegarde et retour si multi-session.
8. Le style en dernier ; la marque possède l'apparence (brand-identity).

Vérifier

• node <form-design>/scripts/form-check.mjs <url|file|dist> --try-submit contre une version locale ou de test. Il vérifie les noms et les étiquettes visibles, la validité et l'objectif de l'autocomplete, les types de saisie, le collage, les boutons radios natifs masqués, les légendes de groupe, le câblage des erreurs, le focus après un échec d'envoi et le libellé d'envoi. Les erreurs renvoient 1. --try-submit soumet vraiment : ne le pointez jamais vers la production.
• node <interface-guidelines>/scripts/audit.mjs <url|dist> pour l'audit général rendu (contraste, cibles, clavier, redimensionnement, stabilité de l'agent).
• Remplissez-le avec un gestionnaire de mots de passe et l'autofill du navigateur sur un profil réel : chaque champ personnel se remplit et rien n'atterrit dans la mauvaise boîte.
• Remplissez-le uniquement au clavier et à 320 px avec un texte à 200 %.
• Remplissez-le en tant qu'agent à partir uniquement de l'instantané d'accessibilité : trouvez chaque champ par son nom, lisez chaque choix, soumettez une erreur, lisez les erreurs, corrigez-les, terminez.
• Mauvaises données : un nom d'un mot, un nom de 60 caractères avec une apostrophe et des accents, une adresse au Japon et une en Irlande sans code postal, un numéro de carte collé avec des espaces, un double-clic sur Envoyer, un délai de session expiré au milieu du flux.

Pièges

• Espace réservé comme étiquette, ou une étiquette flottante qui rétrécit dans la bordure et échoue au contraste.
• type="number" pour les cartes, téléphones, codes postaux ou codes.
• autocomplete="off"

…