WCAG 3.3.4 : Prévention des erreurs (juridique, financier, données)

Ce que signifie cette règle

Le critère de succès 3.3.4 des WCAG, intitulé Prévention des erreurs (juridiques, financières, données), est une exigence de niveau AA relevant du Principe 3 (Compréhensible) et de la Ligne directrice 3.3 (Aide à la saisie). Il s’applique spécifiquement aux pages web où les utilisateurs peuvent entraîner des engagements juridiques ou des transactions financières, ou encore modifier ou supprimer des données contrôlables par l’utilisateur dans un système de stockage de données.

Le critère impose qu’au moins une des trois mesures de protection suivantes soit fournie pour toute soumission de ce type :

• Réversible : La soumission peut être annulée après avoir été envoyée. Par exemple, une commande peut être annulée dans une fenêtre de temps définie, ou un enregistrement supprimé peut être restauré.
• Vérifiée : Les données saisies par l’utilisateur sont vérifiées pour détecter les erreurs de saisie, et l’utilisateur a la possibilité de corriger ces erreurs avant que la soumission ne soit finalisée.
• Confirmée : Un mécanisme est fourni pour revoir, confirmer et corriger les informations avant la soumission finale. Cela prend généralement la forme d’un récapitulatif ou d’une étape de revue avant qu’un bouton d’envoi ne finalise la transaction.

Il est important de noter qu’une seule de ces trois conditions doit être satisfaite pour réussir. Fournir uniquement une étape de revue et de confirmation est suffisant, tout comme offrir une fenêtre d’annulation après la soumission, ou une validation robuste en temps réel avec possibilité de correction. La meilleure pratique consiste toutefois à combiner plusieurs mesures de protection.

Portée du critère : La règle s’applique à trois catégories de transactions. Premièrement, elle couvre les engagements juridiques tels que l’inscription à un abonnement, l’acceptation d’un contrat ou la soumission d’un formulaire juridiquement contraignant. Deuxièmement, elle couvre les transactions financières, y compris les achats, les transferts de fonds, les demandes de prêt et les paiements de factures. Troisièmement, elle couvre toute action qui modifie ou supprime des données contrôlées par l’utilisateur dans un système de stockage de données — par exemple, la mise à jour d’informations de profil, la suppression de fichiers d’un service cloud ou la modification d’enregistrements dans un panneau d’administration.

Un succès ressemble à : un processus de paiement e-commerce qui présente un récapitulatif de commande avec un lien « Modifier » et un bouton « Passer la commande » comme étape finale. Un échec ressemble à : un formulaire d’achat sur une seule page où le clic sur « Acheter maintenant » débite immédiatement la carte sans écran de revue, sans option d’annulation et sans étape de validation.

Le critère comporte une exception définie : il ne s’applique pas aux formulaires pour lesquels la soumission d’informations incorrectes n’a pas de conséquences et peut être répétée très facilement. Les formulaires de contact simples ou les inscriptions à des newsletters sont généralement hors de portée, même si les bonnes pratiques encouragent tout de même la validation sur ces formulaires.

Pourquoi c’est important

Les erreurs lors de transactions à enjeux élevés peuvent avoir des conséquences graves, parfois irréversibles : argent transféré sur le mauvais compte, accord juridique signé sous de faux prétextes, dossiers médicaux mis à jour avec des informations incorrectes, ou abonnement acheté au mauvais niveau. Pour les utilisateurs sans handicap, détecter et corriger ces erreurs est souvent simple. Pour de nombreux groupes de personnes handicapées, cela peut être extrêmement difficile, voire impossible, sans les mesures de protection exigées par ce critère.

Les personnes ayant des handicaps cognitifs — y compris celles ayant une dyslexie, un TDAH, des troubles de la mémoire ou des déficiences intellectuelles — sont plus susceptibles de commettre des erreurs de saisie de données et moins susceptibles de les remarquer avant de cliquer sur envoyer. Un écran de revue leur donne le temps et la clarté nécessaires pour repérer les erreurs. Selon l’Organisation mondiale de la Santé, environ 1 milliard de personnes dans le monde vivent avec une forme de trouble cognitif, neurologique ou de santé mentale qui affecte le fonctionnement quotidien.

