WCAG 3.3.6 : Prévention des erreurs (Tous)

Ce que signifie cette règle

WCAG 3.3.6 — Prévention des erreurs (Tous) est un critère de succès de niveau AAA relevant du principe Compréhensible. Il étend les exigences de 3.3.4 (Prévention des erreurs : juridique, financier, données) pour couvrir toutes les pages qui exigent qu’un utilisateur soumette des informations, que cette soumission implique ou non des engagements juridiques, des transactions financières ou des données personnellement identifiables.

Au cœur de ce critère, il est exigé que, pour toute page web où un utilisateur soumet des informations, au moins une des trois conditions suivantes soit satisfaite :

• Réversible : Les soumissions sont réversibles après coup. L’utilisateur peut annuler, interrompre ou retirer une action dans un délai raisonnable. Par exemple, un message envoyé peut être rappelé, ou un formulaire soumis peut être annulé depuis une file d’attente de confirmation.
• Vérifiée : Les données saisies par l’utilisateur sont vérifiées pour détecter les erreurs de saisie avant la soumission finale, et l’utilisateur a la possibilité de corriger ces erreurs. Cela implique une validation en ligne, des récapitulatifs avant soumission ou des parcours de révision étape par étape.
• Confirmée : Un mécanisme est fourni pour revoir, confirmer et corriger les informations avant que la soumission ne soit finalisée. Il peut s’agir d’un écran de révision, d’une boîte de dialogue de confirmation ou d’un assistant multi-étapes avec une étape finale de révision.

La distinction clé entre 3.3.4 et 3.3.6 est la portée. Le critère 3.3.4 s’applique uniquement aux accords juridiques, aux transactions financières, aux réponses à des tests et aux suppressions de données contrôlées par l’utilisateur. Le critère 3.3.6 élargit cela à chaque page qui exige une quelconque forme de soumission de saisie utilisateur — y compris les formulaires de contact, les inscriptions à des newsletters, les sections de commentaires, les réponses à des enquêtes, les mises à jour de profil, les paramètres de recherche et toute autre saisie de données contrôlée par l’utilisateur.

Ce qui est considéré comme conforme : Un formulaire est conforme s’il met en œuvre au moins un des trois mécanismes ci-dessus de manière cohérente. Une page de confirmation avant la soumission finale, un écran de synthèse avec une option « Modifier », une validation côté client ou côté serveur avec possibilité de corriger les erreurs, ou une fenêtre d’annulation clairement communiquée satisfont tous au critère.

Ce qui est considéré comme non conforme : Un formulaire en une seule étape qui soumet les données immédiatement au clic sur un bouton, sans validation, sans écran de révision et sans mécanisme d’annulation, ne respecte pas ce critère. De même, un formulaire qui valide mais ne donne aucune possibilité de corriger les erreurs avant une nouvelle soumission échoue également.

La spécification WCAG n’exige pas la présence simultanée des trois mécanismes — en satisfaire un seul suffit. Cependant, combiner deux ou trois mécanismes offre une défense en profondeur et répond à un éventail plus large d’utilisateurs et de contextes.

Pourquoi c’est important

La prévention des erreurs n’est pas simplement un confort d’utilisation — c’est une exigence d’accessibilité fondamentale pour les utilisateurs qui présentent un risque accru d’erreurs de saisie en raison d’un handicap ou de limitations situationnelles.

Handicaps cognitifs et troubles de l’apprentissage : Les personnes dyslexiques, avec TDAH ou troubles de la mémoire commettent fréquemment des erreurs typographiques, inversent des chiffres ou perdent le fil de formulaires complexes à plusieurs champs. Sans mécanisme de révision, une adresse e-mail mal saisie dans un formulaire de contact peut signifier une réponse manquée, ou une adresse incorrectement saisie dans un formulaire de livraison peut entraîner la perte de colis. Ce ne sont pas des cas marginaux — selon l’Organisation mondiale de la Santé, environ 1 milliard de personnes dans le monde vivent avec une forme de trouble cognitif ou neurologique qui affecte le fonctionnement quotidien.

