WCAG 3.3.4 Error Prevention (Legal, Financial, Data) is a Level AA rule that protects users from costly, hard-to-undo mistakes. For any page that creates a legal commitment or financial transaction, modifies or deletes saved data, or submits test answers, the submission must be reversible, checked for errors, or confirmable before it finalizes.
What WCAG 3.3.4 requires
The official criterion applies “for web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses.” For those pages, at least one of the following must be true:
- Reversible — Submissions are reversible.
- Checked — Data entered by the user is checked for input errors and the user is given an opportunity to correct them.
- Confirmed — A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
You only need one of the three. A retailer can satisfy 3.3.4 with a single order-review screen; a bank might rely on a stated cancellation window instead. High-stakes actions should never be a silent, irreversible one-click event.
It applies narrowly. Buying something, signing an agreement, placing a trade, deleting your saved address, or submitting graded exam answers are covered. A search box, a newsletter opt-in, or a blog comment are not — those still need labels and instructions (3.3.2) and error identification (3.3.1), but not the heavier 3.3.4 safeguard.
Who it affects
Per the W3C, the intent is to help “users with disabilities avoid serious consequences as the result of a mistake when performing an action that cannot be reversed.” People with disabilities are statistically more likely to trigger an unintended submission:
- Reading and cognitive disabilities (dyslexia, ADHD) — users may transpose digits in a card number or misread a confirmation prompt, and a review step gives them a second look.
- Motor disabilities — someone using a switch, head pointer, or who experiences tremor may hit Enter or fire a “Delete account” button by accident; a confirmation interrupt prevents the irreversible action.
- Screen reader users (JAWS, NVDA, VoiceOver) — a “Place order” button that submits silently with no announced summary leaves a blind user unsure what just happened, or whether the quantity they meant to change actually changed.
- Low vision and older users — magnification crops the viewport, so a final review screen that re-states the totals catches mistakes a 200%-zoomed user could not see in context.
Concrete failures and how to fix them
3.3.4 failures are about missing safeguards, not broken HTML, so automated scanners rarely catch them. These are the patterns we fix during remediation.
Failure 1 — One-click checkout with no review. A “Buy now” button submits payment instantly with no chance to verify the address, quantity, or card. There is no reversal, no review, and validation only fires on the server after charging.
The fix is the Confirmed path: an order-review step the user must pass through.
<!-- Order review step before the irreversible submit -->
<form action="/place-order" method="post">
<h2>Review your order before you buy</h2>
<ul>
<li>Item: Wool Coat (M) × 1 — $189.00</li>
<li>Ship to: 14 Oak St, Austin, TX 78701 <a href="/cart/address">Edit</a></li>
<li>Pay with: Visa ending 4242 <a href="/cart/payment">Edit</a></li>
</ul>
<button type="submit">Confirm and place order</button>
</form>The “Edit” links make it correctable, the summary makes it reviewable, and the explicit “Confirm” button makes it confirmed.
Failure 2 — A destructive button with no confirmation. “Delete my account” or “Cancel subscription” deletes user-controllable data on a single click with no interrupt. This is the textbook case for technique G168 (request confirmation to continue).
<button type="button" aria-haspopup="dialog" data-confirm>
Delete account
</button>
<!-- Opens an accessible dialog -->
<div role="alertdialog" aria-modal="true" aria-labelledby="del-title">
<h2 id="del-title">Permanently delete your account?</h2>
<p>This removes all saved data and cannot be undone.</p>
<button type="button">Cancel</button>
<button type="submit">Yes, delete permanently</button>
</div>Use role="alertdialog" so screen readers announce the warning, move focus into the dialog, and trap focus until the user chooses. A native confirm() also works but is harder to style and announce consistently.
Failure 3 — A legal agreement that submits without acknowledgment. A loan application, lease, or terms-of-service contract posts with no deliberate confirm. Technique G155 (provide a checkbox in addition to a submit button) is the simplest fix.
<label>
<input type="checkbox" name="agree" required>
I have reviewed and agree to the loan terms above.
</label>
<button type="submit">Sign and submit application</button>The required checkbox forces a separate, intentional acknowledgment step, so submission is never the default action.
Failure 4 — Payment fields that reject input but offer no correction. The card field fails server-side, the page reloads blank, and the user cannot tell what was wrong. The Checked path requires that input errors are surfaced with a chance to correct them — keep the entered values, identify the field in text (not color alone), and describe the fix, ideally inline before submission.
How to test for 3.3.4
Because tools cannot judge intent, test by hand on each transactional flow:
- List the trigger pages. Checkout, payment, account-data edit/delete, contract or e-signature, and any graded test. Only these need 3.3.4.
- For each, find the safeguard. Ask: can I undo this (a real reversal or stated cancellation window), is my input checked with a chance to fix, or is there a review/confirm screen? If none of the three exists, it fails.
- Drive it with the keyboard only. Tab to the final action. Can you reach a review step or confirmation, and is the confirm dialog focus-trapped and dismissible? This overlaps with keyboard navigation (2.1.1).
- Listen with a screen reader. Confirm the review summary, the confirmation dialog (
role="alertdialog"), and any error messages are announced — see our screen readers guide. - Try to make a mistake. Submit a wrong card or a deletion, and verify you are warned or can recover before the consequence is locked in.
Real-world and legal relevance
3.3.4 lives exactly where the money and the lawsuits are. UsableNet reported over 4,000 ADA digital-accessibility lawsuits in 2024, with 77% targeting ecommerce — and ecommerce litigation centers on the cart and checkout, the precise flows 3.3.4 governs. Filings stayed high through 2025, with website accessibility cases making up roughly 36% of all ADA Title III federal filings.
Courts and the DOJ point to WCAG 2.1 AA — which includes 3.3.4 — as the practical benchmark for an accessible site under ADA Title III, and the W3C maintains the official criterion at w3.org/WAI. A demand letter is far easier to write when a tester can show that a blind user completed a $400 purchase with no announced review and no way to undo it. This is general information, not legal advice — consult a qualified attorney about your specific exposure.
The practical upside is that 3.3.4 fixes are cheap and high-leverage: one well-built review screen or confirmation dialog covers an entire checkout. Curbcut does this as hands-on code, never an overlay widget — overlays cannot add a meaningful confirmation step to your transaction logic. To see where your transaction pages stand, start with a free scan and we will show you which flows are missing a safeguard, then build it for you.