Les personnes ayant des déficiences motrices qui s’appuient sur un accès par contacteur, des dispositifs de suivi oculaire ou des claviers alternatifs sont sujettes aux activations accidentelles et aux frappes involontaires. Une étape de confirmation agit comme un tampon critique : même si « Envoyer » est activé par erreur, l’utilisateur a une autre occasion d’annuler avant que la transaction ne soit finalisée. Sans cette mesure de protection, une simple pression accidentelle pourrait déclencher une transaction financière que l’utilisateur ne peut pas annuler.

Les utilisateurs de lecteurs d’écran qui parcourent de longs formulaires de manière linéaire peuvent ne pas avoir une vision globale de ce qu’ils ont saisi. Un récapitulatif vocal à l’étape de confirmation — qui lit les valeurs saisies — leur permet de détecter des erreurs qu’ils ne peuvent pas repérer visuellement.

Les personnes ayant de l’anxiété ou des difficultés d’attention bénéficient énormément du fait de savoir qu’il existe un filet de sécurité. Les recherches montrent de manière constante que lorsque les utilisateurs perçoivent un processus comme tolérant aux erreurs, ils s’y engagent avec plus de confiance et abandonnent moins souvent les transactions. Cela profite directement aux taux de conversion et à la satisfaction des utilisateurs, faisant de la conformité au critère 3.3.4 un avantage commercial autant qu’une obligation éthique.

Scénario réel : Une utilisatrice malvoyante à Istanbul réserve un vol intérieur en utilisant un lecteur d’écran. Elle sélectionne une date mais passe accidentellement le champ du nombre de passagers, le laissant à sa valeur par défaut de deux passagers au lieu d’un. Si le site de réservation débite sa carte au moment où elle active « Confirmer », elle a acheté deux billets et peut être confrontée à des pénalités de tarif non remboursable. Un écran de revue qui lit à voix haute « 1 passager : Ayşe Yılmaz, Ankara vers Istanbul, 14 mars, Économie — Total : ₺850 » lui permettrait de détecter immédiatement l’erreur.

Règles Axe-core associées

Le critère 3.3.4 des WCAG nécessite un test manuel. Aucune règle axe-core automatisée ne correspond directement à ce critère, car les mesures de protection qu’il exige — réversibilité, validation avec possibilité de correction et étapes de confirmation — relèvent du flux applicatif et de la logique métier, et non de la structure du balisage ou des attributs du DOM. Les outils automatisés peuvent analyser le HTML et l’ARIA, mais ils ne peuvent pas déterminer si un bouton « Payer maintenant » déclenche un débit irréversible, si une politique d’annulation existe, ou si les données affichées dans un écran de revue reflètent fidèlement ce qui a été saisi.

• Pourquoi l’automatisation ne peut pas détecter cela : Un analyseur automatisé voit un élément <button> avec le texte « Envoyer » et un balisage valide. Il n’a aucun moyen de savoir si l’activation de ce bouton initie une transaction financière contraignante, si une boîte de dialogue de confirmation suivra, ou si la transaction peut être annulée par la suite. Ce sont des décisions d’architecture et d’UX qui se situent au-dessus du niveau des nœuds DOM individuels et qui nécessitent un testeur humain comprenant l’ensemble du parcours utilisateur.
• Signaux partiels à rechercher lors des analyses automatisées : Bien que axe-core ne signale pas directement les violations du critère 3.3.4, les auditeurs utilisent parfois axe pour identifier des problèmes connexes qui aggravent le risque — tels que l’absence d’attributs autocomplete sur les champs de paiement (pertinent pour 1.3.5), l’absence de messages d’erreur (pertinent pour 3.3.1 et 3.3.3), ou l’absence d’étiquettes sur les contrôles de formulaire (pertinent pour 1.3.1 et 4.1.2). Ces échecs connexes rendent la prévention des erreurs encore plus difficile à atteindre.
• Approche d’audit manuel recommandée : Les testeurs doivent cartographier chaque parcours utilisateur impliquant une soumission juridique, financière ou de modification de données, puis évaluer chaque parcours au regard des trois critères : Existe-t-il un moyen d’annuler l’action ? Y a-t-il une validation en ligne avec possibilité de correction ? Y a-t-il une étape de revue et de confirmation ? L’absence des trois mesures sur un quelconque parcours de ce type constitue un échec au critère 3.3.4.

