Home / Knowledge Base / Why Information Submissions Must Include Error Prevention

Why Information Submissions Must Include Error Prevention

Submitting information is one of the most common and most failure-prone actions on the web. Users make mistakes for many reasons: misreading a question, mistyping a value, misunderstanding what will happen next, or pressing the wrong key. For users with cognitive, learning, visual, or motor disabilities, these mistakes are more likely and harder to detect before it’s too late.

WCAG 3.3.6 extends error prevention beyond high-risk actions and requires safeguards for all information submissions, not just legal or financial ones.

WCAG Success Criterion

3.3.6 Error Prevention (All) (Level AAA)

For web pages that require the user to submit information, at least one of the following is true:

  • Reversible – Submissions can be undone
  • Checked – Input errors are detected, and users are given a chance to correct them
  • Confirmed – Users can review, confirm, and correct information before finalising

This is a Level AAA success criterion.
It is not required for Level A or AA conformance, but it addresses usability barriers that disproportionately affect users who struggle with accuracy, memory, attention, or motor control.

What This Criterion Requires (In Plain Terms)

If users must submit information, they should not be trapped by a mistake.

Before or after submission, users must have at least one way to:

  • Fix the mistake
  • Undo the action
  • Catch the error before it becomes permanent

WCAG does not require all three protections.
It requires at least one applied consistently.

Autosave alone does not meet this criterion unless users can review, undo, or correct the saved submission before it becomes final.

How This Builds on Error Prevention (Legal, Financial, Data)

SC 3.3.4 applies only to high-impact actions (legal, financial, data loss, tests).

SC 3.3.6 applies to all submissions, even when the consequences seem minor.

In other words:

  • 3.3.4 prevents serious harm
  • 3.3.6 prevents avoidable frustration and exclusion

This criterion recognises that “low-stakes” errors still block users—especially when recovery is difficult or impossible.

Why This Matters for Real Users

Consider these everyday scenarios:

  • A screen reader user submits a long profile form and notices a typo only after submission
  • A user with motor impairments accidentally presses “Submit” while still editing
  • A user with cognitive fatigue misunderstands a question and realises it moments later

If none of the following are possible: editing, undoing, or reviewing, the user is effectively punished for a momentary mistake.

The Three Acceptable Safeguards

Reversible

Users can undo the submission after it happens.

Examples:

  • Undo after posting a comment
  • Ability to edit a submitted profile
  • Soft delete with restore option

Reversibility must be real, not hidden, temporary, or fragile.

Checked

The system detects errors and allows correction before the submission becomes irreversible.

Examples:

  • Required fields flagged before submission
  • Format validation with correction opportunity
  • Inline errors that block final submission

Errors must be detected early enough for users to fix them before the action is finalised.

Confirmed

Users are shown a review step where they can confirm and correct information before finalising.

Examples:

  • “Review your answers” page
  • Order summary with editable fields
  • Confirmation step that allows changes

A confirmation that only allows “Yes / No” without correction is insufficient.

Irreversible Actions Still Need Protection

Teams often treat these as “low risk,” but they still fall under this criterion:

  • Sending a message
  • Publishing a post
  • Submitting a form that immediately triggers an action

If the action cannot be undone, users must be given a review or correction opportunity before it occurs.

What This Criterion Does Not Require

  • It does not require confirmation for every keystroke
  • It does not require undo for trivial actions like autosave drafts
  • It does not require all three safeguards at once

The goal is protection, not friction.

Common Ways Teams Get This Wrong

  • Treating autosave as sufficient error prevention
  • Confirmation screens that don’t allow edits
  • Undo links that disappear too quickly
  • Publish or send actions with no review step
  • Validation that occurs only after an irreversible action
  • Review pages that are visually clear but inaccessible to screen readers

Passing AAA is about recoverability, not warnings.

Accessibility Considerations

For assistive technology users:

  • Review and confirmation content must be announced clearly
  • Focus must move predictably to the review or confirmation step
  • Users must be able to navigate back and correct information without restarting
  • Changes after submission must be perceivable and operable

A safeguard that exists visually but is unreachable by keyboard or screen reader is not a safeguard.

Auditor Reality Check

In practice, evaluations often come down to these rules of thumb:

  • If a submission cannot be undone, a review step must exist
  • If a review step exists, users must be able to edit without restarting
  • If validation happens after submission, undo or edit must still be available

If none of these are true, the criterion is not met.

Relationship to Other Error Criteria

  • 3.3.1 Error Identification — tells users what went wrong
  • 3.3.3 Error Suggestion — tells users how to fix it
  • 3.3.4 Error Prevention (Legal, Financial, Data) — protects against serious consequences
  • 3.3.6 Error Prevention (All) — ensures all users can recover from mistakes

Benefits

This success criterion benefits users who:

  • Have difficulty with accuracy or recall
  • Experience cognitive fatigue
  • Use assistive technologies that slow review
  • Are new to complex forms or workflows

It also reduces abandonment, repeated submissions, and support burden.

Wrapping Up

WCAG 3.3.6 is not about eliminating mistakes. It’s about acknowledging that mistakes happen and designing systems that allow recovery.

By giving users a way to review, correct, or undo submissions, authors remove a major but often invisible barrier. While this is a Level AAA requirement, applying it consistently improves clarity, reduces frustration, and makes everyday interactions safer for everyone.

Want to test against all WCAG success criteria?

Stay compliant. Avoid fines. WebYes reviews your entire website so you don't have to worry.

Sign Up for Free Now