WCAG 3.3.6 Error Prevention (All): Understanding the WCAG AAA Requirement

What WCAG 3.3.6 Error Prevention (All) requires

WCAG 3.3.6 Error Prevention (All) appears in WCAG 2.2 as a Level AAA success criterion. It extends the earlier error prevention requirement so that finalising any user input that can cause data loss, financial cost, or a significant change must include ways to prevent or fix mistakes.

Why this matters for users

People make mistakes. When a form, purchase, or deletion cannot be undone, the consequences can be frustrating or serious. The criterion reduces that harm by asking designers to let users review, correct or reverse actions before or after they are finalised. This benefits people who use screen readers, keyboard navigation, or cognitive supports.

Which interactions are in scope

The phrase “All” means the rule applies more widely than earlier versions. Typical in-scope interactions include:

• Placing, changing or cancelling an order
• Submitting forms that save or replace data
• Deleting or permanently changing user content
• Actions that transfer money or sensitive personal data

How to meet WCAG 3.3.6: accepted patterns

There are three practical patterns that satisfy the intent. Pick the one that fits the task and context.

1. Review and confirm before commit

Show a clear review screen or confirmation step where users see what will change. Make the review page keyboard reachable and programmatically labelled. Do not rely only on visual emphasis such as colour or position.

2. Allow easy correction on the spot

When a user makes an input error, display validation and correction options before saving. Keep focus management so keyboard and screen reader users can correct the field without losing context. Provide descriptive messages and suggestions.

3. Provide a reversible action or undo

Offer an explicit undo control that returns the system to its previous state. Undo must be discoverable, keyboard operable and available to assistive technologies. Where undo is not feasible, provide a recoverable staging area such as a trash folder.

Accessibility implementation details

Follow these technical points so the feature works for all users.

• Use semantic HTML for controls and labels. Ensure form controls have accessible names.
• Announce state changes using ARIA where native semantics are insufficient. For example use aria-live or role=“alert” for transient messages so screen readers hear them.
• Move focus predictably. After an error or a confirmation step, set focus to the most relevant control or heading.
• Ensure modals and dialogs are keyboard focus trapped and have an accessible name via aria-labelledby or an equivalent heading.
• Do not rely only on browser confirm() dialogs. They may be inaccessible and inconsistent across assistive technologies.

Examples that meet the criterion

• Checkout page with an edit-review screen, accessible heading for order summary, and a clearly labelled place-order button. Users can return to edit items without losing their cart.
• Delete item flow where deletion moves the item to a recoverable trash and shows an accessible undo link after deletion.
• Profile update form with inline validation, a summary of pending changes, and a save button that includes an accessible confirmation step for sensitive fields.

Common failures to avoid

• No confirmation or undo for irreversible deletions
• Undo placed off-screen or hidden from keyboard users
• Error messages that are visual only, not announced to screen readers
• Confirmation dialogs that trap keyboard focus poorly or lack an accessible name
• Auto-submitting changes without a clear opportunity to review

Step-by-step developer checklist

1. Identify all finalising actions in the product. List where data can be lost, charges applied or content permanently changed.
2. For each action, pick one prevention pattern: review, on-the-spot correction or undo.
3. Design the UI so controls have accessible names and predictable focus order.
4. Implement announcements for state changes using ARIA only where native roles do not suffice.
5. Create keyboard and screen reader test cases for review, correction and undo flows.
6. Manually test with at least one screen reader and one keyboard-only session. Verify that undo or restore works and that messages are announced.

Testing scenarios you can run

Run these cases during QA.

• Attempt an irreversible action and confirm the user sees a review screen and can go back to edit.
• Perform an action, then use keyboard and screen reader to find and activate undo.
• Submit a form with errors and confirm errors are announced and focus lands on the first issue.
• Delete content, then verify it appears in a recoverable location or can be restored by account tools.

When to prefer confirmation over undo

Use a confirmation step if the action has immediate legal or financial effect, or if restoring state is costly or impossible. Choose undo when users expect fast workflows and recovery within the application is practical. The deciding factors are reversibility cost and user expectation.

Notes on conformance and practical trade-offs

WCAG 3.3.6 is Level AAA. Many organisations aim for AA as a baseline, but AAA criteria are sometimes required by contract or policy. Where AAA is mandatory, apply the patterns consistently across the product for any finalising action. Where AAA is aspirational, focus first on high-risk interactions such as payments and deletions.

Quick reference: what to document for accessibility audits

• List of finalising actions and the chosen prevention pattern for each
• Accessibility behaviour notes: focus movement, announcements and keyboard behaviour
• Test cases and results for screen reader and keyboard testing
• Any server-side or recovery mechanisms such as soft-delete or audit logs

Summary of practical fixes

• Add a review screen for orders and major edits
• Give users a visible and accessible undo for quick recoveries
• Make validation messages programmatically available and move focus to them
• Provide recoverable storage for deleted content when undo is not feasible

If you need a short checklist or example text for a confirmation dialog or undo message, say which interface you are working on and I will draft specific wording and a small test plan.