For each form that modifies or deletes data, or that submits answers to a test or exam, or whose validation has financial or legal consequences, can the entered data be modified, updated or recovered by the user?
A user submits a bank transfer with an incorrect amount, or accidentally deletes their personal data. Without a safety net, they are stuck. This criterion requires high-stakes forms to provide an escape route.
The scope covers four categories: forms that modify or delete data, those that transmit test or exam answers, and those whose validation carries financial or legal consequences. An order form, a certification test, a contract termination: all fall within the scope.
Three mechanisms satisfy test 11.12.1: allow the user to modify or cancel after submission; let them verify and correct their data before the final step of a multi-step form; or offer explicit confirmation before submission. One is enough.
Test 11.12.2 specifically targets financial, legal, or personal data. It requires either a mechanism for recovering deleted or modified data, or explicit confirmation. These two tests are cumulative: an account deletion form must satisfy both.
2 tests to verify that sensitive data can be confirmed or cancelled
Modification, confirmation or verification mechanism before submission
- Identify all forms that fall into one of these categories:
- Forms that modify or delete existing data
- Forms that transmit answers to a test or exam
- Forms whose validation has financial or legal consequences
- For each form identified, verify that at least one of these three mechanisms is present:
- The user can modify or cancel their action after submission
- In a multi-step form, the user can review and correct their data before the final step
- An explicit confirmation mechanism is provided before submission (checkbox, summary page, additional confirmation step)
- If at least one mechanism is present for each form concerned, the test is validated.
Recovery or confirmation mechanism for financial and personal data
- Identify all forms that modify or delete data of:
- Financial nature (bank details, transactions, rates)
- Legal nature (contracts, legal documents, commitments)
- Personal nature (name, address, password, profile data)
- For each form identified, verify that at least one of these two mechanisms is present:
- A data recovery mechanism: trash bin, history, "Undo" button, delay before permanent deletion
- An explicit confirmation mechanism before the action: explicitly labeled checkbox, summary page, additional confirmation step
- If at least one mechanism is present for each form concerned, the test is validated.
Examples
❌ Non-compliant : Account deletion without confirmation
<form method="post" action="/delete-account">
<button type="submit">Delete my account</button>
</form>A single click triggers permanent deletion. No mechanism allows the user to confirm their intent or recover their data. A distracted user or victim of an accidental click loses their account without recourse. This form fails tests 11.12.1 and 11.12.2.
✅ Compliant : Account deletion with explicit confirmation
<form method="post" action="/delete-account">
<fieldset>
<legend>Confirm account deletion</legend>
<label>
<input type="checkbox" name="confirm" required>
I understand that this action is irreversible and all my data will be permanently deleted.
</label>
</fieldset>
<button type="submit">Permanently delete my account</button>
</form>The checkbox requires the user to read and confirm their intent before submission. The required attribute blocks accidental submission. The button label is explicit about the irreversible nature of the action. This pattern satisfies tests 11.12.1 and 11.12.2 through the explicit confirmation mechanism.
✅ Compliant : Multi-step order form with editable summary
<section aria-label="Step 3 of 3: review your order">
<h2>Review your order before confirming</h2>
<dl>
<dt>Item</dt>
<dd>Premium Subscription — €49.90/month</dd>
<dt>Billing address</dt>
<dd>12 rue de la Paix, 75002 Paris</dd>
</dl>
<a href="/order/step-2">Edit my order</a>
<form method="post" action="/order/confirm">
<button type="submit">Confirm and pay</button>
</form>
</section>The user accesses a complete summary at the final step and can return to correct their data via the edit link. The confirmation button is distinct and clearly labeled. This pattern satisfies test 11.12.1 through verification before final validation in a multi-step form.
Tips and pitfalls
⚠️ window.confirm() is not a valid confirmation mechanism
window.confirm('Are you sure?') is the easy fix found in most audits. This dialog can be disabled by browser extensions, blocked by enterprise policies, and its accessibility is not guaranteed across all browser/screen reader combinations. Prefer a dedicated step in the form or a checkbox with an explicit label.
⚠️ A summary without an edit link is not enough
Displaying entered data on a summary screen satisfies test 11.12.1 only if the user can correct it. A read-only summary without an "Edit" link or back button does not meet the requirement. The user sees their data but is blocked if they made an error.
⚠️ Tests 11.12.1 and 11.12.2 are cumulative
A contract termination form falls under both tests: it has legal consequences (11.12.1) and manipulates personal or legal data (11.12.2). You must verify both. A well-designed explicit confirmation mechanism generally satisfies both simultaneously, but verification must be explicit during the audit.
💡 A grace period is a valid solution for 11.12.2
WCAG technique G99 recommends allowing deleted data recovery. A message like "Your account will be deleted in 30 days — undo" satisfies test 11.12.2 without adding an extra form step. This approach is particularly suited to high-volume user services.
⚠️ Online quizzes and exams are explicitly within scope
An e-learning quiz or online assessment falls within test 11.12.1 scope as soon as it transmits exam answers. The user must be able to review their answers before final submission. If a time limit applies, the verification mechanism must remain accessible for the entire test duration.
⚠️ Search and filtering forms are excluded
A search form, catalog filter, or result sorting form does not modify persistent data and carries no financial or legal consequences. This criterion does not apply. The scope is reserved for high-stakes forms.
Frequently asked questions
How do you audit RGAA criterion 11.12 on data modification in practice?
Identify all forms that delete or modify data (profile, termination, account deletion), e-commerce flows (orders, payments), and evaluation or test forms. For each, submit the form and verify: is there confirmation before the action? An editable summary? A way to cancel after submission? The absence of all three mechanisms constitutes non-compliance.
What alternatives make a single-step form compliant with RGAA criterion 11.12 without a checkbox?
Yes. If the action can be cancelled after submission — for example, an "Undo deletion" button available for 24 hours — test 11.12.1 is satisfied. The checkbox is just one example among other valid mechanisms. What matters is that one of the three mechanisms is present and functional.
When does RGAA criterion 11.12 apply to password modification?
Yes. A password is personal data. Test 11.12.2 applies. A common and valid mechanism: require entry of the old password before authorizing the change, which constitutes a form of explicit confirmation of the user's intent and identity.
How does RGAA criterion 11.12 apply to forms with a third-party payment module?
RGAA evaluates what is perceived by the user in the interface, not the technical implementation. Whether the confirmation logic is managed client-side or via a third-party API: if the user does not see a confirmation or recovery mechanism, the criterion is not satisfied. Third-party payment module integration does not exempt you from this obligation.
When does a display preferences form fall within the scope of RGAA criterion 11.12?
No. Display preferences (theme, language, interface density) do not constitute financial, legal, or personal data under this criterion. The scope is limited to high-stakes data. A form that modifies a postal address or bank details falls within the scope; a form that changes the theme color does not.