Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, les données saisies peuvent-elles être modifiées, mises à jour ou récupérées par l’utilisateur ?
Un utilisateur soumet un virement bancaire avec un mauvais montant, ou supprime par inadvertance ses données personnelles. Sans filet de sécurité, il est bloqué. Ce critère oblige les formulaires à fort enjeu à offrir une sortie de secours.
Le périmètre couvre quatre catégories : les formulaires qui modifient ou suppriment des données, ceux qui transmettent des réponses à un test ou un examen, et ceux dont la validation entraîne des conséquences financières ou juridiques. Un formulaire de commande, un test de certification, une résiliation de contrat : tous entrent dans le périmètre.
Trois mécanismes satisfont le test 11.12.1 : permettre à l’utilisateur de modifier ou annuler après soumission ; lui permettre de vérifier et corriger ses données avant la dernière étape d’un formulaire multi-étapes ; ou lui proposer une confirmation explicite avant la soumission. Un seul suffit.
Le test 11.12.2 cible spécifiquement les données financières, juridiques ou personnelles. Il exige soit un mécanisme de récupération des données supprimées ou modifiées, soit une confirmation explicite. Ces deux tests sont cumulatifs : un formulaire de suppression de compte doit satisfaire les deux.
2 tests pour vérifier que les données sensibles peuvent être confirmées ou annulées
Mécanisme de modification, confirmation ou vérification avant soumission
- Identifiez tous les formulaires qui entrent dans l’une de ces catégories :
- Formulaires qui modifient ou suppriment des données existantes
- Formulaires qui transmettent des réponses à un test ou à un examen
- Formulaires dont la validation entraîne des conséquences financières ou juridiques
- Pour chaque formulaire identifié, vérifiez qu’au moins l’un de ces trois mécanismes est présent :
- L’utilisateur peut modifier ou annuler son action après la soumission
- Dans un formulaire multi-étapes, l’utilisateur peut revoir et corriger ses données avant la dernière étape
- Un mécanisme de confirmation explicite est proposé avant la soumission (case à cocher, page de récapitulatif, étape supplémentaire dédiée)
- Si au moins un mécanisme est présent pour chaque formulaire concerné, le test est validé.
Mécanisme de récupération ou confirmation pour données financières et personnelles
- Identifiez tous les formulaires qui modifient ou suppriment des données à caractère :
- Financier (coordonnées bancaires, transactions, tarifs)
- Juridique (contrats, documents légaux, engagements)
- Personnel (nom, adresse, mot de passe, données de profil)
- Pour chaque formulaire identifié, vérifiez qu’au moins l’un de ces deux mécanismes est présent :
- Un mécanisme de récupération des données : corbeille, historique, bouton « Annuler », délai avant suppression définitive
- Un mécanisme de confirmation explicite avant l’action : case à cocher libellée explicitement, page de récapitulatif, étape supplémentaire dédiée à la confirmation
- Si au moins un mécanisme est présent pour chaque formulaire concerné, le test est validé.
Exemples
❌ Non conforme : Suppression de compte sans confirmation
<form method="post" action="/delete-account">
<button type="submit">Supprimer mon compte</button>
</form>Un clic suffit à déclencher la suppression définitive. Aucun mécanisme ne permet à l’utilisateur de confirmer son intention ou de récupérer ses données. Un utilisateur distrait ou victime d’un clic involontaire perd son compte sans recours. Ce formulaire échoue aux tests 11.12.1 et 11.12.2.
✅ Conforme : Suppression de compte avec confirmation explicite
<form method="post" action="/delete-account">
<fieldset>
<legend>Confirmer la suppression du compte</legend>
<label>
<input type="checkbox" name="confirm" required>
Je comprends que cette action est irréversible et que toutes mes données seront supprimées définitivement.
</label>
</fieldset>
<button type="submit">Supprimer mon compte définitivement</button>
</form>La case à cocher oblige l’utilisateur à lire et confirmer son intention avant la soumission. L’attribut required bloque la soumission accidentelle. Le libellé du bouton est explicite sur le caractère irréversible de l’action. Ce pattern satisfait les tests 11.12.1 et 11.12.2 via le mécanisme de confirmation explicite.
✅ Conforme : Formulaire de commande multi-étapes avec récapitulatif corrigeable
<section aria-label="Étape 3 sur 3 : récapitulatif de votre commande">
<h2>Vérifiez votre commande avant de confirmer</h2>
<dl>
<dt>Article</dt>
<dd>Abonnement Premium — 49,90 €/mois</dd>
<dt>Adresse de facturation</dt>
<dd>12 rue de la Paix, 75002 Paris</dd>
</dl>
<a href="/commande/etape-2">Modifier ma commande</a>
<form method="post" action="/commande/confirmer">
<button type="submit">Confirmer et payer</button>
</form>
</section>L’utilisateur accède à un récapitulatif complet à la dernière étape et peut revenir corriger ses données via le lien de modification. Le bouton de confirmation est distinct et clairement libellé. Ce pattern satisfait le test 11.12.1 par la vérification avant validation finale dans un formulaire multi-étapes.
Astuces et pièges
⚠️ window.confirm() n’est pas un mécanisme de confirmation valide
window.confirm('Êtes-vous sûr ?') est la solution de facilité que l’on retrouve sur la majorité des audits. Cette boîte de dialogue peut être désactivée par des extensions de navigateur, bloquée par des politiques d’entreprise, et son accessibilité n’est pas garantie sur tous les couples navigateur/lecteur d’écran. Préférez une étape dédiée dans le formulaire ou une case à cocher avec un label explicite.
⚠️ Un récapitulatif sans lien de retour ne suffit pas
Afficher les données saisies sur un écran de récapitulatif satisfait le test 11.12.1 uniquement si l’utilisateur peut les corriger. Un récapitulatif en lecture seule, sans lien « Modifier » ni bouton de retour, ne remplit pas l’obligation. L’utilisateur voit ses données, mais reste bloqué s’il a commis une erreur.
⚠️ Les tests 11.12.1 et 11.12.2 sont cumulatifs
Un formulaire de résiliation de contrat relève des deux tests : il a des conséquences juridiques (11.12.1) et manipule des données personnelles ou juridiques (11.12.2). Il faut vérifier les deux. Un mécanisme de confirmation explicite bien conçu satisfait généralement les deux simultanément, mais la vérification doit être explicite lors de l’audit.
💡 Un délai de grâce est une solution valide pour 11.12.2
La technique G99 du WCAG préconise de permettre la récupération des données supprimées. Un message du type « Votre compte sera supprimé dans 30 jours — annuler » satisfait le test 11.12.2 sans alourdir le formulaire d’une étape supplémentaire. Cette approche est particulièrement adaptée aux services à fort volume d’utilisateurs.
⚠️ Les quiz et examens en ligne sont explicitement dans le périmètre
Un QCM de formation e-learning ou une évaluation en ligne entre dans le périmètre du test 11.12.1 dès lors qu’il transmet des réponses à un examen. L’utilisateur doit pouvoir revoir ses réponses avant la soumission finale. Si un délai limite s’applique, le mécanisme de vérification doit rester accessible pendant toute la durée du test.
⚠️ Les formulaires de recherche et de filtrage sont exclus
Un formulaire de recherche, de filtrage de catalogue ou de tri de résultats ne modifie pas de données persistantes et n’entraîne pas de conséquences financières ou juridiques. Ce critère ne s’applique pas. Le périmètre est réservé aux formulaires à fort enjeu.
Questions fréquentes
Comment auditer le critère RGAA 11.12 sur la modification des données en pratique ?
Repérez tous les formulaires qui suppriment ou modifient des données (profil, résiliation, suppression de compte), les tunnels e-commerce (commandes, paiements), et les formulaires d’évaluation ou de test. Pour chacun, soumettez le formulaire et vérifiez : y a-t-il une confirmation avant l’action ? Un récapitulatif corrigeable ? Une possibilité d’annuler après soumission ? L’absence des trois mécanismes constitue une non-conformité.
Quelles alternatives rendent un formulaire mono-étape conforme au critère RGAA 11.12 sans case à cocher ?
Oui. Si l’action peut être annulée après soumission — par exemple, un bouton « Annuler la suppression » disponible pendant 24 heures — le test 11.12.1 est satisfait. La case à cocher n’est qu’un exemple parmi d’autres mécanismes valides. Ce qui compte, c’est qu’un des trois mécanismes soit présent et fonctionnel.
Quand le critère RGAA 11.12 s'applique-t-il à la modification d'un mot de passe ?
Oui. Un mot de passe est une donnée à caractère personnel. Le test 11.12.2 s’applique. Un mécanisme courant et valide : demander la saisie de l’ancien mot de passe avant d’autoriser le changement, ce qui constitue une forme de confirmation explicite de l’intention et de l’identité de l’utilisateur.
Comment le critère RGAA 11.12 s'applique-t-il aux formulaires avec un module de paiement tiers ?
Le RGAA évalue ce qui est perçu par l’utilisateur dans l’interface, pas l’implémentation technique. Peu importe que la logique de confirmation soit gérée côté client ou via une API tierce : si l’utilisateur ne voit pas de mécanisme de confirmation ou de récupération, le critère n’est pas satisfait. L’intégration d’un module de paiement ne vous exonère pas de cette obligation.
Quand un formulaire de préférences d'affichage entre-t-il dans le périmètre du critère RGAA 11.12 ?
Non. Les préférences d’affichage (thème, langue, densité d’interface) ne constituent pas des données à caractère financier, juridique ou personnel au sens de ce critère. Le périmètre est limité aux données à fort enjeu. Un formulaire qui modifie une adresse postale ou des coordonnées bancaires entre dans le périmètre ; un formulaire qui change la couleur du thème n’y entre pas.