Handicaps moteurs : Les utilisateurs ayant des tremblements, une motricité fine limitée, ou qui s’appuient sur un accès par contacteur ou des logiciels de saisie vocale, déclenchent souvent des soumissions de formulaires par accident ou saisissent des caractères involontaires. Une personne atteinte de la maladie de Parkinson qui navigue dans un formulaire complexe avec une interface à contacteur peut soumettre par inadvertance un formulaire incomplet ou incorrect. Sans réversibilité ou étapes de confirmation, ces erreurs deviennent permanentes.

Utilisateurs de lecteurs d’écran : Les personnes aveugles qui naviguent avec JAWS, NVDA ou VoiceOver n’ont pas le même aperçu visuel d’un formulaire complété dont bénéficient les utilisateurs voyants avant la soumission. Un écran de confirmation ou un récapitulatif lu à voix haute par un lecteur d’écran leur offre une dernière chance de vérifier leurs données avant qu’elles ne soient irréversiblement soumises.

Faible littératie numérique et populations âgées : Les personnes âgées et les utilisateurs novices des interfaces numériques sont particulièrement vulnérables aux soumissions accidentelles. Une étape de confirmation avec des résumés en langage simple fournit un filet de sécurité qui réduit considérablement les coûts de support et la frustration des utilisateurs.

Scénario réel : Considérons un portail turc de e-gouvernement où un citoyen remplit un long formulaire bureaucratique pour enregistrer une entreprise. Si le citoyen omet accidentellement un champ obligatoire ou saisit incorrectement son numéro d’identification fiscale et que le formulaire est soumis immédiatement sans étape de révision, il peut ne pas se rendre compte de l’erreur avant de recevoir un avis de rejet officiel quelques jours plus tard. Un simple écran de confirmation affichant toutes les données saisies avant la soumission finale aurait entièrement évité ce problème.

Avantages en SEO et en ergonomie : Les pages qui mettent en œuvre une prévention robuste des erreurs ont tendance à présenter des taux d’abandon de formulaire plus faibles, des taux de conversion plus élevés et de meilleurs scores de satisfaction utilisateur. Les moteurs de recherche prennent de plus en plus en compte les signaux d’expérience utilisateur dans leurs classements, et les pages avec des taux de rebond élevés dus à des erreurs de formulaire souffrent indirectement en visibilité organique.

Règles Axe-core associées

WCAG 3.3.6 nécessite des tests manuels car aucun outil automatisé ne peut déterminer si un flux de soumission de formulaire donné satisfait aux exigences de réversibilité, de vérification des erreurs ou de confirmation de ce critère. Les analyseurs d’accessibilité automatisés comme axe-core peuvent vérifier la présence d’attributs ARIA individuels, de libellés et de messages d’erreur, mais ils ne peuvent pas évaluer la logique globale du flux de soumission, l’existence d’une étape de confirmation ou le caractère réellement fonctionnel d’un mécanisme d’annulation. Le critère concerne fondamentalement la conception de l’interaction et le flux d’expérience utilisateur — pas le balisage statique.

