WCAG 3.3.7 : Saisie redondante

Ce que signifie cette règle

WCAG 3.3.7 Saisie redondante est un critère de succès de niveau A introduit dans WCAG 2.2. Il stipule : « Les informations précédemment saisies par l’utilisateur ou fournies à celui-ci, qui doivent être saisies à nouveau dans le même processus, sont soit préremplies automatiquement, soit disponibles pour que l’utilisateur puisse les sélectionner. » En termes simples, si un utilisateur a déjà saisi son adresse e-mail, son adresse de livraison, sa date de naissance ou toute autre information au cours d’une session, votre interface ne doit pas l’obliger à la ressaisir dans le même processus ou flux.

Ce critère s’applique largement à tout formulaire en plusieurs étapes, processus de paiement, assistant d’inscription, flux de prise de rendez-vous ou séquence similaire où des données collectées à une étape peuvent être nécessaires à une étape ultérieure. Les comportements concernés incluent les champs de texte, listes déroulantes, cases à cocher, boutons radio et tout autre contrôle de formulaire qui collecte des données fournies par l’utilisateur. Lorsque la même information est requise à nouveau, elle doit soit être préremplie automatiquement à l’aide de la valeur fournie précédemment, soit être proposée comme option sélectionnable afin que l’utilisateur puisse la confirmer plutôt que la ressaisir.

Un respect de ce critère ressemble à ceci : un formulaire d’adresse de facturation prérempli avec l’adresse de livraison saisie par l’utilisateur sur l’écran précédent, ou une étape de confirmation qui affiche l’adresse e-mail précédemment saisie dans un champ en lecture seule. Un autre modèle conforme est une case à cocher intitulée « Mon adresse de facturation est la même que mon adresse de livraison » qui, lorsqu’elle est cochée, copie automatiquement les valeurs. Un non-respect ressemble à ceci : un flux d’inscription en plusieurs étapes qui demande une adresse e-mail à l’étape 1 puis à nouveau à l’étape 3 sans préremplir le second champ, ou un formulaire de déclaration d’assurance qui demande le nom du déclarant et son numéro de police sur plusieurs écrans distincts sans aucun remplissage automatique.

WCAG 3.3.7 définit deux exceptions officielles. La première s’applique lorsque la ressaisie de l’information est essentielle au processus — par exemple, un champ « Confirmez votre nouveau mot de passe » demande intentionnellement aux utilisateurs de saisir deux fois le même mot de passe comme protection contre les fautes de frappe, et cela est considéré comme un contrôle de sécurité essentiel. La seconde exception s’applique lorsque les informations précédemment saisies ne sont plus valides — par exemple, si une session a expiré ou si un produit est en rupture de stock et que l’utilisateur doit recommencer un processus avec des données actualisées. En dehors de ces exceptions, la saisie redondante constitue un échec de conformité.

Pourquoi c’est important

La saisie redondante impose une charge disproportionnée aux utilisateurs dont les conditions rendent la saisie lente, douloureuse, sujette aux erreurs ou cognitivement éprouvante. Comprendre qui est concerné aide les développeurs et les designers à apprécier que ce critère est plus qu’une simple fonctionnalité de confort — c’est un véritable obstacle pour de nombreuses personnes.

Les utilisateurs ayant des déficiences motrices, comme ceux qui ont des tremblements, des lésions de la moelle épinière ou des affections telles que la SLA ou la sclérose en plaques, peuvent dépendre de dispositifs d’accès par contacteur, de baguettes buccales, de logiciels de suivi oculaire ou du contrôle vocal pour saisir du texte. Pour ces utilisateurs, taper ne serait-ce qu’une courte adresse peut prendre plusieurs minutes et demander un effort physique important. Être obligé de répéter cette saisie n’est pas seulement agaçant — cela peut provoquer des douleurs physiques ou rendre la tâche pratiquement impossible en une seule session.

