WCAG 3.3.6: Error Prevention (All)

What This Rule Means

WCAG 3.3.6 — Error Prevention (All) is a Level AAA success criterion under the Understandable principle. It extends the requirements of 3.3.4 (Error Prevention: Legal, Financial, Data) to cover all pages that require a user to submit information, regardless of whether that submission involves legal commitments, financial transactions, or personally identifiable data.

At its core, the criterion requires that for any web page where a user submits information, at least one of the following three conditions must be satisfied:

• Reversible: Submissions are reversible after the fact. The user can undo, cancel, or retract an action within a reasonable timeframe. For example, a sent message can be recalled, or a submitted form can be cancelled from a confirmation queue.
• Checked: Data entered by the user is checked for input errors before final submission, and the user is given an opportunity to correct those errors. This involves inline validation, pre-submission summaries, or step-by-step review flows.
• Confirmed: A mechanism is provided for reviewing, confirming, and correcting information before the submission is finalized. This could be a review screen, a confirmation dialog, or a multi-step wizard with a final review step.

The key distinction between 3.3.4 and 3.3.6 is scope. Criterion 3.3.4 applies only to legal agreements, financial transactions, test responses, and deletions of user-controlled data. Criterion 3.3.6 broadens this to every page that requires any form of user input submission—including contact forms, newsletter sign-ups, comment sections, survey responses, profile updates, search settings, and any other user-controlled data entry.

What counts as a pass: A form passes if it implements at least one of the three mechanisms above consistently. A confirmation page before final submission, a summary screen with an "Edit" option, client-side or server-side validation with error correction opportunities, or a clearly communicated undo window all satisfy the criterion.

What counts as a fail: A single-step form that submits data immediately on button click with no validation, no review screen, and no undo mechanism fails this criterion. Similarly, a form that validates but provides no opportunity to correct errors before re-submitting also fails.

The WCAG specification does not require all three mechanisms simultaneously—satisfying any one is sufficient. However, combining two or three mechanisms provides defense-in-depth and serves a broader range of users and contexts.

Why It Matters

Error prevention is not simply a usability nicety—it is a fundamental accessibility requirement for users who face elevated risk of input errors due to disability or situational impairments.

Cognitive and learning disabilities: Users with dyslexia, ADHD, or memory impairments frequently make typographic errors, transpose digits, or lose track of complex multi-field forms. Without a review mechanism, a mistyped email address on a contact form could mean a missed response, or an incorrectly entered address on a delivery form could cause lost packages. These are not edge cases—according to the World Health Organization, approximately 1 billion people worldwide live with some form of cognitive or neurological condition that affects daily functioning.

Motor impairments: Users with tremors, limited fine motor control, or who rely on switch access or voice input software often activate form submissions accidentally or enter unintended characters. A user with Parkinson's disease navigating a complex form with a switch interface may inadvertently submit an incomplete or incorrect form. Without reversibility or confirmation steps, these errors become permanent.

Screen reader users: Blind users navigating with JAWS, NVDA, or VoiceOver may not have the same visual overview of a completed form that sighted users enjoy before submitting. A confirmation screen or summary read aloud by a screen reader gives these users a final chance to verify their data before it is irreversibly submitted.

Low digital literacy and aging populations: Older adults and users new to digital interfaces are particularly vulnerable to accidental submissions. A confirmation step with plain-language summaries provides a safety net that dramatically reduces support costs and user frustration.

Real-world scenario: Consider a Turkish e-government portal where a citizen fills out a lengthy bureaucratic form to register a business. If the citizen accidentally omits a required field or enters their tax identification number incorrectly and the form submits immediately with no review step, they may not realize the error until receiving a formal rejection notice days later. A simple confirmation screen showing all entered data before final submission would have prevented this entirely.

SEO and usability benefits: Pages that implement robust error prevention tend to have lower form abandonment rates, higher conversion rates, and better user satisfaction scores. Search engines increasingly factor user experience signals into rankings, and pages with high bounce rates due to form errors indirectly suffer in organic visibility.

Related Axe-core Rules