Comment tester

1. Recenser les formulaires à enjeux élevés : Avant de commencer les tests, dressez une liste de tous les formulaires ou parcours interactifs sur le site qui impliquent des transactions financières (paiement, facturation, encaissement), des engagements juridiques (signature de contrat, souscription d’abonnement, formulaires de consentement) ou la modification/suppression de données (édition de profil, suppression de fichiers, suppression de compte). Ce sont les seuls flux concernés par le critère 3.3.4.
2. Lancer une analyse automatisée pour les problèmes connexes : Utilisez axe DevTools ou Lighthouse pour identifier les échecs d’accessibilité au niveau des formulaires sur chaque page concernée. Bien que ces outils ne signalent pas directement le critère 3.3.4, la résolution de problèmes tels que l’absence d’étiquettes, d’attributs autocomplete ou d’annonces d’erreur établit un niveau de qualité de base des formulaires avant d’évaluer la mesure de prévention des erreurs.
3. Tester la mesure de protection « Vérifiée » : Soumettez délibérément chaque formulaire concerné avec des erreurs intentionnelles — chiffres inversés dans un numéro de carte, date invalide, champ de confirmation d’e-mail non concordant. Observez si le système bloque la soumission, identifie l’erreur spécifique, décrit comment la corriger (conformément à 3.3.3) et maintient l’utilisateur sur le formulaire pour effectuer les corrections. Si le formulaire se soumet silencieusement ou n’affiche qu’une erreur générique sans identifier le champ en échec, cette mesure de protection n’est pas respectée.
4. Tester la mesure de protection « Confirmée » : Remplissez chaque formulaire concerné avec des données valides et parcourez l’intégralité du flux. Vérifiez si une étape de revue est présentée avant la soumission finale. Assurez-vous que l’étape de revue affiche toutes les données saisies dans un format lisible, inclut un mécanisme pour revenir en arrière et modifier, et exige une action finale délibérée pour compléter la soumission. En utilisant NVDA avec Firefox et JAWS avec Chrome, parcourez cette étape de revue avec un lecteur d’écran pour confirmer que toutes les valeurs sont annoncées et que les contrôles de modification et de confirmation sont accessibles au clavier.
5. Tester la mesure de protection « Réversible » : Effectuez une soumission puis tentez de l’annuler. Pour l’e-commerce, recherchez un lien d’annulation dans l’e-mail de confirmation ou sur la page d’historique des commandes. Pour la suppression de données, recherchez un mécanisme de restauration ou de corbeille. Évaluez si la fenêtre de réversibilité est clairement communiquée à l’utilisateur avant la soumission, et pas seulement après.
6. Parcours avec lecteur d’écran (VoiceOver + Safari sur macOS/iOS) : Parcourez l’intégralité du flux de paiement ou de soumission en utilisant uniquement le clavier et VoiceOver. Confirmez que l’écran de revue lit toutes les valeurs saisies dans un ordre logique, que les liens de modification sont annoncés avec un contexte suffisant (par exemple, « Modifier l’adresse de livraison » et non simplement « Modifier »), et que le but du bouton de confirmation final est sans ambiguïté.
7. Vérification de la charge cognitive : Évaluez si l’étape de revue est présentée dans un langage simple. Un récapitulatif qui liste des noms de champs de base de données bruts ou utilise un jargon juridique sans explication peut techniquement constituer un écran de revue mais échouer en pratique pour les personnes ayant des handicaps cognitifs.

Comment corriger

Paiement en une seule étape sans revue — Incorrect