Les utilisateurs ayant des handicaps cognitifs, y compris la dyslexie, les troubles de l’attention, les traumatismes crâniens et les affections liées à la démence, peuvent avoir du mal à se souvenir de ce qu’ils ont saisi trois étapes plus tôt. Transcrire correctement des informations de mémoire ou à partir d’un document papier à plusieurs reprises augmente fortement les taux d’erreur et d’abandon. Selon l’Organisation mondiale de la santé, plus d’1 milliard de personnes dans le monde vivent avec une forme de handicap, et les handicaps cognitifs représentent l’un des segments les plus importants et les plus mal desservis dans la planification de l’accessibilité.

Les utilisateurs ayant des différences de membres supérieurs, y compris ceux qui sont nés avec ou ont acquis des différences de membres, tapent beaucoup plus lentement et peuvent utiliser des dispositifs d’entrée alternatifs. Chaque frappe supplémentaire exigée multiplie la charge pour ces utilisateurs.

Considérez un scénario réel : une personne atteinte de polyarthrite rhumatoïde prend un rendez-vous médical via le portail en ligne d’un hôpital. Sur l’écran 1, elle saisit son numéro d’identification national, son nom, sa date de naissance et son numéro de téléphone. Sur l’écran 3, le portail demande à nouveau son nom et sa date de naissance pour confirmer le dossier patient. Cette personne doit ressaisir laborieusement des informations fournies seulement deux écrans plus tôt, au risque de fautes de frappe pouvant entraîner des incohérences de dossiers, et subit une fatigue physique inutile. Un simple préremplissage ou une autopopulation de ces champs supprimerait entièrement cet obstacle.

Au-delà de l’accessibilité, l’élimination de la saisie redondante améliore les taux de conversion, réduit l’abandon de formulaires et diminue les tickets de support causés par des erreurs de saisie — apportant une valeur commerciale mesurable en plus d’un design inclusif.

Règles Axe-core associées

WCAG 3.3.7 est un critère qui nécessite des tests manuels. Aucune règle axe-core automatisée n’existe actuellement qui puisse détecter de manière fiable les violations de saisie redondante, car les outils automatisés ne peuvent pas comprendre la relation sémantique entre les données saisies à travers plusieurs étapes ou pages dans un processus dynamique. Ils n’ont aucune connaissance des informations collectées à une étape précédente, des informations demandées à l’étape actuelle, ni de la question de savoir si ces deux informations sont logiquement identiques. Seul un testeur humain qui parcourt l’ensemble du flux peut observer et évaluer si les mêmes données sont demandées deux fois sans préremplissage.

• Test manuel requis (nouveau dans WCAG 2.2) : axe-core et les autres analyseurs d’accessibilité automatisés analysent le DOM d’un seul état de page à la fois. Ils ne peuvent pas suivre les valeurs saisies par l’utilisateur à travers plusieurs chargements de page ou étapes de formulaire, ne peuvent pas comparer les libellés de champs entre les étapes pour identifier les duplications sémantiques, et ne peuvent pas évaluer si un mécanisme de préremplissage fonctionne correctement. Les testeurs doivent parcourir manuellement les processus en plusieurs étapes, consigner les données saisies à chaque étape et vérifier à chaque étape suivante si les données fournies précédemment sont soit préremplies, soit sélectionnables. Tout outil prétendant détecter automatiquement les violations de 3.3.7 produirait un taux de faux négatifs extrêmement élevé et ne devrait pas être utilisé comme unique méthode de test.

Comment tester

