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

What this requires

For web pages that cause legal commitments or financial transactions for the user to occur, modify or delete user-controllable data in data storage systems, or submit user test responses, at least one of:

Reversible: submissions can be reversed.
Checked: data entered is checked for input errors and the user has an opportunity to correct them.
Confirmed: a mechanism is available for reviewing, confirming, and correcting information before finalising.

How AI coding tools fail this

When asked to wire up "Submit order" or "Delete account", AI tools generate a single-click action that fires immediately. There's no confirmation step, no review screen, no undo.

The second pattern: confirmation modals that are easy to dismiss by accident — a large red "Delete" primary action and a tiny "Cancel" secondary, with Enter binding to the destructive button on focus.

The third: account-deletion flows that succeed instantly with no recoverable window. Even if a separate "undo" is documented, the operation has already destroyed data.

Failing examples

One-click destructive action:

<button onClick={deleteAccount}>Delete account</button>

A confirm dialog with Enter bound to delete:

<Dialog>
  <button onClick={confirmDelete} autoFocus>Delete</button>
  <button onClick={cancel}>Cancel</button>
</Dialog>

Passing examples

A review-and-confirm step before submission:

<form action={submitOrder}>
  {/* fields */}
  <button type="button" onClick={previewOrder}>Review order</button>
</form>

// Review screen:
<dl>
  <dt>Items</dt><dd>{items}</dd>
  <dt>Shipping</dt><dd>{shipping}</dd>
  <dt>Total</dt><dd>{total}</dd>
</dl>
<button type="button" onClick={backToEdit}>Edit</button>
<button onClick={submitOrder}>Place order</button>

A destructive action with a type-to-confirm safeguard:

<Dialog>
  <h2>Delete account</h2>
  <p>
    This will permanently delete your account and all associated data.
    Type your email address to confirm.
  </p>
  <input
    value={confirmText}
    onChange={(e) => setConfirmText(e.target.value)}
  />
  <button
    onClick={confirmDelete}
    disabled={confirmText !== userEmail}
  >
    Permanently delete
  </button>
  <button onClick={cancel} autoFocus>Cancel</button>
</Dialog>

Edge cases

Reversible submissions (e.g., an "undo send" window after email submission) satisfy the criterion without a review step.
The three options are alternatives, not all required. Pick whichever fits the action best.
Type-to-confirm is the strongest safeguard for irreversible destructive actions.
Autocomplete and form-save can reduce the chance of input error but don't satisfy the "checked" path alone — explicit validation is needed.
Test responses (online exams) need review-and-confirm before final submission.

How Jeikin handles this

The scanner flags single-step destructive actions (delete buttons, payment-submit buttons) that don't pass through a confirmation route. The dashboard records each finding and tracks the move to a reviewable, confirmable, or reversible flow.

References

W3C — Understanding 3.3.4 Error Prevention (Legal, Financial, Data) (opens in new tab)