• Il n’existe pas de règle axe-core dédiée pour 3.3.6. Axe-core et des moteurs similaires testent des éléments DOM individuels par rapport à des exigences spécifiques d’attributs ou de rôles. Déterminer si un formulaire multi-pages inclut une étape de révision avant la soumission finale nécessite de comprendre le flux de navigation de l’application et le comportement côté serveur — des informations auxquelles les outils d’analyse statique n’ont pas accès. Un testeur humain doit parcourir l’intégralité du parcours de soumission pour évaluer la conformité.
• Règles associées qui soutiennent la qualité globale des formulaires (bien que pas spécifiquement 3.3.6) : Des règles telles que label (chaque champ de saisie a un libellé associé), aria-required-attr (les attributs ARIA requis sont présents) et form-field-multiple-labels (les champs de saisie n’ont pas de libellés contradictoires) contribuent au socle des formulaires accessibles. S’assurer qu’elles sont satisfaites est un prérequis à une prévention des erreurs significative, mais les respecter ne garantit pas la conformité à 3.3.6.
• Pourquoi l’automatisation est insuffisante : Une analyse automatisée d’une page de paiement peut confirmer que tous les champs de saisie ont des libellés et que les messages d’erreur sont associés de manière programmatique aux champs. Mais elle ne peut pas déterminer si le clic sur « Submit » amène l’utilisateur à un écran de révision, si une option « Cancel » existe, ou si le système envoie un e-mail de confirmation avec un lien d’annulation. Ce sont des questions de comportement et de processus auxquelles seule une évaluation humaine peut répondre.

Comment tester

1. Exécuter une analyse automatisée comme base : Utilisez axe DevTools, Lighthouse ou le mode d’audit intégré du widget Accsible pour analyser toutes les pages contenant des formulaires. Bien que ces outils ne signalent pas directement les violations de 3.3.6, ils établissent une base en identifiant les libellés manquants, l’absence de messages d’erreur ou les retours de validation mal associés. Résolvez tous les problèmes détectés automatiquement avant de passer aux tests manuels.
2. Identifier tous les formulaires de soumission sur le site : Créez un inventaire complet de chaque page qui accepte et soumet des saisies utilisateur — formulaires de contact, formulaires d’inscription, formulaires de connexion, formulaires de préférences de recherche, pages de mise à jour de profil, sections de commentaires, inscriptions à des newsletters et tout assistant multi-étapes. Chacun doit être testé indépendamment.
3. Tester le scénario nominal avec des erreurs intentionnelles : Sur chaque formulaire, saisissez intentionnellement des données incorrectes, incomplètes ou mal formées (par exemple, une adresse e-mail invalide, un numéro de téléphone contenant des lettres, des champs obligatoires laissés vides). Soumettez le formulaire et observez : la page empêche-t-elle la soumission et fournit-elle des messages d’erreur ? Les messages d’erreur sont-ils associés aux bons champs ? L’utilisateur a-t-il une possibilité claire de corriger et de soumettre à nouveau ?
4. Tester les mécanismes de confirmation ou de révision : Pour les formulaires qui passent la validation, complétez le formulaire avec des données valides et soumettez-le. Observez si un écran de confirmation, une boîte de dialogue de synthèse ou une étape de révision apparaît avant que les données ne soient irrévocablement soumises. Vérifiez que l’étape de révision permet à l’utilisateur de revenir en arrière et de modifier les entrées.
5. Tester la réversibilité après soumission : Après une soumission réussie, vérifiez s’il existe un mécanisme d’annulation, de retour en arrière ou de retrait. Il peut s’agir d’un lien « Cancel submission » dans un e-mail de confirmation, d’un écran de gestion de file d’attente dans une zone d’administration ou d’une notification in-app avec une action d’annulation. Vérifiez que le mécanisme fonctionne et qu’il est clairement communiqué aux utilisateurs.
6. Tests avec lecteur d’écran NVDA + Firefox : Naviguez jusqu’à chaque formulaire en utilisant NVDA et Firefox. Parcourez tous les champs avec la touche Tab, saisissez des données et soumettez le formulaire. Vérifiez que les messages d’erreur sont annoncés lorsqu’ils apparaissent, que l’écran de révision (s’il est présent) est entièrement lisible dans l’ordre du document, et que tous les contrôles interactifs (boutons de modification, de confirmation, d’annulation) sur l’écran de confirmation sont accessibles au clavier et correctement étiquetés.
7. Tests avec lecteur d’écran VoiceOver + Safari (macOS/iOS) : Répétez le processus ci-dessus en utilisant VoiceOver sur Safari. Portez une attention particulière aux mises à jour dynamiques de contenu — si les erreurs de validation apparaissent dynamiquement via JavaScript sans rechargement de page, vérifiez qu’elles sont exposées via des régions dynamiques (aria-live) afin que VoiceOver les annonce sans que l’utilisateur ait à explorer manuellement la page.
8. Tests au clavier uniquement : Sans souris, naviguez dans l’intégralité du flux de soumission du formulaire en utilisant uniquement les touches Tab, Maj+Tab, Entrée et Espace. Vérifiez que chaque élément interactif — y compris les boutons de modification, retour, confirmation et annulation sur les écrans de révision — est atteignable et actionnable sans dispositif de pointage.

