La finalité d’un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l’utilisateur ?
Un utilisateur atteint de tremblements ou de troubles moteurs remplit un formulaire de commande. Saisir son adresse, son numéro de téléphone, ses coordonnées bancaires : chaque champ est un effort physique réel. Si son navigateur connaît déjà ces informations et peut les insérer automatiquement, pourquoi l’en empêcher ? L’attribut autocomplete est le signal qui rend cela possible.
Ce critère s’applique à tous les champs qui collectent des données personnelles de l’utilisateur : nom, prénom, adresse, téléphone, email, numéro de carte bancaire, date de naissance. Pour chaque champ concerné, trois conditions doivent être réunies : l’attribut autocomplete est présent, sa valeur appartient à la liste officielle de la spécification HTML, et cette valeur est cohérente avec le type d’information demandé. Un autocomplete="tel" sur un champ d’adresse email, c’est une non-conformité — la valeur existe dans la liste, mais elle trompe le navigateur.
La liste officielle compte une quarantaine de valeurs définies dans la spécification HTML5 : given-name, family-name, email, tel, street-address, postal-code, cc-number, cc-exp, bday, entre autres. Pour les formulaires comportant des sections distinctes (facturation, livraison), les préfixes billing et shipping permettent de différencier des champs homologues : autocomplete="billing postal-code" versus autocomplete="shipping postal-code".
Un seul attribut bien placé, une vraie différence pour des millions d’utilisateurs.
Un test pour s'assurer que le remplissage automatique est disponible
Attribut autocomplete valide et pertinent sur les champs personnels
- Repérez tous les champs de formulaire liés à des données personnelles : nom, prénom, email, téléphone, adresse, code postal, numéro de carte, date de naissance, etc.
- Pour chacun de ces champs (
<input>,<select>,<textarea>), vérifiez les trois conditions suivantes : a. L’attributautocompleteest présent sur l’élément. b. La valeur deautocompletefigure dans la liste officielle HTML (https://www.w3.org/TR/html52/sec-forms.html#autofill-processing-model) — une valeur inventée commeautocomplete="firstname"est non conforme. c. La valeur est cohérente avec ce que le champ attend réellement (ex. :autocomplete="email"pour un champ courriel, pasautocomplete="tel"). - Le test est validé si chaque champ personnel identifié satisfait ces trois conditions. Un seul champ sans
autocompletevalide et pertinent suffit à invalider le test.
Exemples
❌ Non conforme : Formulaire d’inscription sans attribut autocomplete
<form>
<label for="prenom">Prénom</label>
<input type="text" id="prenom" name="prenom">
<label for="nom">Nom de famille</label>
<input type="text" id="nom" name="nom">
<label for="email">Adresse email</label>
<input type="email" id="email" name="email">
<label for="tel">Téléphone</label>
<input type="tel" id="tel" name="tel">
</form>Aucun attribut autocomplete n’est déclaré. Le navigateur peut tenter de deviner la finalité des champs à partir du name ou du label, mais ce comportement heuristique varie selon les navigateurs et n’est pas garanti. Pour un utilisateur qui remplit ce formulaire pour la dixième fois, ou qui souffre de troubles moteurs, le remplissage automatique fiable est impossible.
✅ Conforme : Formulaire d’inscription avec autocomplete correctement renseigné
<form>
<label for="prenom">Prénom</label>
<input type="text" id="prenom" name="prenom" autocomplete="given-name">
<label for="nom">Nom de famille</label>
<input type="text" id="nom" name="nom" autocomplete="family-name">
<label for="email">Adresse email</label>
<input type="email" id="email" name="email" autocomplete="email">
<label for="tel">Téléphone</label>
<input type="tel" id="tel" name="tel" autocomplete="tel">
</form>Chaque champ déclare explicitement sa finalité. Le navigateur — et les gestionnaires de mots de passe ou d’autocomplétion — peut pré-remplir ces champs de façon fiable. L’utilisateur n’a plus à retaper des informations qu’il a déjà fournies ailleurs. Notez que given-name et family-name sont les valeurs correctes, pas firstname ou lastname qui n’existent pas dans la spécification.
✅ Conforme : Formulaire de paiement avec préfixes billing et shipping
<fieldset>
<legend>Adresse de facturation</legend>
<label for="billing-street">Rue</label>
<input type="text" id="billing-street" name="billing-street" autocomplete="billing street-address">
<label for="billing-zip">Code postal</label>
<input type="text" id="billing-zip" name="billing-zip" autocomplete="billing postal-code">
</fieldset>
<fieldset>
<legend>Adresse de livraison</legend>
<label for="shipping-street">Rue</label>
<input type="text" id="shipping-street" name="shipping-street" autocomplete="shipping street-address">
<label for="shipping-zip">Code postal</label>
<input type="text" id="shipping-zip" name="shipping-zip" autocomplete="shipping postal-code">
</fieldset>Les préfixes billing et shipping permettent de distinguer des champs homologues dans un même formulaire. Sans eux, un navigateur ne saurait pas quelle adresse injecter dans quel champ. Ici, les données de facturation et de livraison de l’utilisateur arrivent au bon endroit sans ambiguïté.
Astuces et pièges
⚠️ autocomplete="off" désactive le critère et pénalise vos utilisateurs
Certaines équipes ajoutent autocomplete="off" pour des raisons de sécurité supposées — éviter que les données sensibles soient mémorisées dans le navigateur. Double erreur : les navigateurs modernes ignorent souvent cette directive sur les champs de connexion, et pour les utilisateurs avec des limitations motrices, vous supprimez une aide indispensable. Sur un champ de données personnelles, autocomplete="off" rend le critère 11.13 non conforme.
⚠️ Valeur inventée ou absente de la liste officielle
autocomplete="firstname" ou autocomplete="phone-number" sont des valeurs non conformes : elles n’existent pas dans la spécification HTML. Les valeurs correctes sont respectivement given-name et tel. C’est l’erreur la plus fréquente en audit. Consultez systématiquement https://www.w3.org/TR/html52/sec-forms.html#autofill-processing-model avant d’utiliser une valeur que vous avez déduite par intuition.
💡 Le type HTML et autocomplete ont des rôles distincts
<input type="email"> aide les navigateurs mobiles à afficher le clavier adapté, mais ne suffit pas pour garantir une autocomplétion fiable au sens du RGAA. Vous devez ajouter autocomplete="email" explicitement. Les deux attributs se complètent : type définit le format de saisie, autocomplete définit la finalité sémantique du champ.
⚠️ Les éléments <select> sont aussi concernés
L’attribut autocomplete ne s’applique pas uniquement aux <input>. Un <select> pour le pays ou la région peut recevoir autocomplete="country" ou autocomplete="address-level1". L’oubli des listes déroulantes est courant en audit — vérifiez tous les contrôles de formulaire liés à des données personnelles, pas uniquement les champs texte.
⚠️ Champs sans équivalent dans la liste officielle
Si votre formulaire demande une information qui n’a pas de correspondance dans la liste officielle (numéro de dossier client, code entreprise interne), le critère 11.13 ne s’applique pas à ce champ. L’obligation ne concerne que les données personnelles de l’utilisateur au sens de la spécification HTML. En cas de doute, l’absence d’autocomplete vaut mieux qu’une valeur incorrecte.
Questions fréquentes
Comment l'attribut autocomplete s'applique-t-il aux champs de mot de passe en RGAA ?
Oui, avec des valeurs spécifiques. Un champ de mot de passe existant (connexion) prend autocomplete="current-password". Un champ de nouveau mot de passe (création de compte, changement de mot de passe) prend autocomplete="new-password". Cette distinction est importante : new-password signale aux gestionnaires de mots de passe qu’ils doivent proposer de générer un mot de passe fort, et non pré-remplir le mot de passe actuel.
Comment auditer efficacement le critère RGAA 11.13 sur le remplissage automatique ?
Ouvrez les DevTools (F12), inspectez chaque champ lié à des données personnelles et vérifiez la présence et la valeur de l’attribut autocomplete. Pour aller plus vite sur une page, lancez une recherche dans le code source (Ctrl+U) sur la chaîne autocomplete et listez toutes les valeurs trouvées. Croisez-les avec la liste officielle. Testez ensuite en pratique : remplissez le formulaire une première fois, revenez dessus — les champs proposent-ils des suggestions cohérentes ?
Quand l'attribut autocomplete est-il nécessaire sur un champ de recherche RGAA ?
Non. Le critère 11.13 cible uniquement les champs qui collectent des données personnelles de l’utilisateur. Un champ de recherche de contenu (rechercher un article, un produit) n’est pas dans le périmètre. La valeur autocomplete="search" existe dans la spécification, mais son usage sur une barre de recherche n’est pas une exigence de ce critère.
Comment choisir la valeur autocomplete correcte selon le libellé visible du champ RGAA ?
Elle doit être cohérente avec la finalité du champ, pas forcément avec son libellé exact. Un champ intitulé « Votre courriel » prend autocomplete="email". Un champ intitulé « Numéro de portable » prend autocomplete="tel". C’est ce que le champ attend comme information qui détermine la valeur, pas le wording du label. Critre 11.13 est invalidé si la valeur est techniquement valide mais sémantiquement incohérente.