<!-- Problématique : cliquer sur "Complete Purchase" débite immédiatement la carte -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Paiement en une seule étape avec ajout d’une étape de revue — Correct

<!-- Étape 1 : le formulaire collecte les données et les envoie à la page de revue (non finale) -->
<form action='/checkout/review' method='post'>
  <!-- champs de paiement et de livraison -->
  <button type='submit'>Review Order</button>
</form>

<!-- Étape 2 : la page de revue récapitule toutes les données saisies et propose des liens de modification -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Le bouton final est clairement libellé comme l’action contraignante -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Suppression irréversible de données sans confirmation — Incorrect

<!-- Problématique : le bouton de suppression envoie directement la requête sans boîte de dialogue de confirmation -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Suppression irréversible de données avec boîte de dialogue de confirmation — Correct

<!-- Le bouton déclencheur ouvre une boîte de dialogue de confirmation, pas l’action destructive -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Formulaire financier sans validation en ligne — Incorrect

<!-- Problématique : aucune validation, IBAN erroné accepté sans avertissement -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Formulaire financier avec validation et revue — Correct

<!-- Validation en ligne avec aria-describedby pour associer les erreurs -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Envoie vers la page de revue, pas d’exécution directe -->
  <button type='submit'>Review Transfer</button>
</form>

Erreurs courantes

• Utiliser une info-bulle comme mécanisme de « revue » : Afficher les valeurs saisies dans une info-bulle au survol avant le bouton d’envoi ne constitue pas une étape de revue, car les info-bulles ne sont pas accessibles aux utilisateurs uniquement au clavier ou aux utilisateurs de lecteurs d’écran et disparaissent avant que l’utilisateur puisse agir.
• Libeller le bouton final « Continuer » au lieu de décrire l’action : Un bouton portant la mention « Continuer » sur une page de revue ne rend pas clair que le clic finalisera une transaction financière. Le bouton doit décrire sans ambiguïté l’action contraignante, comme « Passer la commande et payer ₺850 » ou « Signer le contrat ».
• Fournir une politique d’annulation uniquement dans les conditions d’utilisation : Enfouir le mécanisme de réversibilité dans un document juridique lié que la plupart des utilisateurs ne liront pas ne satisfait pas à l’exigence de réversibilité. La possibilité d’annuler et la fenêtre pendant laquelle elle est disponible doivent être communiquées dans le flux de transaction lui-même.
• Utiliser window.confirm() comme seul mécanisme de confirmation : Les boîtes de dialogue de confirmation natives du navigateur sont mal prises en charge par certaines technologies d’assistance, ne peuvent pas être stylées pour améliorer la lisibilité et sont bloquées dans certaines configurations de navigateur. Elles ne doivent pas être utilisées comme seule mesure de protection pour les soumissions à enjeux élevés.
• Réinitialiser le formulaire en cas d’échec de validation sans conserver les champs valides : Lorsqu’un formulaire échoue à la validation, effacer tous les champs oblige les utilisateurs — en particulier ceux ayant des déficiences motrices — à ressaisir toutes les données. Seul le champ invalide doit être effacé ou mis en évidence ; toutes les saisies valides doivent être conservées.
• Placer le lien « Modifier » sur la page de revue sans association programmatique : Un lien « Modifier » à côté de chaque groupe de données doit avoir un nom accessible descriptif (par exemple, aria-label='Edit billing address'). Un simple « Edit » répété plusieurs fois est ambigu pour les utilisateurs de lecteurs d’écran qui naviguent par liens.
• Ne pas annoncer l’étape de revue aux lecteurs d’écran : Si la page de revue se charge sans déplacer le focus vers le titre ou une région de résumé, les utilisateurs de lecteurs d’écran peuvent ne pas se rendre compte qu’ils se trouvent sur une page de revue et peuvent activer le bouton d’envoi sans lire le récapitulatif.
• Considérer que le critère ne s’applique qu’aux pages de paiement : La portée inclut tout engagement juridique (inscription à un abonnement, formulaires de consentement, acceptation de contrat) et toute modification de données utilisateur (suppression de fichiers, mise à jour de dossiers médicaux, modification des paramètres de compte). Les développeurs négligent souvent les panneaux d’administration et les pages de paramètres.
• Proposer une réversibilité uniquement par téléphone ou e-mail : Si l’annulation nécessite d’appeler une ligne d’assistance, les personnes ayant des troubles de la parole ou de l’audition peuvent ne pas être en mesure d’accéder au mécanisme de réversibilité. Le parcours d’annulation doit lui-même être accessible — de préférence un flux d’annulation intégré à l’application.
• Ignorer le critère pour les vues web mobiles : Certaines équipes implémentent une étape de revue sur ordinateur de bureau mais utilisent un flux condensé en une seule étape sur mobile pour réduire l’espace écran. Le critère s’applique de manière égale à toutes les tailles de fenêtre d’affichage et ne doit pas être omis dans les implémentations responsives ou web mobiles.

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 un cadre national complet en matière d’accessibilité qui se réfère aux WCAG 2.2 comme norme technique. La Circulaire impose que les services numériques atteignent au minimum la conformité WCAG 2.2 niveau AA, ce qui inclut le critère 3.3.4 Prévention des erreurs (juridiques, financières, données).

