Chapitre 9.4 — Autocomplete & saisie

⏱️ TL;DR — Le formulaire le plus accessible est celui qui demande le moins d’effort. Quatre leviers : l’attribut autocomplete (1.3.5) sur les champs d’identité, pour que le navigateur remplisse nom, e-mail et adresse ; les bons type et inputmode, qui adaptent le clavier mobile et la validation ; l’absence de saisie redondante (3.3.7), c’est-à-dire ne pas redemander une info déjà donnée dans le même parcours ; et une authentification accessible (3.3.8) qui n’impose aucun test cognitif (recopier un captcha illisible, mémoriser un code) sans alternative.

🎯 Objectifs

• Renseigner autocomplete sur les champs d’identité pour activer le remplissage automatique.
• Choisir le bon type et le bon inputmode selon la donnée attendue.
• Éviter de redemander une information déjà saisie dans le même parcours.
• Concevoir une authentification sans test cognitif obligatoire.

autocomplete : laisser le navigateur remplir

L’attribut autocomplete indique au navigateur la nature d’un champ (prénom, e-mail, adresse, code postal…). Le navigateur — ou un gestionnaire de mots de passe — peut alors le remplir automatiquement avec les données de l’utilisateur.

Le bénéfice est pour tout le monde, mais il est décisif pour les personnes avec un handicap moteur (moins de frappe, moins de fatigue) ou cognitif (moins de mémorisation, moins de risque d’erreur). Recopier son adresse complète à la main est un obstacle réel ; le remplissage automatique le supprime.

<!-- ✅ Champs d'identité avec autocomplete : remplissage automatique possible -->
<label for="prenom">Prénom</label>
<input id="prenom" name="prenom" type="text" autocomplete="given-name" />
 
<label for="nom">Nom</label>
<input id="nom" name="nom" type="text" autocomplete="family-name" />
 
<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email" autocomplete="email" />
 
<label for="tel">Téléphone</label>
<input id="tel" name="tel" type="tel" autocomplete="tel" />

Les valeurs sont normalisées (given-name, family-name, email, tel, street-address, postal-code, country, new-password, current-password…) : utilise le vocabulaire standard, pas des valeurs inventées, sinon le navigateur ne sait pas quoi faire.

📚 Aller plus loin — C’est le critère 1.3.5 Identifier la finalité de la saisie (niveau AA) : la finalité des champs qui collectent des informations sur l’utilisateur doit pouvoir être déterminée par programme, via les valeurs standard d’autocomplete. Le vocabulaire complet est défini dans la spécification HTML.

type et inputmode : le bon clavier, la bonne validation

Le type d’un <input> fait beaucoup de travail gratuitement : type="email" valide grossièrement le format et, sur mobile, affiche un clavier avec @ ; type="tel" fait apparaître un pavé numérique ; type="url", type="date", etc.

Quand le type ne suffit pas (ex. un code postal reste du texte mais on veut un pavé numérique), inputmode ajuste le clavier mobile sans changer la sémantique du champ :

<!-- Code postal : reste du texte, mais clavier numérique sur mobile -->
<label for="cp">Code postal</label>
<input id="cp" name="cp" type="text" inputmode="numeric" autocomplete="postal-code" />
 
<!-- Montant : clavier numérique avec séparateur décimal -->
<label for="montant">Montant</label>
<input id="montant" name="montant" type="text" inputmode="decimal" />

Valeurs utiles d’inputmode : numeric (chiffres seuls), decimal (avec virgule), tel, email, url, search. Le bon clavier, c’est moins de bascules et moins d’erreurs de saisie — un gain pour la motricité comme pour la charge cognitive.

💡 Réflexe — Pour chaque champ, pose-toi trois questions dans l’ordre : « quel type natif correspond ? », « ce champ concerne-t-il l’identité de l’utilisateur → quel autocomplete ? », « sur mobile, quel clavier je veux → besoin d’un inputmode ? ». Trois attributs, souvent, transforment une saisie pénible en saisie fluide — sans une ligne de JavaScript.

Éviter la saisie redondante

Redemander une information que l’utilisateur a déjà fournie dans le même parcours est une charge inutile, particulièrement lourde en cas de handicap moteur ou cognitif. Typiquement : le tunnel de commande qui redemande l’adresse de facturation alors qu’elle est identique à la livraison.

Les bonnes pratiques :

