WCAG 3.3.6: Error Prevention (All)
At Level AA, WCAG protects users from irreversible mistakes on legal and financial forms. This criterion asks a simple question: why only those? Every submission of user information must be reversible, checked for errors, or confirmable before it is finalized. One safety net, three ways to weave it, applied everywhere.
The success criterion, in full
For Web pages that require the user to submit information, at least one of the following is true:Reversible — Submissions are reversible.Checked — Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.Confirmed — A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
“At least one” is the operative phrase — pick the mechanism that fits the form. The only scoping condition is that the page requires the user to submit information; there are no carve-outs by topic or stakes at this level.
Who this helps
Input errors are universal, but the ability to notice and recover from them is not. The criterion levels that field:
People with motor disabilities
Tremor, fatigue, or switch access make mis-keys and accidental activations routine. A review step or undo means a slipped finger is a nuisance, not a consequence.
People with dyslexia and dyscalculia
Transposed letters and digits (0161 vs 0611) are hard to self-detect. Validation that checks plausibility, and review screens that present data in a fresh format, both catch what proofreading misses.
People with cognitive and memory disabilities
Multi-field forms tax working memory; the wrong date or option may feel right in the moment. An explicit confirmation pass externalizes the checking the brain could not do inline.
Screen reader and magnification users
There is no at-a-glance final scan of a form when you experience it one field at a time. A structured review page rebuilds that overview in an accessible, linear form.
Reversible, checked, confirmed — choosing your mechanism
- Reversible suits destructive or dispatching actions: deletions that go to a recoverable trash, sent messages with an undo window, cancellable orders. The undo path must be discoverable and give users enough time to use it.
- Checked suits everyday forms: validate the input (formats, ranges, required fields, plausibility), report errors accessibly, and let the user correct and resubmit. Checking must be paired with the opportunity to fix — validation that simply rejects is not enough.
- Confirmed suits consequential or multi-step submissions: before finalizing, show everything the user entered on a review screen with working “change” links, then require an explicit confirm action. A checkbox (“I have reviewed my information”) before the submit button is the minimal version for single-step forms.
Note that validation cannot catch everything — a mistyped but valid phone number sails through any checker. That is why review steps and reversibility matter even on forms with excellent validation: the three mechanisms cover different classes of error, and the criterion lets you choose the one matching the risk.
Pass and fail examples
✓ Passes 3.3.6
- A support-ticket form that validates each field and lists any errors with links back to the fields (checked).
- A survey ending on a “Review your answers” page with an Edit link beside every response (confirmed).
- Deleting a photo moves it to a trash folder recoverable for 30 days (reversible).
- A comment box whose posted comments carry Edit and Delete controls for the author (reversible).
✗ Fails 3.3.6
- An RSVP form that submits instantly with no validation, no review, and no way to change the response afterwards.
- A profile editor that saves on every keystroke with no undo and no confirmation of the final state.
- A “Delete account” button that acts immediately — irreversible, unchecked, unconfirmed.
- Validation that rejects a submission but wipes the form, giving no real opportunity to correct (fails the spirit of “checked” and 3.3.1 besides).
Code examples
Checked: accessible validation with a correction path
Report errors in an announced summary that links to each field, keep the user’s input intact, and identify errors in text (per 3.3.1).
<div role="alert" tabindex="-1" id="error-summary" hidden>
<h2>There are 2 problems with your submission</h2>
<ul>
<li><a href="#email">Email address is missing an @ sign</a></li>
<li><a href="#date">Event date must be in the future</a></li>
</ul>
</div>
<label for="email">Email address</label>
<input id="email" type="email" aria-describedby="email-error"
aria-invalid="true" value="jamie.example.com" />
<p id="email-error" class="error">
Enter an email address in the format name@example.com
</p>Confirmed: a review step before finalizing
<h1>Check your answers before submitting</h1>
<dl>
<div>
<dt>Full name</dt>
<dd>Jamie Rivera</dd>
<dd><a href="/apply/name">Change<span class="sr-only"> full name</span></a></dd>
</div>
<div>
<dt>Date of birth</dt>
<dd>4 July 1990</dd>
<dd><a href="/apply/dob">Change<span class="sr-only"> date of birth</span></a></dd>
</div>
</dl>
<form action="/apply/submit" method="post">
<button type="submit">Confirm and submit application</button>
</form>Reversible: a real undo window
Announce the undo, give it generous time, and expose a persistent recovery route (a trash folder) for users who miss the toast.
<div role="status" class="toast">
Item moved to trash.
<button type="button" onclick="undoDelete('item-42')">Undo</button>
</div>
<script>
// Soft-delete: flag now, purge later. The trash page offers
// "Restore" for 30 days, so recovery never depends on
// catching a transient toast.
async function undoDelete(id) {
await fetch(`/api/items/${id}/restore`, { method: "POST" })
document.querySelector(".toast").textContent = "Item restored."
}
</script>Common failures
- Ordinary forms — comments, RSVPs, settings, tickets — that submit irrevocably with no validation, review, or undo, because 'it's not a financial form'.
- Destructive actions (delete, unsubscribe, cancel) that execute immediately and permanently on a single click.
- Validation that rejects the submission but discards everything the user typed, forcing full re-entry instead of correction.
- Review pages whose 'Change' links lose the rest of the entered data, punishing the user for reviewing.
- Undo offered only as a 2-second toast with no persistent recovery path — technically reversible, practically not.
- Confirmation dialogs that don't display the data being confirmed, reducing 'review and confirm' to a reflex click.
- Auto-submitting the form when the last field is filled, removing the user's explicit submit moment entirely (also a 3.2.2 problem).
How to test for 3.3.6
- 1
Inventory every submission on the page
Forms, comment boxes, settings toggles that persist, delete buttons, multi-step wizards. Anything that sends user information somewhere is in scope — not just the checkout.
- 2
For each, identify which of the three mechanisms applies
Is it reversible (find the undo/restore path)? Checked (submit bad data and see what happens)? Confirmed (look for the review step)? At least one must be demonstrably present.
- 3
Submit deliberately wrong data
Type an impossible date, a malformed email, digits in a name field. Verify errors are detected, described in text, associated with their fields, and that your other input survives for correction.
- 4
Exercise the confirmation path end to end
On review screens, use every Change link and verify data persists; confirm with a screen reader that the review content and the confirm control are properly announced.
- 5
Attempt to reverse what claims to be reversible
Delete, then restore. Send, then undo. Time the window and check a persistent route (trash, history, cancellation page) exists for users who need longer than a toast.
This is flow testing, not markup linting — automated tools cannot tell whether an undo exists. Work it into your WCAG 2.2 checklist alongside the rest of the 3.3.x cluster.
Relationship to 3.3.4 and the Input Assistance cluster
3.3.6 is 3.3.4 Error Prevention (Legal, Financial, Data) (AA) with the scope limit removed: identical reversible / checked / confirmed options, applied to every information submission instead of only high-stakes ones. If your design system bakes validation and review patterns into its standard form components, the jump from AA to AAA here costs almost nothing.
The rest of Guideline 3.3 supplies the machinery: 3.3.1 Error Identification (A) makes detected errors visible in text, 3.3.3 Error Suggestion (AA) requires fixes to be suggested, 3.3.2 Labels or Instructions (A) and 3.3.5 Help (AAA) prevent errors upstream. Together they describe one lifecycle: help users enter data correctly, catch what goes wrong, explain it, and make nothing irreversible by accident.
Frequently asked questions
What does WCAG 3.3.6 Error Prevention (All) require?
For any web page that requires the user to submit information, at least one of three things must be true: the submission is reversible (it can be undone), the data is checked for input errors and the user gets a chance to correct them, or a mechanism lets the user review, confirm, and correct the information before finalizing. It is a Level AAA success criterion under Guideline 3.3 Input Assistance. You need one of the three per submission, not all three.
How is 3.3.6 different from 3.3.4 Error Prevention (Legal, Financial, Data)?
The requirement — reversible, checked, or confirmed — is identical. The difference is scope. 3.3.4 (Level AA) applies only to high-stakes submissions: legal commitments, financial transactions, modifications or deletions of user-controllable data, and test responses. 3.3.6 (AAA) applies the same protection to every page that requires submitting information: comments, profile edits, RSVPs, search preferences, support tickets — all of it. If you meet 3.3.6, you have met 3.3.4 automatically.
Do I need reversible AND checked AND confirmed to pass?
No — any one of the three per submission satisfies the criterion. In practice they suit different situations: 'checked' (inline validation plus the chance to fix) fits low-stakes forms; 'confirmed' (a review step) fits multi-field or consequential submissions; 'reversible' (undo, cancellation windows, soft-delete) fits destructive actions. Many well-designed flows layer two of them anyway — validation plus a review page — but one is enough for conformance.
Does a browser 'Are you sure?' dialog count as a confirmation step?
A native confirm() dialog can technically provide a confirmation opportunity for a simple action like a deletion, but it is weak: it usually restates nothing (the user cannot review what they typed), and it trains users to click through. A real review step shows the actual data — 'You are about to post this comment / delete these 3 files' — with edit and cancel paths. For anything beyond a single obvious action, prefer a genuine review-and-confirm page or an undo window over a reflexive dialog.
What does 'reversible' mean concretely on the web?
The action can be undone after submission. Patterns include: soft-deletion with a trash folder and a restore option, an undo toast with a genuine grace period ('Message sent — Undo'), an order cancellation window before fulfillment starts, and edit/withdraw controls on posted content. The reversal path must be findable and usable — an undo that exists only in an unannounced toast that vanishes in two seconds does not meaningfully make the action reversible for people who need more time.
Who benefits most from 3.3.6?
Everyone makes input errors, but the criterion exists because some users cannot reliably catch their own. People with motor disabilities mis-hit keys and controls; people with dyslexia transpose characters and numbers; people with cognitive disabilities, memory impairments, or attention difficulties may not notice a wrong field until after submitting; screen reader users can't visually scan the whole form one last time before pressing submit. A check, a review step, or an undo converts each of those slips from a permanent consequence into a correctable moment.
Related Success Criteria
Input errors are automatically detected and described to the user.
Labels or instructions are provided when content requires user input.
Input error suggestions are provided when errors are detected.
Important transactions can be reversed, checked, or confirmed.
Context-sensitive help is available.