Level AAA

Extends 3.3.4's three safeguards -- reversible, checked, or confirmed -- to every user submission, not just legal, financial, and data-handling transactions

3.3.6 Error Prevention (All)

In Plain Language

3.3.6 Error Prevention (All) is the Level AAA generalisation of 3.3.4 Error Prevention (Legal, Financial, Data). Where 3.3.4 requires one of three safeguards -- reversible, checked, or confirmed -- only for submissions that incur legal commitments, move money, modify stored user data, or submit test responses, 3.3.6 extends the same three mechanisms to any page that causes a user submission[1].

Practically: the comment box, the search query, the profile-update form, the "save preferences" toggle, and the support-ticket composer all fall inside 3.3.6's scope, even though none of them trigger 3.3.4. At least one of reversible, checked, or confirmed has to be wired to the submission path -- not documented in a help article, wired in the markup and the handler.

Why It Matters

  • Users with cognitive and learning disabilities may transpose characters, skip fields, or misread labels and only notice after the submit button has fired. A review-then-confirm step or a post-submission undo gives them a recovery window[1].
  • Users with motor disabilities trigger submit controls unintentionally -- tremor, spasticity, switch overshoot, head-pointer drift. A confirmation dialog or a reversible action intercepts the accidental fire before it mutates server state.
  • Screen-reader users cannot visually scan a long form to spot a mistyped field. A review step that renders the submitted values as a `
    ` or equivalent lets them walk the entries with virtual cursor navigation before committing.
  • 3.3.4 already covers the high-consequence cases. 3.3.6 closes the gap for every other submission path, on the premise that the user -- not the form designer -- should decide which mistakes are recoverable.

Examples

Do: Provide a review step before submission

Review your submission

Name
Jane Smith
Comment
The new park hours work great for our family.

✔ User can review entries and go back to edit before final submission

<!-- Step 2: Review before submit -->
<h2>Review your submission</h2>
<dl>
  <dt>Name</dt>
  <dd>Jane Smith</dd>
  <dt>Comment</dt>
  <dd>The new park hours work great...</dd>
</dl>
<button type="button">Edit</button>
<button type="submit">Confirm & Submit</button>
<!-- User sees their data and can go back to fix it -->
Don't: Submit immediately with no review or undo

✘ No review step, no confirmation, no undo -- typos are submitted immediately

<!-- FAILS: no review, confirmation, or undo -->
<form action="/submit" method="post">
  <label for="name">Name</label>
  <input id="name" type="text">
  <label for="comment">Comment</label>
  <textarea id="comment"></textarea>
  <button type="submit">Submit</button>
</form>
<!-- Data goes straight to the server with no chance
     to review, correct, or reverse the action -->
Do: Allow users to undo a submission
Comment posted.

✔ Submission is reversible -- user can undo within a time window

<!-- After submission, show a reversible toast -->
<div role="status" class="toast">
  Comment posted.
  <button type="button">Undo</button>
</div>
<!-- Undo reverses the submission within a time window.
     role="status" announces the message to screen readers. -->
Don't: Show a success message with no way to reverse
Your comment has been posted. Thank you!

✘ No undo, no edit link -- the user cannot recover from a mistake

<!-- FAILS: no way to reverse the action -->
<div class="success-msg">
  Your comment has been posted. Thank you!
</div>
<!-- User who made a typo or submitted the wrong
     content has no recourse -->

How to Fix It

  1. Pick one of the three mechanisms per submission path. 3.3.6 is satisfied by reversible, checked, or confirmed -- you do not need all three[1]. Audit each form (comments, profile, settings, search, support) and decide which mechanism fits. Destructive actions lean toward confirmed; low-stakes posts lean toward reversible.
  2. Confirmed: render the submitted values on a review step. Before the server handler runs, show a summary page or modal that lists every field the user entered, and expose an explicit Edit control alongside the final Submit. The review list should be readable as structured content (a <dl> of term/description pairs works), not a paragraph of concatenated values.
  3. Reversible: wire an undo that actually rolls back server state. A toast with an Undo button only meets 3.3.6 if clicking it reverses the submission on the backend within the window the toast was visible. Announce the toast with role="status" (or role="alert" for destructive contexts) so screen-reader users hear the undo offer, not only sighted users who happen to be looking at the corner of the viewport.
  4. Checked: validate on the client, then give the user the opportunity to correct. "Checked" in 3.3.6's language means the input is validated and the user is offered a chance to fix detected errors before the submission is final. Mark invalid fields with aria-invalid="true" and link the error message via aria-describedby so assistive tech reads the error at the field, not as a disconnected banner.
  5. Do not confuse a success toast with a reversible action. "Your comment has been posted" is a status message, not a recovery mechanism. If the submission cannot be undone and there is no review step and no checked-then-correct flow, the page fails 3.3.6 regardless of how clearly the confirmation is worded.
  6. Level AAA scope. 3.3.6 is Level AAA. Teams conforming to Level AA are not obligated to meet it, but 3.3.4 still applies to legal, financial, and data-handling submissions and is the load-bearing Level AA requirement in this area[1].

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.6: Error Prevention (All). W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-all.html ↩ ↩ ↩ ↩