Pourquoi un visiteur qui utilise un gestionnaire de mots de passe ou une aide à la saisie doit-il retaper son adresse e-mail à la main sur un formulaire de contact, alors que son navigateur connaît déjà cette information ? La réponse tient souvent à un seul attribut HTML oublié : autocomplete.
Ce tutoriel s’adresse à un développeur de thème qui personnalise un formulaire de contact WordPress, qu’il soit généré par un plugin ou codé à la main dans un template. Il couvre l’ajout des valeurs autocomplete pertinentes, exigées par le critère 11.13 du RGAA 4.1, sans entrer dans la validation côté serveur des champs, qui relève d’un sujet distinct.
Ce que dit le critère RGAA 11.13
Le référentiel général d’amélioration de l’accessibilité, dans sa version 4.1, formule ainsi le critère 11.13 : « Dans chaque formulaire, le remplissage automatique des champs de même nature est-il facilité, chaque fois que c’est possible ? ». Ce critère reprend l’esprit du critère de succès WCAG 1.3.5, « Identifier la finalité de la saisie », qui demande que la finalité d’un champ de formulaire lié aux informations de l’utilisateur puisse être déterminée par programmation.
Concrètement, le RGAA attend qu’un champ dont la finalité figure dans la liste normalisée de la spécification HTML — nom, e-mail, téléphone, adresse postale, entre autres — porte l’attribut autocomplete avec la valeur correspondante. Un formulaire de contact classique en comporte souvent trois ou quatre : nom, e-mail, téléphone, message.
Le formulaire tel qu’il existe avant correction
Voici le balisage de départ, un formulaire de contact simple codé directement dans le template page-contact.php d’un thème sur mesure :
<form method="post" action="/contact/traiter/">
<label for="nom">Nom</label>
<input type="text" id="nom" name="nom">
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email">
<label for="telephone">Téléphone</label>
<input type="tel" id="telephone" name="telephone">
<label for="message">Message</label>
<textarea id="message" name="message"></textarea>
<button type="submit">Envoyer</button>
</form>
Le typage des champs est correct — type="email", type="tel" — mais aucun attribut autocomplete n’apparaît. Le navigateur peut deviner certaines finalités grâce au nom du champ, mais rien ne le garantit, en particulier pour les technologies d’assistance qui s’appuient sur cet attribut pour proposer une saisie vocale ou simplifiée.
Étape 1 : identifier la finalité normalisée de chaque champ
La spécification HTML autonomie complète une liste de jetons reconnus pour l’attribut autocomplete. Pour ce formulaire, les correspondances sont directes :
- Le champ « Nom » correspond au jeton
name. - Le champ « Adresse e-mail » correspond au jeton
email. - Le champ « Téléphone » correspond au jeton
tel. - Le champ « Message » n’a pas de finalité normalisée : il reste sans attribut
autocomplete, ou reçoit la valeuroffsi l’on souhaite explicitement décourager la suggestion automatique.
Étape 2 : ajouter les attributs au balisage
La correction consiste simplement à ajouter l’attribut sur chaque champ concerné :
<form method="post" action="/contact/traiter/">
<label for="nom">Nom</label>
<input type="text" id="nom" name="nom" autocomplete="name">
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">
<label for="telephone">Téléphone</label>
<input type="tel" id="telephone" name="telephone" autocomplete="tel">
<label for="message">Message</label>
<textarea id="message" name="message"></textarea>
<button type="submit">Envoyer</button>
</form>
Étape 3 : vérifier le résultat
La vérification se fait en deux temps. D’abord manuellement : remplir une première fois le champ e-mail dans le navigateur, recharger la page, puis constater que le navigateur propose désormais une suggestion de saisie automatique dès le premier caractère tapé. Ensuite avec un outil d’audit automatisé, qui signale généralement les champs sans autocomplete reconnu sous une règle liée au critère de succès 1.3.5 du WCAG.
Conseil maison : sur un formulaire multi-champs, mieux vaut vérifier la liste des jetons dans la documentation HTML plutôt que de deviner — certains, comme
street-addressoupostal-code, sont moins évidents quenameou
Pour aller plus loin
Le critère RGAA 11.13 s’applique à tout champ dont la finalité figure dans la liste normalisée, pas seulement aux formulaires de contact : un formulaire de commande, un formulaire d’inscription à une newsletter ou un champ d’adresse de livraison en bénéficient tout autant. Ajouter systématiquement l’attribut autocomplete dès la conception du template, plutôt qu’en correction a posteriori, évite d’avoir à repasser sur chaque formulaire du site un par un.
