A11y 101 – 3.3.4 Error Prevention

Imagine buying a car. You sign a contract. Then you discover the dealership changed the interest rate after you clicked “Accept.” Or you transfer money to a bank account. You confirm the transaction. Then you realize you sent it to the wrong person—and the funds are gone.

These aren’t typos. These aren’t forgotten passwords. These are consequential actions with legal, financial, or irreversible data implications.

And if your interface doesn’t protect users from making these mistakes, you’re not just violating WCAG—you’re exposing yourself to liability.

That’s the core of WCAG 3.3.4: Error Prevention. Unlike 3.3.3, which is about helping users fix field-level validation errors, 3.3.4 is about preventing catastrophic mistakes before they happen.

The Requirement, With Stakes

When a page causes one of the following:

The user must have at least one of three protections:

1. Reversible — they can undo the action afterward
2. Checked — errors are validated before submission
3. Confirmed — they review and confirm their choices before committing

If none of these exist for high-stakes submissions, you fail. And you’ve probably opened yourself to risk.

Why 3.3.4 Is Different From 3.3.3

I want to be crystal clear on this, because teams conflate them all the time.

Criterion	Scope	Stakes	Protection Needed
3.3.3 Error Suggestion	Any input error	Low to medium	Suggest a fix
3.3.4 Error Prevention	Submissions with consequences	High (legal, financial, data)	Prevent the mistake entirely

3.3.3 handles “you forgot a number in your phone.” 3.3.4 handles “you authorized a $50,000 wire transfer.”

Different universe.

The Legal Reality

Let’s talk about liability for a minute, because this is where the rubber meets the road.

Consumer protection laws increasingly assume digital consent. The FTC has brought enforcement actions against companies that use dark patterns to trap users into subscriptions. Courts have ruled on cases where “clickwrap” agreements lacked meaningful review opportunities. In some jurisdictions, electronic signatures carry less weight if the user didn’t have a chance to verify terms before signing.

Accessibility gaps amplify liability.
They turn a design flaw into a legal defense.

Now add accessibility into that mix. If a screen reader user submits a contract without understanding what they’re agreeing to—and you didn’t provide a way to review the terms in an accessible format—could that signature be invalidated? Could you face a discrimination claim? The answer is yes.

This isn’t theoretical. It’s already happening.

The Financial Cost

Beyond legal exposure, there’s the direct financial impact.

Or imagine an e-commerce checkout that charges the wrong amount and gives no way to cancel the order. Now you’re dealing with refunds, chargebacks, and reputational damage.

Then we add the accessibility multiplier. If a blind user completes a purchase by accident because the review step wasn’t announced by their screen reader, you’re now liable under both consumer protection law and disability discrimination statutes.

One double-blind form can turn into a six-figure settlement.

Code Patterns: Building in Protection

Here’s how you implement 3.3.4 in practice. The key is choosing at least one of the three required protections:

Option 1: Confirmation Step

<!-- Review Page Before Final Submission --> 
<div id="reviewStep"> 
<h2>Review Your Order</h2> 
<table> <thead> 
<tr><th>Item</th><th>Quantity</th><th>Price</th></tr> </thead> 
<tbody> 
<tr><td>Laptop</td><td>1</td><td>$1,299</td></tr> 
</tbody> </table> 
<p>Total: <strong>$1,299</strong></p> 
<p>Billing Address: <strong>123 Main St, Boston, MA 02108</strong></p> 
<button type="button" onclick="window.history.back()">Back and Edit</button> 
<button type="submit" form="checkoutForm">Confirm Purchase</button> 
</div> 
<form id="checkoutForm" hidden> <!-- Hidden fields carrying all the data --> <input type="hidden" name="items" value='[...]'> <input type="hidden" name="billingAddress" value="..."> </form>

This is the gold standard. User sees everything before committing. If anything’s wrong, they go back.

Option 2: Validation Before Commitment

// Before submitting financial transaction async function 
submitPayment() { const result = await validateTransaction();       if (!result.isValid) { // Block submission with detailed error showError(result.errors); return; // Stop here, don't proceed } // Only proceed if validation passes await processPayment(); }

If errors exist, the submission never happens. The user fixes them first.

Option 3: Reversibility

<!-- Transaction confirmation with cancellation window --> <p>Your transfer has been initiated.</p> 
<p>You have 60 minutes to cancel this transaction.</p> <button type="button" onclick="cancelTransfer()">Cancel Transfer</button>

The action goes through, but there’s a safety net. User can undo if they change their mind.

Common Failures (The Expensive Ones)

These are the patterns I see that trigger lawsuits, not just accessibility complaints:

• No Review Before Payment: “Buy Now” button immediately charges without showing order summary.
• Irreversible Deletion: “Are you sure?” dialog exists, but screen readers don’t announce the danger level or provide a way to navigate back.
• Hidden Terms: Contract terms buried in a link that isn’t focused properly, with no requirement to or ability to scroll through before accepting.
• Default Opt-In: Subscription checkboxes pre-checked, with no accessible indication that you’re signing up for recurring billing.

Each one is a vulnerability waiting to be exploited—either by accident or by someone who finds out they can contest the transaction.

Compounding the Problem

Now, factor accessibility onto these patterns, because that’s where the risk compounds.

If your confirmation page relies on hover states to show details, screen reader users miss that context entirely. If your “review” text is styled as a heading but not semantically marked up as one, someone navigating by headings skips right past the warning. If your confirmation button has a focus indicator but no clear “submit” label, the user might click without knowing what they’re approving.

Accessibility gaps amplify liability. They turn a design flaw into a legal defense.

The Hard Truth

When we design systems that allow users to make irreversible mistakes, we’re betting against them. We’re saying, “Trust us, you won’t mess up. Or if you do, it’s on you.”

That’s not just negligent design. It’s predatory.

Especially for users with cognitive disabilities, memory issues, or situational impairments—stress, fatigue, distraction—confirmation steps aren’t annoyance. They’re safeguards.

And especially for users relying on assistive technologies—confirmation pages need to be fully accessible, with clear structure, readable text, and navigation that works.

Giving people a chance to review isn’t just accessibility. It’s due diligence.

3.3.4 isn’t about validation. It’s about consequence.

Before a user hits “submit” on anything with real-world weight—money, data, legal obligations—they need protection. A review step. A confirmation dialog. A way to undo. Remember–Reversible, Checked, Confirmed!

If you don’t build that in, you’re not cutting corners. You’re opening doors to liability.

Design with reversibility in mind. Design with review in mind. Design with accountability in mind.

Because when things go wrong, “we didn’t warn them” isn’t a defense. It’s an admission.

Want to discuss this more? find me on LinkedIn and Bluesky!