3.3.6 Error Prevention (All)

WCAG 2.2 · 3.3.6 AAA Understandable

What it requires

This is the broadest of the three error-prevention criteria. Where 3.3.4 (AA) covers only pages with legal, financial, or user-data commitments, 3.3.6 extends the same protection to any page that causes the user to submit information. For such submissions, at least one of the following must be true:

  • Reversible — the submission can be undone.
  • Checked — entered data is validated for input errors and the user is given a chance to correct them.
  • Confirmed — a review, confirm, and correct step is available before the submission is finalised.

The user does not have to be on a legal or financial page for this to apply — committing any form data triggers it.

Failures hit users who are most likely to make and least able to recover from a mistaken submission:

  • People with cognitive, learning, or memory disabilities, who may misread fields or forget what they entered.
  • People with motor disabilities, who may trigger a submit unintentionally.
  • Blind and low-vision users, who can transpose or mistype data they cannot easily review at a glance.
  • Anyone under stress or time pressure who would benefit from a chance to catch errors before they become permanent.

How to detect it

Concrete checks for 3.3.6
Check How Automatable?
Identify committing submissions Manually list every form that sends data; note which are protected. No — requires human judgement.
Reversible Confirm an undo, cancel, or edit path exists after submitting. No.
Checked Submit invalid data via keyboard and screen reader; confirm errors are described in text and correctable. Partly — axe flags missing labels, not validation logic.
Confirmed Verify a review/confirm screen lets you inspect and amend before finalising. No.

How to fix it

  1. Inventory every form that commits data, not just legal or financial ones.
  2. Pick a mechanism per form: make it reversible, validate and surface correctable errors, or add a confirmation step.
  3. For the confirm pattern, show a summary and let the user go back and edit each value.
  4. Announce validation errors programmatically so assistive technology hears them.

A simple review-and-confirm step before the final submit:

<form action="/order/confirm" method="post">
  <h2>Review your order</h2>
  <dl>
    <dt>Email</dt><dd>sam@example.com</dd>
    <dt>Total</dt><dd>€48.00</dd>
  </dl>
  <a href="/order/edit">Edit details</a>
  <button type="submit">Confirm and place order</button>
</form>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that proves 3.3.6: a tool cannot tell whether a committing submission is reversible, checked, or confirmable. This criterion needs manual review — use the console check and steps below to find the forms, then verify each by hand.

Run this in the browser console

console — list-committing-forms.js 
// READ-ONLY: surfaces forms that submit data so you can review each by hand.
const forms = [...document.querySelectorAll('form')];
const suspects = forms.map(f => ({
  action: f.getAttribute('action') || '(none)',
  method: (f.getAttribute('method') || 'get').toLowerCase(),
  submits: f.querySelectorAll('button[type=submit], input[type=submit], button:not([type])').length,
  hasConfirmOrUndo: /confirm|review|undo|cancel|edit/i.test(f.textContent),
  el: f
}));
console.table(suspects.map(({ el, ...row }) => row));
suspects.forEach(s => { s.el.style.outline = '2px dashed orangered'; });
console.log('Outlined', suspects.length, 'form(s) — none modified or submitted.');

What to check manually: for each outlined form, confirm a real reverse, check, or confirm step actually works — e.g. that submitting wrong data shows a correctable, text-described error, and that any "confirm" screen truly lets you go back and edit before finalising. No script can judge whether that recovery path is genuine.