3.3.4 Error Prevention (Legal, Financial, Data)
- Level AA
- Understandable
- Since WCAG 2.0
Summary
Some submissions cannot be shrugged off. Placing an order, signing a contract, deleting saved data, or submitting a test are actions with consequences, and people with disabilities are disproportionately likely to trigger them by accident: a screen reader user activating the wrong button, someone with a tremor double-tapping "confirm", a person with a cognitive disability mistyping an account number they cannot easily verify. This criterion, at Level AA since WCAG 2.0, requires a safety net around exactly these high-stakes submissions.
The auditor's mental model has two steps. First, scope: does this page or screen create a legal commitment or financial transaction, modify or delete user-controllable stored data, or submit test responses? If not, the criterion does not apply, however sloppy the form is. Second, if it does apply, at least one of three protections must be present: the submission is reversible (including a cancellation window), the entered data is checked and correctable, or a review-and-confirm step sits before the final commit. One is enough; you are grading the submission's safety net, not the quality of individual field validation.
Official wording
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, at least one of the following is true:
Reversible: Submissions are reversible.
Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
EN 301 549 mapping
- Web pages
- Clause 9.3.3.4
- Software and native apps
- Clause 11.3.3.4 (via Table 11.11)
Clause 9.3.3.4 applies this criterion to web pages unchanged. For software, clause 11.3.3.4 carries the requirement through a word-substitution table (Table 11.11) that restates it for application user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Walk the real journeys rather than inspecting individual forms. For a checkout, complete a purchase to the final step: the canonical pass is an order review page that shows the items, price, delivery address, and payment method, with edit links, before a clearly labelled "Place order" button (confirmed). If there is no review step, look for the other two routes: does the site validate the critical inputs and let the user correct them before charging (checked), or can the order be cancelled after submission from the account area or within a stated window (reversible)? A one-click purchase pattern is fine only when it is backed by a cancellation window or an equivalent reversal route.
For data deletion, find every place saved data can be removed: addresses, payment methods, documents, messages, the account itself. Each deletion needs a confirmation step ("Delete this address?" with the item identified) or an undo mechanism after the fact. A delete control that acts immediately and permanently, with neither, fails. For test and quiz submissions, check whether the user can review answers before final submit, change them, and whether an auto-submitting timer gives any confirmation opportunity at all.
Use the browser normally; no devtools are needed. The evidence is the journey itself: screenshot the step before the commit and the state after it. The common failure spots are single-step "quick buy" buttons, deletion icons in list rows that fire instantly, and subscription sign-ups where the button that takes payment is the same one that started the form.
iOS
The criterion is written for web pages, but the European standard carries it through to software: it restates the same requirement for application user interfaces through a word-substitution table, so native app journeys are graded to the same three-way test.
In-app purchases made through the system purchase sheet (StoreKit) get confirmation for free: the sheet displays the product and price and requires an explicit confirm (double-click of the side button or authentication), which satisfies the confirmed route. What you audit is everything the system sheet does not cover: in-app checkouts using the app's own payment flow, order placement in commerce apps, and contract-like commitments such as accepting paid plan changes. Walk them exactly as on the web and look for review, checking, or reversal.
For destructive actions, the platform conventions map cleanly onto the criterion: a confirmation alert or action sheet before deletion is the confirmed route, and an undo affordance after deletion is the reversible route. Either passes. Pay particular attention to account deletion flows (which App Store policy requires apps with account creation to offer): the flow must confirm before the account and its data are destroyed. Swipe-to-delete rows deserve a check too: the full-swipe gesture commits immediately, so the app needs a confirmation or an undo for data that matters.
Android
The same word-substitution reading of the European standard applies, so grade Android app journeys against the identical three-way test.
Purchases through the Google Play billing sheet include a system confirmation step showing the item and price, which satisfies the confirmed route for that transaction. Audit the app's own flows beyond it: custom checkouts, order placement, paid upgrades, and anything that commits the user contractually.
For deletion and data modification, Material patterns give you two passing shapes to look for: a confirmation dialog before the action, or a snackbar with an undo action after it (an undo snackbar is the reversible route, provided the undo window is realistically usable). Watch the failure spots: snackbars that only announce "Deleted" with no undo action, long-press or swipe deletions that commit with neither dialog nor undo, and settings screens where clearing stored data takes effect instantly. Account deletion flows should be walked end to end, including any web view the app hands off to.
Pass and fail examples
Passes:
- A checkout whose final step is an order review page listing items, totals, address, and payment method with edit links, before the "Place order" button: confirmed.
- Deleting an email shows a snackbar reading "Conversation deleted" with an Undo action, and undo restores it: reversible.
- Orders can be cancelled from the account area for a stated period after purchase: a cancellation window counts as reversible, even without a pre-submit review page.
- A bank transfer form validates the payee account number and amount, flags detected input errors, and lets the user correct them before sending: checked.
- An online exam shows a summary of all answers, flags unanswered questions, and lets the candidate revise before the final "Submit exam" action: confirmed.
- An iOS in-app purchase completed through the system purchase sheet, which displays the price and requires explicit confirmation: confirmed.
Fails:
- A "Buy now" button that charges the stored card immediately, with no review step, no input checking, and no way to cancel the order afterwards.
- "Delete account" executes as soon as it is tapped: permanent, no confirmation dialog, no undo, no grace period.
- A saved delivery address is removed the instant its bin icon is clicked, with no confirmation and no way to restore it.
- A timed test auto-submits when the clock runs out and also lets a stray click on "Finish" submit instantly, with no review of answers and no way to reopen the attempt.
- An Android app's swipe-to-delete permanently removes a stored document and the snackbar only says "Deleted" with no undo action.
Not a fail under this criterion:
- A contact form, newsletter sign-up, or search form with no confirmation step: out of scope. The criterion covers only legal commitments, financial transactions, changes to user-controllable stored data, and test responses. Applying it to every form is the most common over-application in audits.
- A field whose error state is not described in text: that is SC 3.3.1 Error Identification.
- An error message that identifies the problem but offers no fix: that is SC 3.3.3 Error Suggestion.
- A review page that redisplays everything the user already entered: displaying data for confirmation is not re-asking for it, so it raises no issue under SC 3.3.7 Redundant Entry, and it is precisely what this criterion wants.
Commonly confused with
- Error Identification, SC 3.3.1. 3.3.1 grades individual inputs: when a field fails validation, is the error identified and described in text? This criterion grades the submission as a whole: is there a safety net before or after the commit? A checkout can have flawless field-level errors and still fail 3.3.4 because nothing guards the final "Place order".
- Error Suggestion, SC 3.3.3. 3.3.3 asks whether known error messages suggest a fix. Its "checked" cousin here is broader: the checked route of 3.3.4 requires that critical data is checked at all and correctable before the consequence lands. File message-quality findings under 3.3.3; file "nothing checks this before the money moves" under 3.3.4.
- Redundant Entry, SC 3.3.7. Auditors sometimes worry that a confirmation page "asks again" for information. It does not: a review step displays earlier data for confirmation rather than requiring the user to re-enter it, so a proper confirmed pattern satisfies 3.3.4 without touching 3.3.7. Only a flow that makes the user retype earlier answers raises 3.3.7.
- Error Prevention (All), SC 3.3.6. The Level AAA sibling applies the same three-way test to pages requiring any information submission. If a finding cites a plain contact form against this criterion, it belongs (if anywhere) under 3.3.6, and at Level AA it is usually not a finding at all.
How AUDITSU tests this
AUDITSU's audit walkthrough covers this criterion on the screens where it actually lives: checkout and payment steps, account and data management screens, and test or quiz submission flows. On those screens the walkthrough asks scope first (does this screen commit the user legally or financially, change stored data, or submit test responses?) and then walks you through the three routes: is the submission reversible, is the entered data checked and correctable, or is there a review-and-confirm step before the commit? Each question records a pass, fail, or not applicable result per screen with evidence attached, so a missing safety net is reported against the exact journey step where the user would be exposed, and out-of-scope forms are recorded as not applicable rather than misfiled as failures.
For the full guided workflow, see the audit platform.