WCAG 1.3.5 : Identifier la finalité de la saisie

Ce que signifie cette règle

WCAG 1.3.5 — Identifier la finalité de la saisie est un critère de niveau AA introduit dans WCAG 2.1 et repris dans WCAG 2.2. Il exige que tout élément <input>, <select> ou <textarea> qui collecte des informations sur l’utilisateur ait sa finalité communiquée de manière programmatique, afin que les navigateurs et les technologies d’assistance puissent identifier et exploiter automatiquement cette finalité.

Le mécanisme permettant de satisfaire ce critère est l’attribut autocomplete, combiné avec la valeur de jeton correcte issue de la liste officielle définie dans la spécification HTML. Lorsqu’un champ collecte le nom, l’adresse e-mail, le numéro de téléphone, l’adresse postale, le numéro de carte de crédit ou des données personnelles similaires d’un utilisateur, l’attribut autocomplete doit porter une valeur qui décrit avec précision la finalité de ce champ — par exemple, autocomplete="given-name" pour un champ de prénom, ou autocomplete="email" pour un champ d’e-mail.

Le critère s’applique spécifiquement aux champs qui collectent des informations sur l’utilisateur lui-même. Il ne s’applique pas aux champs où un utilisateur saisit des données concernant une autre personne (par exemple, un formulaire de réservation de voyage demandant le nom d’un passager lorsque l’utilisateur réserve pour le compte d’une autre personne), ni aux champs pour lesquels l’autocomplétion créerait un risque de sécurité — comme les mots de passe à usage unique ou les défis de type CAPTCHA, qui peuvent légitimement utiliser autocomplete="off" ou autocomplete="one-time-code".

Pour être conforme, il faut que : (1) chaque champ de saisie entrant dans le champ d’application porte un attribut autocomplete ; et (2) la valeur de cet attribut soit un jeton valide et reconnu par la spécification HTML d’autoremplissage — pas une chaîne arbitraire, pas une valeur vide lorsqu’une valeur significative est requise, et pas un jeton mal orthographié. Un échec se produit lorsqu’un champ entrant dans le champ d’application n’a pas d’attribut autocomplete, a autocomplete="off" sans justification, ou a un jeton invalide comme autocomplete="firstname" (le jeton correct est given-name) ou autocomplete="phone" (le jeton correct est tel).

La liste complète des jetons d’autocomplétion valides est maintenue par le WHATWG HTML Living Standard et inclut des valeurs pour les noms (given-name, family-name, additional-name), les adresses (street-address, address-line1, postal-code, country-name), les informations de contact (email, tel, tel-national), les identifiants (username, current-password, new-password), les détails de paiement (cc-name, cc-number, cc-exp, cc-csc), et plus encore. Les jetons peuvent également être précédés d’identifiants de section (par exemple, section-billing) et de mots-clés de livraison ou de facturation pour gérer plusieurs groupes d’adresses sur une même page.

Pourquoi c’est important

Ce critère existe principalement au bénéfice des utilisateurs ayant des déficiences cognitives, y compris les personnes dyslexiques, ayant des troubles de la mémoire, des troubles de l’attention ou des troubles d’apprentissage. Pour ces utilisateurs, remplir correctement un formulaire de paiement complexe — avec des champs distincts pour le prénom, le nom de famille, l’adresse, la ville, le code postal, le téléphone et les détails de paiement — peut représenter une charge cognitive importante. Lorsque les jetons autocomplete sont corrects, les navigateurs peuvent préremplir les champs à partir du profil enregistré de l’utilisateur en une seule interaction, réduisant considérablement les frictions et le risque d’erreurs.

Les utilisateurs ayant des déficiences motrices — y compris les personnes ayant une fonction limitée des mains qui utilisent l’accès par contacteur, des logiciels de suivi oculaire ou des dispositifs de type souffle-et-aspiration — en bénéficient tout autant. La saisie est lente, exigeante et parfois douloureuse pour ces utilisateurs. Un autoremplissage fiable peut transformer une épreuve de dix minutes en une tâche quasi instantanée. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap significatif, et les déficiences motrices affectant la motricité fine des mains comptent parmi les plus courantes.

Au-delà de l’autoremplissage, des jetons autocomplete corrects permettent aux navigateurs et aux technologies d’assistance de présenter des icônes, des libellés ou des interfaces de saisie enrichies personnalisés — par exemple, afficher automatiquement un clavier téléphonique pour un champ tel sur un appareil mobile, ou montrer un visuel de carte de crédit pour un champ cc-number. Les gestionnaires de mots de passe, qui sont des outils d’accessibilité essentiels pour les utilisateurs ayant des troubles de la mémoire, s’appuient également sur ces jetons pour identifier et remplir correctement les champs d’identifiants.

