WCAG 3.3.4: Error Prevention (Legal, Financial, Data)

Why error prevention matters

All users make input errors, but users with disabilities make more of them and catch fewer. Someone with a motor impairment may hit an adjacent key or trigger a double-submit; someone with dyslexia may transpose the digits of an account number; a screen reader user cannot visually skim a completed form to sanity-check it the way a sighted user does; a user with a memory limitation may not recall what they entered three steps ago.

For most interactions the cost of a slip is trivial — resubmit the search, re-type the comment. The criterion exists for the interactions where it is not: money leaves an account, a contract binds, data is destroyed, an exam is graded. In those cases, an undetected error is not an inconvenience but a genuine harm, and the interface — not the user’s vigilance — must provide the protection.

The safety nets it mandates are ones good commerce sites already use: order review pages, cancellation windows, undo for deletions, validation with a chance to fix. 3.3.4 turns that good practice into a requirement wherever the stakes are legal, financial, or data loss.

Which submissions are covered

3.3.4 does not apply to every form. It applies to pages that cause any of four kinds of consequence:

A contact form, comment box, or newsletter signup is outside 3.3.4’s scope (its cousins 3.3.1 and 3.3.3 still govern its error messages). The AAA criterion 3.3.6 extends the same protections to all submissions — at AA, focus on the four categories above.

The three ways to conform

Satisfy any one of these for each covered submission:

1. 1

   Reversible — the action can be undone

   Provide a way to reverse the submission after the fact: a cancellation window for orders, a 'trash' stage before permanent deletion with a documented recovery period, an undo for destructive edits. Reversibility is strongest for data operations; genuinely irreversible events (a sent payment, a graded exam) usually need one of the other two options instead.

2. 2

   Checked — input is validated, with a chance to correct

   Check the entered data for input errors — malformed account numbers, impossible dates, missing required fields, amounts outside plausible bounds — and give the user the opportunity to fix them before the action completes. Error messages must satisfy 3.3.1 (identified in text) and ideally 3.3.3 (suggest a correction).

3. 3

   Confirmed — review before it becomes final

   Insert a review step that shows the user exactly what is about to happen — the actual data: items, amounts, recipient, the records to be deleted — with an explicit way to go back and correct it, before a clearly labelled final action ('Place order and pay', 'Permanently delete account').

Pass and fail examples

Code examples

Direct submit vs. a real review step

The “confirmed” option means showing the user their actual data before the final action — not just interposing a second button.

<!-- ✗ The first click is the final, charging action -->
<form action="/api/checkout" method="post">
  …payment fields…
  <button type="submit">Buy now</button>
</form>

<!-- ✓ A review page echoes the data, with a way back -->
<main>
  <h1>Review your order</h1>
  <h2>Items</h2>
  <ul>
    <li>Ergonomic keyboard — 1 × $89.00</li>
  </ul>
  <h2>Deliver to</h2>
  <p>Jane Doe, 42 Main St, Springfield
     <a href="/checkout/address">Edit address</a></p>
  <h2>Payment</h2>
  <p>Visa ending 4242 — total $96.12
     <a href="/checkout/payment">Edit payment</a></p>

  <form action="/api/checkout/confirm" method="post">
    <button type="submit">Place order and pay $96.12</button>
  </form>
  <a href="/checkout">Back to checkout</a>
</main>

A deletion that is reversible — and says so

For data operations, reversibility is often the cleanest option: a trash stage plus an immediate, focusable undo.

<!-- ✗ Instant, permanent, and vague -->
<button onclick="if(confirm('Are you sure?')) destroyForever(id)">
  Delete
</button>

<!-- ✓ Soft delete with a recovery window and announced undo -->
<button type="button" data-action="move-to-trash" data-id="prj_81">
  Delete project
</button>

<div role="status" class="toast">
  “Marketing site” moved to Trash. Items in Trash are kept
  for 30 days.
  <button type="button" data-action="undo">Undo</button>
</div>

Checked: validate, describe, let the user fix it

The “checked” option pairs validation with an accessible error message and returns control to the user instead of finalizing.

<form action="/api/transfer" method="post" novalidate>
  <label for="iban">Recipient IBAN</label>
  <input id="iban" name="iban" inputmode="text"
         autocomplete="off"
         aria-describedby="iban-error" aria-invalid="true" />
  <p id="iban-error" class="error">
    This IBAN fails its checksum — one digit may be mistyped.
    Compare it with the recipient's details and correct it.
  </p>

  <label for="amount">Amount (USD)</label>
  <input id="amount" name="amount" inputmode="decimal" />

  <!-- Submission is blocked until errors are corrected;
       nothing is transferred while aria-invalid fields remain. -->
  <button type="submit">Continue to review</button>
</form>

Common failures

• ✗A financial or legal submission that completes on the first click, with no review step, no validation opportunity, and no way to reverse it.
• ✗A confirmation dialog that names nothing — 'Are you sure? OK / Cancel' — so the user confirms an action they cannot actually review or correct.
• ✗Permanent deletion of user data with no trash stage, no undo, and no confirmation that shows what will be destroyed.
• ✗A review page that displays the data but offers no way back to correct it — 'confirming' without the required correcting.
• ✗Validation that silently rejects or 'corrects' input without telling the user, finalizing a submission that differs from what they intended.
• ✗Timed test submissions that auto-finalize mid-answer without warning and without any of the three protections (this also implicates 2.2.1 Timing Adjustable).

How to test for 3.3.4

1. 1

   Find the covered submissions

   Inventory every flow that creates a legal commitment, moves money, modifies or deletes stored user data, or submits test answers: checkout, payments, transfers, plan changes, account closure, bulk deletes, e-signatures, exams.

2. 2

   Walk each flow to the point of no return

   Complete the flow in a test environment and note the exact step where the action becomes final. Everything before that step is where a check or confirmation must live; everything after is where reversal would apply.

3. 3

   Verify at least one protection exists

   For each flow, confirm one of: the finished action can genuinely be reversed (try it); input errors are detected with a real opportunity to correct them; or a review step shows the actual data with a working path back to edit before the final, clearly labelled action.

4. 4

   Test the protection with assistive technology

   Run the review or error step with a screen reader and keyboard only. The summary must be readable in sequence, error messages must be announced and associated with their fields (3.3.1), and the 'go back and edit' path must be keyboard-operable.

5. 5

   Probe the edge cases

   Deliberately submit wrong data: a bad account number, an implausible amount, a double-click on the final button. Confirm the system catches it or the mistake is recoverable — and that the promised reversal window actually works.

This is flow-level, manual testing — no scanner can judge whether an order is reversible. Audit it alongside the rest of Guideline 3.3 in the full WCAG 2.2 checklist.

Frequently asked questions