Comment corriger

Formulaire de contact sans validation ni révision — Incorrect

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Formulaire de contact avec validation et étape de confirmation — Correct

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Assistant multi-étapes sans étape de synthèse — Incorrect

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Assistant multi-étapes avec étape finale de révision — Correct

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Formulaire avec soumission immédiate et sans annulation — Incorrect

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Action destructive avec boîte de dialogue de confirmation — Correct

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Erreurs courantes

• Mettre en œuvre une validation sans l’exposer aux lecteurs d’écran : Afficher des messages d’erreur visuellement via des changements de couleur CSS ou des icônes sans les associer au champ de saisie à l’aide de aria-describedby ou sans les injecter dans une région aria-live signifie que les utilisateurs aveugles n’entendent jamais l’erreur — le formulaire semble avoir été soumis avec succès alors qu’il reste en réalité incomplet.
• Considérer la conformité à 3.3.4 comme suffisante pour le niveau AAA : Les équipes mettent souvent en œuvre la prévention des erreurs uniquement pour les formulaires financiers ou juridiques (satisfaisant 3.3.4) et supposent que tous les formulaires sont couverts. Le critère 3.3.6 exige les mêmes protections pour chaque formulaire du site, y compris les inscriptions à des newsletters, les commentaires et les mises à jour de profil.
• Fournir un écran de confirmation en lecture seule sans possibilité de modification : Une page de révision qui affiche les données soumises mais n’offre qu’un bouton « Confirm » — sans moyen de revenir en arrière et de corriger les erreurs — ne satisfait pas pleinement l’esprit du critère et laisse les utilisateurs sans recours s’ils repèrent une erreur lors de la révision.
• Utiliser window.confirm() comme seul mécanisme de confirmation : Les boîtes de dialogue de confirmation natives du navigateur ne sont pas accessibles à tous les utilisateurs et ne peuvent pas être stylées ou structurées pour plus de clarté. Elles se comportent également de manière incohérente selon les technologies d’assistance. Utilisez plutôt un véritable élément <dialog> avec les attributs ARIA appropriés.
• Réinitialiser l’intégralité du formulaire en cas d’échec de validation au lieu de conserver les entrées valides : Lorsqu’un utilisateur soumet un formulaire de 10 champs avec une seule erreur et que le formulaire efface tous les champs, l’utilisateur doit ressaisir toutes les données. C’est particulièrement pénible pour les personnes ayant des handicaps moteurs ou une fatigue cognitive. Conservez toujours les données valides et concentrez l’attention uniquement sur les champs erronés.
• Placer les messages de synthèse d’erreurs en dehors de la zone d’affichage ou de l’ordre de focus clavier : Une bannière de synthèse d’erreurs injectée en haut de la page après une soumission échouée ne sert à rien pour les utilisateurs qui sont focalisés au milieu du formulaire. Utilisez aria-live='assertive' sur le conteneur de synthèse et déplacez le focus vers celui-ci de manière programmatique en cas d’échec de soumission.
• Marquer les boutons de confirmation avec des libellés vagues comme « OK » ou « Yes » : Sur un écran de révision, les boutons doivent communiquer clairement ce qui va se passer. « Confirm and Send Message » est sans ambiguïté ; « OK » ne l’est pas — en particulier pour les utilisateurs de lecteurs d’écran qui peuvent ne pas disposer du contexte visuel environnant.
• Supposer que la validation côté serveur seule satisfait au critère : Si la validation côté client est absente, chaque soumission nécessite un aller-retour complet vers le serveur avant que l’utilisateur ne prenne connaissance d’une erreur. Les utilisateurs sur des connexions lentes ou qui perdent le réseau en cours de soumission peuvent se retrouver dans un état incertain sans retour d’erreur clair.
• Ne pas tester le mécanisme de réversibilité dans des conditions réalistes : Les équipes implémentent parfois une option « cancel » dans un e-mail de confirmation mais ne testent jamais si le lien d’annulation est accessible, s’il fonctionne après l’expiration de la fenêtre ou s’il est utilisable par les lecteurs d’écran. Un mécanisme d’annulation inaccessible ne satisfait pas au critère.
• Ne pas gérer les cas limites d’auto-complétion dans les écrans de révision : Lorsque l’auto-complétion du navigateur ou d’un gestionnaire de mots de passe remplit les champs de formulaire, les valeurs affichées sur un écran de révision peuvent ne pas correspondre à ce qui a réellement été soumis si le JavaScript qui alimente la révision récupère les valeurs depuis le DOM avant la fin de l’auto-complétion. Récupérez toujours les valeurs immédiatement avant d’afficher l’écran de révision, et non au chargement initial de la page.