Considérons un scénario réel : une personne atteinte de paralysie cérébrale remplit une demande de prestations sociales. Le formulaire comporte douze champs couvrant le nom, l’adresse, le numéro d’identification national et les coordonnées. Sans valeurs autocomplete correctes, chaque champ doit être saisi manuellement. Un seul jeton mal orthographié — par exemple, autocomplete="surname" au lieu de autocomplete="family-name" — suffit à empêcher le navigateur de reconnaître le champ, obligeant l’utilisateur à saisir son nom de famille caractère par caractère. Avec des jetons corrects, l’ensemble du formulaire peut être rempli automatiquement en quelques secondes, réduisant à la fois l’effort et le taux d’erreur.

Il existe également des avantages en termes d’ergonomie et de taux de conversion pour les organisations : les recherches montrent de manière constante que les formulaires compatibles avec l’autoremplissage ont des taux d’abandon plus faibles et des taux de complétion plus élevés, ce qui signifie que corriger les jetons d’autocomplétion n’est pas seulement une amélioration de l’accessibilité, mais aussi une amélioration directe pour l’activité.

Règles axe-core associées

• autocomplete-valid — Il s’agit de la règle axe-core principale pour WCAG 1.3.5. Elle inspecte chaque élément <input>, <select> et <textarea> qui possède un attribut autocomplete et vérifie si la valeur de cet attribut est un jeton valide et reconnu par la spécification HTML d’autoremplissage. La règle signale les éléments dont le jeton est mal orthographié (par exemple, given name avec un espace au lieu d’un tiret), ceux où une valeur propriétaire non standard a été utilisée (par exemple, autocomplete="first-name"), ou ceux où l’ordre des jetons dans une valeur multi-jetons est incorrect (par exemple, placer le nom de champ avant un préfixe de section requis). La règle ne signale pas les champs qui n’ont pas du tout d’attribut autocomplete — cette situation nécessite un examen manuel — car axe-core ne peut pas déterminer de manière programmatique si un champ donné entre dans le champ d’application du critère (c’est-à-dire s’il collecte des informations sur l’utilisateur).
• Pourquoi des tests manuels sont également nécessaires — Les outils automatisés comme axe-core ne peuvent valider que le fait qu’une valeur autocomplete présente est syntaxiquement correcte ; ils ne peuvent pas déterminer si le jeton choisi décrit avec précision la finalité du champ. Par exemple, un champ de téléphone de facturation avec autocomplete="email" passerait la règle automatisée (puisque email est un jeton valide) mais ne satisferait pas le critère, car le jeton ne correspond pas à la finalité réelle du champ. De même, les outils automatisés ne peuvent pas identifier les champs qui n’ont pas d’attribut autocomplete mais devraient en avoir un, car déterminer si un champ collecte des informations personnelles sur l’utilisateur nécessite un jugement humain basé sur le contexte. Un examen manuel de chaque champ de formulaire qui collecte des données spécifiques à l’utilisateur est donc essentiel pour une conformité complète avec 1.3.5.

Comment tester

