Level AA

Applies to pages causing legal commitments, financial transactions, data modification or deletion, or test submissions -- at least one of reversible, checked, or confirmed must hold

3.3.4 Error Prevention (Legal, Financial, Data)

In Plain Language

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) applies to pages that cause legal commitments, financial transactions, modification or deletion of user-controllable data in storage, or submission of user test responses. On those pages, at least one of three safeguards must hold: the submission is reversible; the data is checked for input errors and the user is given a chance to correct them; or a mechanism is available for reviewing, confirming, and correcting the information before finalising the submission[1].

The four trigger scopes are narrow and load-bearing. A profile-photo swap does not trigger 3.3.4; a wire transfer, a contract signature, an account deletion, and a graded-test submission do. 3.3.6 Error Prevention (All) (Level AAA) extends the same three-option rule to all user submissions, regardless of legal or financial consequence[2].

Why It Matters

  • Users with cognitive and learning disabilities are more likely to misread a total, misclick a date, or miss a consequence buried in fine print. A review step surfaces the commitment in one place so the user can catch the mistake before it becomes a chargeback or a legal dispute[1].
  • Screen-reader users cannot always see what they typed -- they hear what the accessibility tree exposes at the moment focus lands. A confirmation page re-announces the submitted values as text, which is the only way the user can verify them without replaying the entire form.
  • Users with motor disabilities trigger accidental activations -- tremor, spasticity, and switch-bounce all produce unintended clicks. A reversible action (soft-delete with undo) or a confirmation dialog neutralises the accidental click before the record is destroyed[1].
  • The mechanism is protection against irreversible consequence, not against typos in general. 3.3.1 Error Identification and 3.3.3 Error Suggestion handle generic input validation; 3.3.4 specifically covers the case where the cost of a mistake is a signed contract, a charged card, or a deleted record.

Examples

Do: Provide a review step before finalizing a purchase

Review Your Order

ItemAnnual subscription
Price$99.00
CardVisa ending 4242
Total$99.00

✔ User can review all details and go back to edit before confirming

<h3>Review Your Order</h3>
<dl class="review-summary">
  <dt>Item</dt><dd>Annual subscription</dd>
  <dt>Price</dt><dd>$99.00</dd>
  <dt>Card</dt><dd>Visa ending 4242</dd>
  <dt>Total</dt><dd>$99.00</dd>
</dl>
<button type="button">Edit order</button>
<button type="submit">Confirm purchase</button>
<!-- Satisfies the "Confirmed" option: -->
<!-- review, correct, then finalise. -->
Don't: Submit a purchase with no review or undo

✘ Single click charges the card -- no review, no undo, no confirmation

<!-- FAILS 3.3.4: a financial transaction -->
<!-- with none of the three options satisfied. -->
<form action="/charge">
  <label for="card">Card number</label>
  <input id="card" type="text">
  <button type="submit">Pay $99.00</button>
</form>
<!-- Not reversible, not checked, not confirmed. -->
Do: Allow users to undo a destructive data action

✔ Deletion is reversible -- user can undo immediately

<div role="alert">
  Record deleted.
  <button type="button">Undo</button>
</div>
<!-- Satisfies the "Reversible" option: -->
<!-- soft-delete with time-limited undo. -->
<!-- The record is not destroyed until -->
<!-- the undo window expires. -->
Don't: Permanently delete data with no confirmation or undo
Tax filing 2024

✘ One click permanently destroys the record -- no confirmation, no undo

<!-- FAILS 3.3.4: deletion of -->
<!-- user-controllable data with -->
<!-- no safeguard on any of the three options. -->
<div class="record">
  <span>Tax filing 2024</span>
  <button onclick="permanentDelete(id)">
    Delete
  </button>
</div>

How to Fix It

  1. Pick which of the three options you are satisfying, per flow. 3.3.4 requires at least one of Reversible, Checked, or Confirmed -- not all three. Decide per transaction which is cheapest to implement correctly, and document it so the next developer does not regress the flow[1].
  2. Confirmed: insert a review page before the irreversible action. Render all submitted values as text (not just as disabled inputs -- disabled controls do not consistently expose their values to assistive technology), pair a "Confirm" submit with an "Edit" link back to the form, and require an explicit activation of Confirm to finalise. This is the default pattern for checkout, contract signing, and wire transfers.
  3. Reversible: soft-delete with a time-bounded undo window. Write a deleted_at timestamp rather than removing the row, expose an Undo control while the window is open, and run a background job that hard-deletes after the window expires. For legal commitments with a statutory cooling-off period (EU distance-selling, some US state contract law), expose a cancel mechanism that matches the statutory window.
  4. Checked: validate the submission and route errors back with field-level messages. Catch the typo before the transaction posts. This option is the weakest of the three on its own -- validation cannot catch the user who meant to buy 10 shares and typed 100 -- so combine it with Confirmed for high-stakes flows.
  5. Use an accessible confirmation dialog for destructive actions. Implement as role="dialog" with aria-modal="true", move focus into the dialog on open, trap Tab inside it, restore focus to the triggering element on close, and wire Escape to cancel. A native <dialog> element with showModal() handles most of this for free.
  6. Do not rely on a disabled button or a countdown as the safeguard. A greyed-out submit button that enables after the user reads a checkbox is not "Confirmed" -- the user still commits with a single activation. Confirmed requires a distinct review view the user can correct from.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data). W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html ↩ ↩ ↩ ↩
  2. [2] W3C (2023). Understanding Success Criterion 3.3.6: Error Prevention (All). W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-all.html ↩