1. Analyse automatisée comme point de départ : Exécutez axe DevTools, Lighthouse ou l’auditeur Accsible sur chaque étape individuelle de votre processus en plusieurs étapes. Bien que ces outils ne signalent pas directement les violations de 3.3.7, ils feront remonter des problèmes connexes tels que l’absence d’attributs autocomplete, des champs de formulaire non étiquetés et d’autres échecs de critères 3.3.x qui coexistent souvent. Documentez chaque champ de formulaire que vous trouvez à chaque étape.
2. Cartographier les exigences de données à travers les étapes : Avant les tests manuels, créez un tableau ou une feuille de calcul simple listant chaque étape du processus et tous les champs de données qu’elle collecte. Identifiez ensuite tout libellé de champ ou type de données apparaissant dans plus d’une étape. Cet exercice de cartographie met en évidence des violations potentielles avant même d’ouvrir un navigateur.
3. Parcours manuel — bureau : À l’aide d’une souris et d’un clavier standard, complétez l’ensemble du processus en plusieurs étapes (par exemple, paiement, inscription, dépôt de réclamation). Saisissez des valeurs réalistes dans chaque champ. Lorsque vous arrivez à une étape qui apparaît dans votre carte comme un champ dupliqué, vérifiez si le champ est prérempli avec votre saisie précédente, ou si une option sélectionnable présentant votre saisie précédente est disponible. Si ce n’est pas le cas, consignez un échec. Répétez ce test avec un lecteur d’écran (NVDA avec Firefox, JAWS avec Chrome, VoiceOver avec Safari) pour confirmer que les valeurs préremplies sont correctement annoncées et que les contrôles de sélection pour les valeurs précédemment saisies sont accessibles au clavier.
4. Parcours manuel — mobile : Complétez le même flux sur iOS (VoiceOver + Safari) et Android (TalkBack + Chrome). Faites attention à la question de savoir si les fonctionnalités natives d’autocomplétion ou de remplissage automatique sont désactivées par l’application, ce qui pourrait créer involontairement des obstacles de saisie redondante même si le développeur comptait sur l’autocomplétion pour aider.
5. Tester les exceptions : Identifiez tout champ qui demande intentionnellement une saisie en double (par exemple, confirmation de mot de passe, ressaisir l’e-mail). Vérifiez qu’ils répondent bien aux critères de contrôles de sécurité ou de validation essentiels au titre de l’exception WCAG et qu’il ne s’agit pas simplement de champs redondants qui devraient être supprimés ou préremplis.
6. Tester avec l’autocomplétion désactivée : Certains utilisateurs désactivent l’autocomplétion du navigateur pour des raisons de confidentialité. Testez si le mécanisme de préremplissage propre à l’application (côté serveur ou piloté par JavaScript) fonctionne toujours correctement lorsque l’autocomplétion du navigateur est désactivée, afin de garantir que le critère est respecté indépendamment du comportement du navigateur.

Comment corriger

Paiement en plusieurs étapes — même adresse requise sur deux écrans — Incorrect

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Paiement en plusieurs étapes — même adresse requise sur deux écrans — Correct

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Assistant d’inscription demandant l’e-mail deux fois sans justification — Incorrect

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Assistant d’inscription — e-mail prérempli à partir des données de session — Correct

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Prise de rendez-vous — informations patient redemandées à l’étape de résumé — Incorrect

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Prise de rendez-vous — date de naissance affichée en confirmation en lecture seule — Correct

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Erreurs courantes