1. Exécuter une analyse automatisée avec axe DevTools ou Lighthouse. Ouvrez la page contenant le formulaire dans Chrome ou Firefox. Dans axe DevTools, cliquez sur « Analyze » et filtrez les résultats par l’ID de règle autocomplete-valid. Dans Lighthouse, exécutez un audit d’accessibilité et recherchez les violations faisant référence à autocomplete. Notez chaque élément signalé et enregistrez les valeurs de jetons invalides indiquées. Corrigez chaque élément signalé et relancez l’analyse pour confirmer la correction.
2. Identifier manuellement tous les champs de saisie entrant dans le champ d’application. Passez en revue le formulaire et listez chaque champ qui collecte des informations sur l’utilisateur actuel — champs de nom, champs d’adresse, e-mail, téléphone, détails de paiement, identifiants. Pour chaque champ, vérifiez qu’un attribut autocomplete est présent et que son jeton correspond à la finalité réelle du champ selon la liste des jetons d’autoremplissage HTML. Les champs collectant des informations sur d’autres personnes sont hors du champ d’application et peuvent être exclus.
3. Tester le comportement d’autoremplissage du navigateur. Dans Chrome ou Firefox, assurez-vous que le navigateur dispose d’un profil enregistré (Paramètres > Autofill). Accédez à la page du formulaire et cliquez dans le premier champ d’informations personnelles. Vérifiez que le navigateur présente une suggestion d’autoremplissage et que la sélectionner remplit les bons champs avec les bonnes valeurs. Répétez l’opération pour les champs d’adresse, de paiement et d’identifiants. Si l’autoremplissage ne propose pas de valeurs ou remplit les mauvais champs, il est probable que les jetons d’autocomplétion soient incorrects.
4. Tester avec une combinaison lecteur d’écran / navigateur. Avec NVDA et Firefox, naviguez jusqu’à chaque champ de formulaire à l’aide de la touche Tab. NVDA doit annoncer le libellé et la finalité du champ ; certaines combinaisons lecteur d’écran / navigateur annonceront également la finalité d’autocomplétion. Avec VoiceOver sur macOS (Safari), parcourez les champs avec Tab et écoutez si VoiceOver annonce la disponibilité de l’autoremplissage. Avec JAWS et Chrome, parcourez de la même manière les champs avec Tab et vérifiez que JAWS annonce le contexte attendu du champ. Bien que les lecteurs d’écran n’annoncent pas toujours explicitement les jetons d’autocomplétion, le fait de confirmer que l’autoremplissage fonctionne correctement en combinaison avec la navigation au clavier valide l’exposition de la finalité programmatique.
5. Inspecter les attributs autocomplete dans les outils de développement du navigateur. Faites un clic droit sur chaque champ de formulaire et sélectionnez « Inspecter ». Dans le panneau Elements, vérifiez que l’attribut autocomplete est présent et que sa valeur correspond exactement à un jeton valide. Portez une attention particulière aux valeurs multi-jetons — par exemple, autocomplete="shipping street-address" — et vérifiez que l’ordre des jetons suit la spécification (nom de section, puis « shipping » ou « billing », puis nom de champ).

Comment corriger

Champs de nom — Incorrect

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Champs de nom — Correct

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Formulaire d’adresse avec sections de facturation et de livraison — Incorrect

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Formulaire d’adresse avec sections de facturation et de livraison — Correct

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Champ de téléphone — Incorrect

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Champ de téléphone — Correct

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Identifiants de connexion — Incorrect

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Identifiants de connexion — Correct

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Erreurs courantes

• Utiliser autocomplete="firstname" ou autocomplete="first-name" au lieu du jeton correct given-name". Ces valeurs non standard ne sont pas reconnues par les navigateurs ou les technologies d’assistance, même si elles semblent logiques. Utilisez toujours les jetons exacts de la spécification HTML d’autoremplissage.
• Utiliser autocomplete="phone" au lieu de autocomplete="tel". Le mot « phone » n’est pas un jeton valide. La spécification utilise tel pour un numéro de téléphone complet, et tel-national, tel-area-code, tel-local pour les sous-parties d’un numéro de téléphone.
• Définir autocomplete="off" sur les champs d’identifiants comme mesure de sécurité mal avisée. Les navigateurs modernes et la spécification WCAG reconnaissent tous deux que le fait d’empêcher l’autoremplissage sur les formulaires de connexion crée de réels obstacles pour les utilisateurs handicapés et n’améliore pas de manière significative la sécurité. Utilisez plutôt autocomplete="username" et autocomplete="current-password".
• Omettre complètement l’attribut autocomplete sur les champs de données personnelles, en supposant que le navigateur déduira la finalité à partir du nom ou du libellé du champ. Les navigateurs utilisent des heuristiques pour deviner la finalité des champs, mais celles-ci sont peu fiables et incohérentes d’un navigateur à l’autre. Des jetons explicites sont nécessaires pour garantir une expérience accessible.
• Utiliser autocomplete="address" au lieu des sous-jetons d’adresse spécifiques. Il n’existe pas de jeton address dans la spécification. Vous devez utiliser individuellement street-address, address-line1, address-line2, address-level1 (État/province), address-level2 (ville) et postal-code.
• Placer les mots-clés de livraison ou de facturation dans le mauvais ordre dans les valeurs multi-jetons. L’ordre correct est : préfixe de section facultatif (par exemple, section-billing), puis mot-clé facultatif shipping/billing, puis le jeton de nom de champ. Écrire autocomplete="street-address billing" est invalide ; la forme correcte est autocomplete="billing street-address".
• Appliquer autocomplete uniquement aux champs visibles et ignorer les champs masqués ou révélés dynamiquement. Les champs qui sont initialement masqués mais révélés par une interaction utilisateur (comme des lignes d’adresse supplémentaires ou des champs facultatifs) doivent également porter des jetons d’autocomplétion corrects lorsqu’ils deviennent actifs.
• Utiliser JavaScript pour supprimer ou écraser dynamiquement l’attribut autocomplete après le chargement de la page. Certaines bibliothèques de formulaires ou frameworks d’interface réinitialisent les attributs des champs de saisie lorsque les composants sont montés ou re-rendus, supprimant involontairement les jetons d’autocomplétion. Vérifiez toujours que l’attribut persiste dans le DOM en production après l’exécution de tout le JavaScript.
• Supposer que type="email" ou type="tel" sur un champ de saisie suffit à communiquer la finalité sans autocomplete. Bien que type fournisse certaines informations, l’attribut autocomplete est un signal distinct et explicite exigé par WCAG 1.3.5 et utilisé différemment par les navigateurs et les technologies d’assistance.
• Utiliser le même jeton autocomplete sur deux champs différents qui collectent des données différentes. Par exemple, étiqueter à la fois un champ d’e-mail professionnel et un champ d’e-mail personnel avec autocomplete="email" perturbe les navigateurs et peut entraîner un autoremplissage incorrect. Utilisez des préfixes de section (par exemple, section-work email vs. section-personal email) pour lever l’ambiguïté.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences d’accessibilité contraignantes pour un large éventail d’organisations opérant en Turquie. La Circulaire impose la conformité à WCAG 2.2 au niveau AA comme norme de base pour les services numériques, ce qui inclut directement WCAG 1.3.5 — Identifier la finalité de la saisie.