WCAG 3.3.6 requires manual testing because no automated tool can determine whether a given form submission flow satisfies the reversibility, error-checking, or confirmation requirements of this criterion. Automated accessibility scanners like axe-core can verify the presence of individual ARIA attributes, labels, and error messages, but they cannot evaluate the overall submission flow logic, the existence of a confirmation step, or whether an undo mechanism is actually functional. The criterion is fundamentally about interaction design and user experience flow—not static markup.

• No dedicated axe-core rule exists for 3.3.6. Axe-core and similar engines test individual DOM elements against specific attribute or role requirements. Determining whether a multi-page form includes a review step before final submission requires understanding the application's navigation flow and server-side behavior—information that static analysis tools cannot access. A human tester must walk through the complete submission journey to evaluate compliance.
• Related rules that support overall form quality (though not specifically 3.3.6): Rules such as label (every input has an associated label), aria-required-attr (required ARIA attributes are present), and form-field-multiple-labels (inputs do not have conflicting labels) contribute to the foundation of accessible forms. Ensuring these pass is a prerequisite to meaningful error prevention, but passing them does not guarantee 3.3.6 compliance.
• Why automation falls short: An automated scan of a checkout page might confirm that all input fields have labels and that error messages are programmatically associated with inputs. But it cannot determine whether clicking "Submit" takes the user to a review screen, whether a "Cancel" option exists, or whether the system sends a confirmation email with a cancellation link. These are behavioral and process questions that only human evaluation can answer.

How to Test

1. Run an automated scan as a baseline: Use axe DevTools, Lighthouse, or the Accsible widget's built-in audit mode to scan all pages containing forms. While these tools will not flag 3.3.6 violations directly, they establish a foundation by identifying missing labels, absent error messages, or improperly associated validation feedback. Resolve all automated findings before proceeding to manual testing.
2. Identify all submission forms on the site: Create a complete inventory of every page that accepts and submits user input—contact forms, registration forms, login forms, search preference forms, profile update pages, comment sections, newsletter sign-ups, and any multi-step wizards. Each one must be tested independently.
3. Test the happy path with intentional errors: On each form, intentionally enter incorrect, incomplete, or malformed data (e.g., an invalid email address, a phone number with letters, leaving required fields empty). Submit the form and observe: Does the page prevent submission and provide error messages? Are error messages associated with the correct fields? Does the user have a clear opportunity to correct and resubmit?
4. Test for confirmation or review mechanisms: For forms that pass validation, complete the form with valid data and submit. Observe whether a confirmation screen, summary dialog, or review step appears before the data is irrevocably submitted. Verify that the review step allows the user to go back and edit entries.
5. Test reversibility post-submission: After a successful submission, check whether a cancellation, undo, or retraction mechanism exists. This might be a "Cancel submission" link in a confirmation email, a queue management screen in an admin area, or an in-app notification with an undo action. Verify the mechanism works and is clearly communicated to users.
6. Screen reader testing with NVDA + Firefox: Navigate to each form using NVDA and Firefox. Tab through all fields, enter data, and submit the form. Verify that error messages are announced when they appear, that the review screen (if present) is fully readable in document order, and that all interactive controls (edit buttons, confirm buttons, cancel buttons) on the confirmation screen are keyboard accessible and properly labelled.
7. Screen reader testing with VoiceOver + Safari (macOS/iOS): Repeat the above process using VoiceOver on Safari. Pay particular attention to dynamic content updates—if validation errors appear dynamically via JavaScript without a page reload, confirm they are surfaced via live regions (aria-live) so VoiceOver announces them without requiring the user to manually explore the page.
8. Keyboard-only testing: Without a mouse, navigate through the entire form submission flow using only the Tab, Shift+Tab, Enter, and Space keys. Confirm that every interactive element—including edit, back, confirm, and cancel buttons on review screens—is reachable and operable without a pointing device.

How to Fix

Contact Form with No Validation or Review — Incorrect

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Contact Form with Validation and Confirmation Step — Correct

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Multi-Step Wizard Without Summary Step — Incorrect

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Multi-Step Wizard with Final Review Step — Correct

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Form with Immediate Submit and No Undo — Incorrect

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Destructive Action with Confirmation Dialog — Correct

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Common Mistakes