• Construire des formulaires en plusieurs étapes comme des pages indépendantes sans état de session partagé, de sorte qu’il n’existe aucun mécanisme pour transmettre les valeurs saisies aux étapes précédentes — l’erreur architecturale la plus fondamentale conduisant à des échecs 3.3.7.
• Fournir une case à cocher « même que l’adresse de livraison » sans réellement remplir les champs de facturation lorsqu’elle est cochée, obligeant les utilisateurs à saisir quand même manuellement les détails de l’adresse après avoir indiqué qu’ils devraient correspondre.
• Préremplir les champs au chargement de la page puis les effacer en cas d’erreur de validation, de sorte qu’un utilisateur qui commet une erreur à une étape ultérieure doit ressaisir toutes les données fournies précédemment lorsqu’il revient pour la corriger.
• Stocker les données de session de manière non sécurisée et choisir de désactiver cette fonctionnalité plutôt que de corriger le problème de sécurité, ce qui entraîne une expérience de préremplissage défaillante qui constitue techniquement un échec 3.3.7.
• Utiliser l’exception de confirmation de mot de passe pour justifier la demande de ressaisie des adresses e-mail, alors que la confirmation d’e-mail n’est pas un contrôle de sécurité essentiel et ne relève pas de l’exception WCAG.
• Ne pas transmettre les valeurs reportées via des champs cachés dans les formulaires rendus côté serveur, ce qui fait que les valeurs préremplies sont perdues lorsqu’un utilisateur navigue en arrière et en avant entre les étapes à l’aide des boutons d’historique du navigateur.
• Se fier uniquement au remplissage automatique du navigateur pour satisfaire ce critère, sans mettre en œuvre de préremplissage au niveau de l’application — les utilisateurs qui désactivent le remplissage automatique pour des raisons de confidentialité n’ont alors aucun parcours conforme dans le processus.
• Préremplir un champ mais le définir comme disabled plutôt que readonly, ce qui fait que la valeur est exclue de la soumission du formulaire dans la plupart des navigateurs, rompant le processus et pouvant forcer une ressaisie.
• Ne pas tester l’ensemble du flux de bout en bout avec des utilisateurs qui utilisent des logiciels de saisie vocale tels que Dragon NaturallySpeaking, où des champs redondants peuvent nécessiter la répétition de la même commande de dictée plusieurs fois, une charge importante facile à négliger lors des tests par les développeurs.
• Considérer que ce critère ne s’applique qu’aux champs d’adresse, alors qu’il s’applique tout autant à toute donnée répétée, y compris les noms, numéros de téléphone, numéros d’identification nationaux, numéros de police, dates et toute autre information fournie par l’utilisateur demandée plus d’une fois dans le même processus.

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, impose la conformité à l’accessibilité web pour un large éventail d’entités publiques et privées opérant en Turquie. WCAG 3.3.7 Saisie redondante est un critère de niveau A dans WCAG 2.2, et la conformité de niveau A constitue le socle obligatoire au titre de cette circulaire. Cela signifie que toute entité concernée exploitant un site web, une application web ou un service numérique ne doit pas exiger des utilisateurs qu’ils ressaisissent des informations qu’ils ont déjà fournies dans le même processus — sans exception — sous peine de non-conformité.

La circulaire établit un calendrier de mise en œuvre progressif : les institutions publiques doivent atteindre la conformité dans un délai d’un an à compter de la publication de la circulaire, tandis que les entités du secteur privé dans les catégories couvertes disposent de deux ans pour se mettre en conformité.

Les types d’entités couverts par la circulaire sont nombreux et incluent les plateformes et places de marché de commerce électronique, toutes les institutions publiques et agences gouvernementales, les banques et prestataires de services financiers, les hôpitaux et portails de santé (publics et privés), les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privé et les écoles privées autorisées par le Ministry of National Education (MoNE). Pour toutes ces entités, les processus numériques en plusieurs étapes — flux de paiement sur les sites de commerce électronique, inscription des patients sur les portails hospitaliers, ouverture de compte sur les plateformes bancaires, formulaires d’inscription sur les sites d’écoles — doivent être audités et corrigés pour éliminer toute instance de saisie redondante.

En pratique, cette réglementation place la conformité à WCAG 3.3.7 au cœur du périmètre des équipes achats, produit et juridique dans l’économie numérique turque. Par exemple, une plateforme de commerce électronique turque exploitant un paiement en plusieurs étapes qui demande une adresse de livraison sur un écran puis une adresse de facturation sur le suivant sans offrir d’option de préremplissage ou de copie est en violation directe à la fois de WCAG 2.2 niveau A et de la Circulaire présidentielle. De même, le portail de prise de rendez-vous d’un hôpital public qui demande aux patients de ressaisir leur numéro d’identité ou leur date de naissance sur plusieurs écrans n’est pas conforme. Les organisations soumises à la circulaire devraient prioriser un audit de bout en bout de tous les processus en plusieurs étapes dans le cadre de leur feuille de route de conformité, en traitant l’élimination de la saisie redondante comme une tâche d’ingénierie obligatoire, et non comme une amélioration facultative.