Lien avec la réglementation sur l’accessibilité en Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des obligations d’accessibilité numérique obligatoires pour un large éventail d’entités opérant en Turquie. La circulaire exige que les organisations concernées se conforment à WCAG 2.2 au niveau AA comme base. Les entités explicitement couvertes incluent les institutions et agences publiques, les plateformes de e-commerce, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunication comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privées et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

WCAG 3.3.6 est un critère de niveau AAA et n’est donc pas une exigence légale directe au titre de la circulaire 2025/10. Cependant, son importance dans le contexte réglementaire turc ne doit pas être minimisée. Plusieurs des types d’entités couvertes — en particulier les banques, les plateformes de e-commerce et les prestataires de soins de santé — exploitent des formulaires transactionnels à enjeux élevés où la prévention des erreurs n’est pas simplement une bonne pratique mais une nécessité juridique et éthique. Un formulaire de virement en ligne d’une banque turque, un système de prise de rendez-vous d’un portail de santé ou un flux de paiement de e-commerce dépourvu d’étapes de confirmation ou de mécanismes de correction des erreurs peuvent ne pas violer 3.3.6 dans un sens juridiquement contraignant, mais ils créent un risque significatif de préjudice pour les utilisateurs handicapés et exposent l’organisation à un risque réputationnel et opérationnel.

En outre, la circulaire signale une trajectoire claire vers un renforcement progressif des exigences d’accessibilité, conformément au cadre de l’Acte européen sur l’accessibilité (EAA) auquel la Turquie s’aligne. Les organisations qui mettent en œuvre dès aujourd’hui des critères AAA tels que 3.3.6 se positionnent de manière proactive pour un durcissement réglementaire futur et démontrent un engagement en faveur d’une conception inclusive qui va au-delà de la conformité minimale. Pour des entités comme les hôpitaux privés et les institutions financières qui servent des populations vieillissantes ou des utilisateurs présentant des handicaps cognitifs et moteurs à des taux disproportionnellement élevés, la mise en œuvre de 3.3.6 sur tous les formulaires est une décision solide de gestion des risques, indépendamment de son statut juridique. Le SDK de surcouche d’Accsible peut aider à faire remonter les messages d’erreur, à renforcer les états de validation et à fournir des invites de confirmation supplémentaires comme couche de protection renforcée pour les organisations turques qui cherchent à être à la pointe en matière d’accessibilité.