Some actions carry consequences that users cannot easily recover from. Imagine a screen reader user submitting a tax form, a motor-impaired user accidentally activating “Delete account,” or a user with a cognitive disability missing a single digit in a bank transfer amount. In these situations, a small mistake can lead to financial loss, legal commitments, or permanent data deletion.
WCAG 3.3.4 exists to prevent exactly this kind of harm. When actions have serious consequences, users must be given a reliable way to stop, review, or undo mistakes before it’s too late.
WCAG Success Criterion
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)
For web pages that cause legal commitments or financial transactions to occur, modify or delete user-controllable data, or submit user test responses, at least one of the following is true:
- Reversible
- Checked
- Confirmed
Level AA is the most commonly required WCAG conformance level in laws and procurement policies. This makes Error Prevention a baseline requirement for high-risk interactions, not a best practice.
What This Criterion Requires
If an action could seriously affect the user, the interface must protect them from accidental mistakes.
That protection can take different forms, but the outcome must be the same:
Users should not lose money, rights, or important data because of a simple, preventable error.
When This Criterion Applies
This criterion applies only to high-impact actions, such as those that:
- Create legal commitments
- Perform financial transactions
- Delete or significantly modify user-controllable data
- Submit test or exam responses
Examples include:
- Purchasing non-refundable tickets
- Buying or selling stock
- Deleting stored records or accounts
- Submitting final exam answers
It does not apply to routine actions like autosaving drafts, editing profile text, or updating content that can easily be changed later.
The Three Allowed Safeguards
WCAG requires at least one of the following protections. You do not need to implement all three.
1. Reversible
The action can be undone after it happens.
Examples:
- “Undo delete” for files or records
- Recovery periods for cancelled subscriptions
- Restore options for deleted data
Reversibility must be reliable and accessible. A temporary undo that disappears before users can perceive it may not be sufficient.
2. Checked
The system checks for errors and lets users fix them before submission.
Examples:
- Validating required fields
- Blocking submission until errors are corrected
- Clearly identifying invalid values
This safeguard must occur before the irreversible action is finalised.
3. Confirmed
Users can review, confirm, and correct information before completing the action.
Examples:
- Order review pages
- Confirmation screens summarising the action
- “Review and submit” steps in multi-step flows
A confirmation step must allow users to change their input, not merely acknowledge it.
What Counts as User-Controllable Data
User-controllable data is information that users can intentionally view, modify, or delete.
Examples:
- Account details (address, phone number)
- Saved records or documents
- Stored preferences or profiles
This does not include:
- Server logs
- Analytics data
- Monitoring data users cannot access
The goal is to prevent meaningful loss, not to require confirmation for every save action.
Common Mistakes Teams Make
These failures appear frequently in audits:
- Confirmation screens that do not allow edits
- Delete dialogs that fail to name what will be deleted
- Undo options that disappear too quickly to perceive
- Confirmation modals that trap keyboard focus incorrectly
- Browser-native confirm() dialogs that are poorly announced by screen readers
- Final submissions are triggered automatically without an explicit review step
If a single accidental action can cause permanent loss, the criterion is not met.
Accessibility Implementation Notes
For error prevention to work for assistive technology users:
- Focus must move predictably to confirmation or review content
- Summary information must be available in text, not images alone
- Screen readers must announce what is being confirmed or undone
- Users must be able to correct errors without restarting the entire process
Confirmation dialogs that look fine visually often fail because focus is lost, content is not announced, or users cannot reach correction controls.
Relationship to Other Error Criteria
- 3.3.1 Error Identification
Users are told that an error exists. - 3.3.3 Error Suggestion
Users are told how to fix it. - 3.3.4 Error Prevention
Users are protected from irreversible consequences.
Error Prevention applies only when mistakes carry a serious risk, but it is often the most critical safeguard.
Examples
Passing Example: Order Confirmation
An online retailer displays a comprehensive order summary, including items, quantities, shipping address, and payment method, before the purchase is completed. Users can edit or cancel before confirming.
Passing Example: Financial Transaction Warning
A trading platform detects after-hours trading, explains the risks, and gives users a clear option to cancel or confirm.
Failing Example
A site deletes user records immediately after clicking “Delete,” with no undo option, no confirmation, and no recovery mechanism.
How Auditors Typically Evaluate This
Auditors look for:
- Whether at least one safeguard exists
- Whether it occurs before consequences are final
- Whether users can correct mistakes without penalty
- Whether assistive technology users can perceive and operate the safeguard
Patterns associated with failure include F31 (immediate irreversible submission) and missing confirmations for destructive actions.
Common supporting techniques include G98 (confirmation) and G155 (undo functionality).
Benefits
Error prevention protects users who:
- Have cognitive or learning disabilities
- Have motor impairments that increase accidental input
- Use screen readers or magnification
- Experience fatigue or reduced attention
It also reduces abandonment, complaints, and costly support requests.
Wrapping Up
Error Prevention is not about slowing users down. It is about acknowledging that when consequences are serious, interfaces must give users a fair chance to notice, correct, or undo mistakes. WCAG 3.3.4 sets that expectation at Level AA because preventable harm is not an acceptable cost of interaction.
When high-risk actions exist, safeguards are not optional; they are the minimum.