• Pré-remplir ou réutiliser l’information déjà saisie plus tôt dans le processus.
• Offrir une case « identique à… » (adresse de facturation = adresse de livraison) plutôt que de faire ressaisir.
• Ne pas exiger de recopier une donnée déjà présente (retaper son e-mail « pour confirmer » est à éviter ; si tu y tiens, autorise le collage).

📚 Aller plus loin — C’est le critère 3.3.7 Saisie redondante (niveau A, ajouté en WCAG 2.2) : une information déjà saisie par l’utilisateur au cours d’un même processus est soit pré-remplie, soit disponible à la sélection — sauf exceptions (ressaisie essentielle, sécurité, information devenue invalide).

Authentification accessible : pas de test cognitif imposé

Se connecter ne devrait pas exiger de résoudre une énigme mentale. Or beaucoup de mécanismes d’authentification imposent un test de fonction cognitive : mémoriser un mot de passe complexe, recopier un captcha déformé, transcrire un code reçu, résoudre un puzzle. Pour les personnes dyslexiques, avec troubles de la mémoire ou de l’attention, c’est un mur.

Le principe : un moyen de s’authentifier sans test cognitif obligatoire doit exister. Concrètement :

• Autoriser le collage et le remplissage automatique dans les champs de connexion et de mot de passe (ne bloque jamais le collage sur un champ mot de passe).
• Accepter les gestionnaires de mots de passe : c’est justement ce qui dispense de mémoriser.
• Si tu utilises un captcha, fournir une alternative (ne pas imposer de recopier un texte illisible) ou préférer des mécanismes qui ne demandent aucune reconnaissance d’objet ni transcription.
• Un code envoyé par e-mail ou SMS que l’on peut coller reste acceptable ; l’imposer en le recopiant de mémoire, non.

<!-- ✅ Connexion : autocomplete adéquat, collage autorisé (aucun bloqueur JS) -->
<label for="login-email">Adresse e-mail</label>
<input id="login-email" name="email" type="email" autocomplete="email" />
 
<label for="login-pwd">Mot de passe</label>
<input id="login-pwd" name="password" type="password" autocomplete="current-password" />

⚠️ Piège — Bloquer le collage (onpaste désactivé) sur le champ mot de passe « pour la sécurité ». Ça n’améliore pas la sécurité — ça empêche l’usage d’un gestionnaire de mots de passe et force la mémorisation ou la recopie caractère par caractère, c’est-à-dire exactement le test cognitif qu’on doit éviter. Laisse toujours le collage possible.

📚 Aller plus loin — Le critère 3.3.8 Authentification accessible (minimum) (niveau AA, WCAG 2.2) exige qu’aucun test de fonction cognitive (mémoriser, transcrire) ne soit requis pour une étape d’authentification, sauf s’il existe une alternative, un mécanisme d’assistance, ou s’il s’agit de reconnaître des objets ou du contenu fourni par l’utilisateur.

🧭 Sur A11yLearn — L’inscription d’A11yLearn cumulait deux fautes : un champ « Confirmez votre e-mail » qui faisait retaper l’adresse (saisie redondante), et un captcha « recopiez ces lettres déformées » sans alternative (test cognitif). On a supprimé le champ de confirmation — un autocomplete="email" et la relecture du champ suffisent — et remplacé le captcha par une protection anti-spam invisible, sans transcription. Bonus : on a ajouté autocomplete sur tous les champs d’identité et autocomplete="new-password" sur le mot de passe, pour que les gestionnaires proposent d’en générer et retenir un. Inscription plus rapide pour tout le monde, franchissable pour les personnes concernées.

✏️ Exercices

Exercice 1 — Ajoute les bons attributs. Ce bloc d’identité n’a aucun attribut d’aide à la saisie. Complète-le.

<label for="p">Prénom</label>
<input id="p" name="p" type="text" />
 
<label for="cp">Code postal</label>
<input id="cp" name="cp" type="text" />

<label for="p">Prénom</label>
<input id="p" name="p" type="text" autocomplete="given-name" />
 
<label for="cp">Code postal</label>
<input id="cp" name="cp" type="text" inputmode="numeric" autocomplete="postal-code" />

Exercice 2 — Repère les fautes. Un tunnel de paiement (a) redemande l’adresse de facturation identique à la livraison, (b) impose de recopier un captcha déformé, (c) bloque le collage du mot de passe. Quels critères WCAG 2.2 sont concernés et comment corriger ?

🧠 Quiz de révision

Chapitre suivant : Atelier : un formulaire de A à Z — on applique tout, de la version inaccessible à la version corrigée.