• Implementing validation but not surfacing it to screen readers: Displaying error messages visually via CSS color changes or icons without associating them with the input using aria-describedby or injecting them into an aria-live region means blind users never hear the error—the form appears to have submitted successfully while actually remaining incomplete.
• Treating 3.3.4 compliance as sufficient for AAA: Teams often implement error prevention only for financial or legal forms (satisfying 3.3.4) and assume all forms are covered. Criterion 3.3.6 requires the same protections for every form on the site, including newsletter sign-ups, comments, and profile updates.
• Providing a confirmation screen that is read-only with no edit path: A review page that displays submitted data but offers only a "Confirm" button—with no way to return and correct errors—does not fully satisfy the spirit of the criterion and leaves users with no recourse if they spot a mistake during review.
• Using window.confirm() as the sole confirmation mechanism: Browser-native confirm dialogs are not accessible to all users and cannot be styled or structured for clarity. They also behave inconsistently across assistive technologies. Use a proper <dialog> element with appropriate ARIA attributes instead.
• Resetting the entire form on validation failure instead of preserving valid entries: When a user submits a 10-field form with one error and the form clears all fields, the user must re-enter all data. This is particularly burdensome for users with motor disabilities or cognitive fatigue. Always preserve valid data and focus attention only on the erroneous fields.
• Placing error summary messages outside the viewport or keyboard focus order: An error summary banner injected at the top of the page after a failed submission does nothing for users who are focused mid-form. Use aria-live='assertive' on the summary container and programmatically move focus to it on submission failure.
• Marking confirmation buttons with vague labels like "OK" or "Yes": On a review screen, buttons must clearly communicate what will happen. "Confirm and Send Message" is unambiguous; "OK" is not—especially for screen reader users who may not have the surrounding visual context available.
• Assuming server-side validation alone satisfies the criterion: If client-side validation is absent, every submission requires a full round-trip to the server before the user learns of an error. Users on slow connections or who lose network mid-submission may be left in an uncertain state with no clear error feedback.
• Not testing the reversibility mechanism under realistic conditions: Teams sometimes implement a "cancel" option in a confirmation email but never test whether the cancel link is accessible, whether it works after the window expires, or whether the link is usable by screen readers. An inaccessible undo mechanism does not satisfy the criterion.
• Failing to handle auto-fill edge cases in review screens: When browser or password-manager auto-fill populates form fields, the values displayed on a review screen may not match what was actually submitted if the JavaScript populating the review pulls from the DOM before auto-fill completes. Always pull values immediately before rendering the review screen, not on initial page load.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility obligations for a broad range of entities operating in Turkey. The circular requires covered organizations to conform to WCAG 2.2 at Level AA as a baseline. The entities explicitly covered include public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and healthcare providers, telecommunication companies with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

WCAG 3.3.6 is a Level AAA criterion and is therefore not a direct legal requirement under the 2025/10 Circular. However, its importance in the Turkish regulatory context should not be dismissed. Several of the covered entity types—particularly banks, e-commerce platforms, and healthcare providers—operate high-stakes transactional forms where error prevention is not merely a best practice but a legal and ethical necessity. A Turkish bank's online money transfer form, a healthcare portal's appointment booking system, or an e-commerce checkout flow that lacks confirmation steps or error correction mechanisms may not violate 3.3.6 in a legally enforceable sense, but it creates significant risk of harm for users with disabilities and exposes the organization to reputational and operational risk.

Furthermore, the circular signals a clear trajectory toward increasing accessibility requirements over time, consistent with the European Accessibility Act (EAA) framework that Turkey has been aligning with. Organizations that implement AAA criteria such as 3.3.6 today are proactively positioned for future regulatory tightening and demonstrate a commitment to inclusive design that goes beyond minimum compliance. For entities like private hospitals and financial institutions that serve aging populations or users with cognitive and motor impairments at disproportionately high rates, implementing 3.3.6 across all forms is a sound risk management decision independent of its legal status. Accsible's overlay SDK can assist in surfacing error messages, reinforcing validation states, and providing supplementary confirmation prompts as a layer of enhanced protection for Turkish organizations striving to lead on accessibility.