Les types d’entités couverts par la Circulaire sont très variés. Les institutions publiques et les organismes gouvernementaux sont tenus de respecter ces normes pour tous les services numériques destinés aux citoyens. Les organisations du secteur privé concernées incluent les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et prestataires de soins de santé, les opérateurs de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises privées de transport de passagers et les établissements d’enseignement privés autorisés par le ministère de l’Éducation nationale (MoNE). La conséquence pratique est que pratiquement tous les principaux produits numériques destinés aux consommateurs en Turquie — des applications bancaires aux caisses de commerce en ligne en passant par les portails de prise de rendez-vous médicaux — doivent avoir des jetons autocomplete correctement implémentés sur tous les champs de saisie de données personnelles.

Pour WCAG 1.3.5 spécifiquement, cela signifie que tout formulaire de paiement de commerce électronique, formulaire d’ouverture de compte bancaire, formulaire d’enregistrement de patient à l’hôpital ou formulaire d’abonnement télécom turc qui collecte des informations utilisateur telles que le nom, l’adresse, le numéro de téléphone ou les détails de paiement doit inclure des valeurs d’attribut autocomplete valides sur chaque champ de saisie pertinent. Ne pas le faire constitue une non-conformité de niveau AA et peut empêcher une organisation d’obtenir ou de conserver le Logo d’Accessibilité (Erişilebilirlik Logosu), la marque officielle délivrée par le ministère de la Famille et des Services sociaux qui certifie que les services numériques d’une organisation respectent les normes d’accessibilité.

Le Logo d’Accessibilité a un poids réputationnel et réglementaire, et les organisations sur des marchés de consommation concurrentiels — comme le commerce électronique et la banque — ont de fortes incitations à l’obtenir et à le maintenir. Parce que WCAG 1.3.5 est simple à mettre en œuvre (ajouter ou corriger les valeurs d’attribut autocomplete ne nécessite aucun changement d’architecture) tout en apportant un bénéfice significatif aux utilisateurs ayant des déficiences cognitives et motrices, il représente l’une des améliorations d’accessibilité à plus forte valeur ajoutée et à plus faible effort qu’une organisation puisse réaliser dans la poursuite d’une conformité complète au niveau AA au titre de la Circulaire 2025/10.

Les organisations devraient auditer tous les formulaires sur l’ensemble de leurs propriétés numériques — y compris les interfaces web mobiles et les mises en page responsives — et établir une politique de développement qui exige des jetons autocomplete corrects comme partie standard de toute implémentation de formulaire. Cela devrait être appliqué via des tests automatisés dans les pipelines CI/CD à l’aide d’outils tels qu’axe-core, afin que les régressions soient détectées avant d’atteindre la production.