Les entités explicitement couvertes par la Circulaire couvrent un large éventail de secteurs. Les institutions et organismes publics sont tenus de rendre tous les services numériques destinés aux citoyens accessibles, y compris les demandes en ligne, les portails d’e-gouvernement et les services d’identité numérique — qui impliquent tous fréquemment des engagements juridiques et des modifications de données. Les banques et institutions financières réglementées par la BDDK (Banking Regulation and Supervision Agency) doivent se conformer, ce qui rend le critère 3.3.4 directement pertinent pour chaque transaction bancaire en ligne, transfert de fonds et demande de prêt qu’elles proposent. Les hôpitaux et établissements de santé exploitant des portails patients numériques, des systèmes de prise de rendez-vous et des dossiers de santé électroniques doivent veiller à ce que toute saisie ou modification de données dans ces systèmes respecte les normes de prévention des erreurs. Les fournisseurs de télécommunications comptant 200,000 abonnés ou plus — y compris Turkcell, Vodafone TR et Türk Telekom — doivent s’assurer que la gestion des abonnements, les changements de forfait et les flux de paiement sont couverts. Les plateformes d’e-commerce, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE) sont également concernées, couvrant une part substantielle des services web transactionnels à fort volume sur le marché turc.

La conformité au critère 3.3.4 n’est pas simplement une case technique à cocher dans ce cadre. Les organisations qui souhaitent obtenir le Erişilebilirlik Logosu (Logo d’accessibilité) délivré par le ministère de la Famille et des Services sociaux doivent démontrer une conformité complète aux WCAG 2.2 AA. Ce logo sert de signal de confiance publique et est de plus en plus attendu par les consommateurs et les organismes d’achat. Le défaut de mise en œuvre de mesures de prévention des erreurs sur les parcours financiers ou juridiques peut entraîner à la fois le refus du logo et d’éventuelles mesures administratives au titre des dispositions d’application de la Circulaire.

Pour les organisations turques des secteurs de l’e-commerce et de la fintech en particulier, le critère 3.3.4 s’aligne étroitement sur les exigences existantes en matière de protection des consommateurs en droit turc. La Loi sur la protection des consommateurs (n° 6502) et la réglementation associée sur l’e-commerce exigent déjà des informations précontractuelles claires et des droits d’annulation pour les contrats à distance. La mise en œuvre d’une étape de revue et de confirmation conforme au critère 3.3.4 des WCAG satisfait simultanément à l’exigence d’accessibilité et à l’obligation de droit de la consommation de présenter des récapitulatifs de commande avant de lier l’acheteur. Cette double conformité fait de l’investissement dans une UX de prévention des erreurs adéquate un effort à forte valeur ajoutée et à faible duplication pour les prestataires de services numériques turcs.