WCAG 3.3.4: Error Prevention (Legal, Financial, Data)

What This Rule Means

WCAG Success Criterion 3.3.4, titled Error Prevention (Legal, Financial, Data), is a Level AA requirement under Principle 3 (Understandable) and Guideline 3.3 (Input Assistance). It applies specifically to web pages where users can cause legal commitments or financial transactions to occur, or where the user modifies or deletes user-controllable data in a data storage system.

The criterion mandates that at least one of the following three safeguards is provided for any such submission:

• Reversible: The submission can be undone after it has been sent. For example, an order can be cancelled within a defined time window, or a deleted record can be restored.
• Checked: The data entered by the user is checked for input errors, and the user is given an opportunity to correct those errors before the submission is finalized.
• Confirmed: A mechanism is provided for reviewing, confirming, and correcting information before the final submission. This typically takes the form of a summary or review step before a submit button completes the transaction.

It is important to note that only one of these three conditions needs to be satisfied for a pass. Providing a review-and-confirm step alone is sufficient, as is providing a post-submission cancellation window, as is robust real-time validation with a correction opportunity. Best practice, however, is to combine multiple safeguards.

Scope of the criterion: The rule applies to three categories of transaction. First, it covers legal commitments such as signing up for a subscription, agreeing to a contract, or submitting a binding legal form. Second, it covers financial transactions including purchases, fund transfers, loan applications, and bill payments. Third, it covers any action that modifies or deletes user-controlled data in a data storage system — for example, updating profile information, deleting files from a cloud service, or editing records in an administrative panel.

A pass looks like: an e-commerce checkout that presents an order summary with an "Edit" link and a "Place Order" button as the final step. A fail looks like: a single-page purchase form where clicking "Buy Now" immediately charges a card with no review screen, no cancellation option, and no validation step.

The criterion has a defined exception: it does not apply to forms where submitting incorrect information is not consequential and the submission can trivially be repeated. Simple contact forms or newsletter signups generally fall outside the scope, although good practice still encourages validation on those forms.

Why It Matters

Errors during high-stakes transactions can have serious, sometimes irreversible consequences: money transferred to the wrong account, a legal agreement signed under false pretenses, medical records updated with incorrect information, or a subscription purchased at the wrong tier. For users without disabilities, catching and correcting these mistakes is often straightforward. For many disability groups, it can be extremely difficult or even impossible without the safeguards this criterion requires.

Users with cognitive disabilities — including those with dyslexia, ADHD, memory impairments, or intellectual disabilities — are more likely to make data-entry errors and less likely to notice them before clicking submit. A review screen gives them the time and clarity they need to spot mistakes. According to the World Health Organization, approximately 1 billion people worldwide live with some form of cognitive, neurological, or mental health condition that affects daily functioning.

Users with motor impairments who rely on switch access, eye-tracking devices, or alternative keyboards are prone to accidental activations and unintended keystrokes. A confirmation step acts as a critical buffer: even if "Submit" is activated by mistake, the user has another opportunity to cancel before the transaction completes. Without this safeguard, a single accidental tap could trigger a financial transaction that the user cannot reverse.

Screen reader users navigating long forms linearly may not have a holistic view of what they have entered. A spoken summary at the confirmation stage — reading back the entered values — allows them to catch errors they could not visually scan for.

Users with anxiety or attention difficulties benefit enormously from knowing there is a safety net. Research consistently shows that when users perceive a process as error-tolerant, they engage with more confidence and abandon transactions less frequently. This directly benefits conversion rates and user satisfaction, making 3.3.4 compliance a business advantage as well as an ethical obligation.

Real-world scenario: A visually impaired user in Istanbul is booking a domestic flight using a screen reader. She selects a date but accidentally navigates past the passenger count field, leaving it at its default of two passengers instead of one. If the booking site charges her card the moment she activates "Confirm," she has purchased two tickets and may face non-refundable fare penalties. A review screen that reads aloud "1 passenger: Ayşe Yılmaz, Ankara to Istanbul, 14 March, Economy — Total: ₺850" would let her catch the error immediately.

Related Axe-core Rules

WCAG 3.3.4 requires manual testing. No automated axe-core rule directly maps to this criterion because the safeguards it requires — reversibility, validation-with-correction opportunity, and confirmation steps — are matters of application flow and business logic, not of markup structure or DOM attributes. Automated tools can parse HTML and ARIA, but they cannot determine whether a "Pay Now" button triggers an irreversible charge, whether a cancellation policy exists, or whether the data shown in a review screen accurately reflects what was entered.

• Why automation cannot catch this: An automated scanner sees a <button> element with the text "Submit" and valid markup. It has no way of knowing whether activating that button initiates a binding financial transaction, whether a confirmation dialog will follow, or whether the transaction can be undone afterward. These are architectural and UX decisions that exist above the level of individual DOM nodes, requiring a human tester who understands the full user journey.
• Partial signals to look for during automated scans: While axe-core does not flag 3.3.4 violations directly, auditors sometimes use axe to identify related issues that compound the risk — such as missing autocomplete attributes on payment fields (relevant to 1.3.5), absent error messages (relevant to 3.3.1 and 3.3.3), or missing labels on form controls (relevant to 1.3.1 and 4.1.2). These related failures make error prevention even harder to achieve.
• Recommended manual audit approach: Testers should map every user journey that involves a legal, financial, or data-modification submission, then evaluate each journey against the three criteria: Is there a way to undo it? Is there inline validation with a correction opportunity? Is there a review-and-confirm step? Failing all three on any such journey constitutes a 3.3.4 failure.

How to Test

1. Inventory high-stakes forms: Before testing begins, create a list of every form or interactive workflow on the site that involves financial transactions (checkout, payment, invoicing), legal commitments (contract signing, subscription enrollment, consent forms), or data modification/deletion (profile editing, file deletion, account removal). These are the only flows in scope for 3.3.4.
2. Run an automated scan for related issues: Use axe DevTools or Lighthouse to identify form-level accessibility failures on each in-scope page. While these tools will not flag 3.3.4 directly, resolving issues like missing labels, absent autocomplete attributes, and missing error announcements establishes a baseline of form quality before evaluating the error-prevention safeguard.
3. Test the "Checked" safeguard: Deliberately submit each in-scope form with intentional errors — transposed digits in a card number, an invalid date, a mismatched email confirmation field. Observe whether the system halts submission, identifies the specific error, describes how to fix it (per 3.3.3), and keeps the user on the form to make corrections. If the form submits silently or only shows a generic error without identifying which field failed, this safeguard is not met.
4. Test the "Confirmed" safeguard: Complete each in-scope form with valid data and proceed through the full flow. Identify whether a review step is presented before the final submission. Verify that the review step displays all entered data in a readable format, includes a mechanism to go back and edit, and requires a deliberate final action to complete the submission. Using NVDA with Firefox and JAWS with Chrome, navigate this review step with a screen reader to confirm that all values are announced and that the edit and confirm controls are reachable by keyboard.
5. Test the "Reversible" safeguard: Complete a submission and then attempt to undo it. For e-commerce, look for a cancellation link in the confirmation email or on the order history page. For data deletion, look for a restore or recycle-bin mechanism. Evaluate whether the reversal window is clearly communicated to the user before they submit, not only after.
6. Screen reader walkthrough (VoiceOver + Safari on macOS/iOS): Navigate the entire checkout or submission flow using only the keyboard and VoiceOver. Confirm that the review screen reads all entered values in a logical order, that edit links are announced with sufficient context (e.g., "Edit shipping address" not just "Edit"), and that the final confirmation button's purpose is unambiguous.
7. Cognitive load check: Evaluate whether the review step is presented in plain language. A summary that lists raw database field names or uses legal jargon without explanation may technically qualify as a review screen but fail in practice for users with cognitive disabilities.

How to Fix

Single-step checkout with no review — Incorrect

<!-- Problematic: clicking "Complete Purchase" immediately charges the card -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Single-step checkout with review step added — Correct

<!-- Step 1: form collects data, submits to review page (not final) -->
<form action='/checkout/review' method='post'>
  <!-- payment and shipping fields -->
  <button type='submit'>Review Order</button>
</form>

<!-- Step 2: review page summarises all entered data and offers edit links -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Final button is clearly labelled as the binding action -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Irreversible data deletion with no confirmation — Incorrect

<!-- Problematic: delete button directly posts with no confirmation dialog -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Irreversible data deletion with confirmation dialog — Correct

<!-- Trigger button opens a confirmation dialog, not the destructive action -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Financial form with no inline validation — Incorrect

<!-- Problematic: no validation, wrong IBAN accepted silently -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Financial form with validation and review — Correct

<!-- Inline validation with aria-describedby for error association -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Submits to review page, not direct execution -->
  <button type='submit'>Review Transfer</button>
</form>

Common Mistakes

• Using a tooltip as a "review" mechanism: Displaying entered values in a hover tooltip before the submit button does not constitute a review step, because tooltips are not accessible to keyboard-only users or screen reader users and disappear before the user can act on them.
• Labelling the final button "Continue" instead of describing the action: A button reading "Continue" on a review page does not make clear that clicking it will complete a financial transaction. The button must unambiguously describe the binding action, such as "Place Order and Pay ₺850" or "Sign Contract."
• Providing a cancellation policy only in the terms of service: Burying the reversal mechanism in a linked legal document that most users will not read does not satisfy the reversible requirement. The ability to cancel and the window within which it is available must be communicated in the transaction flow itself.
• Using window.confirm() as the sole confirmation mechanism: Browser-native confirm dialogs are poorly supported by some assistive technologies, cannot be styled for readability, and are blocked in certain browser configurations. They should not be used as the only safeguard for high-stakes submissions.
• Resetting the form on validation failure without preserving valid field values: When a form fails validation, clearing all fields forces users — especially those with motor disabilities — to re-enter all data. Only the invalid field should be cleared or highlighted; all valid entries must be preserved.
• Placing the "Edit" link on the review page without programmatic association: An "Edit" link next to each data group must have a descriptive accessible name (e.g., aria-label='Edit billing address'). A bare "Edit" repeated multiple times is ambiguous for screen reader users navigating by links.
• Not announcing the review step to screen readers: If the review page loads without moving focus to the heading or a summary region, screen reader users may not realise they are on a review page at all and may activate the submit button without reading the summary.
• Treating the criterion as only applying to payment pages: The scope includes any legal commitment (subscription sign-up, consent forms, contract acceptance) and any user-data modification (deleting files, updating medical records, changing account settings). Developers often overlook administrative panels and settings pages.
• Offering reversal only by phone or email: If cancellation requires calling a support line, users with speech or hearing disabilities may be unable to access the reversal mechanism. The reversal path must itself be accessible — preferably an in-app cancellation flow.
• Skipping the criterion for mobile web views: Some teams implement a review step on desktop but use a condensed single-step flow on mobile to reduce screen space. The criterion applies equally to all viewport sizes and must not be omitted from responsive or mobile web implementations.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on 21 June 2025, establishes a comprehensive national accessibility framework that references WCAG 2.2 as its technical standard. The Circular mandates that digital services meet at least WCAG 2.2 Level AA conformance, which includes WCAG 3.3.4 Error Prevention (Legal, Financial, Data).

The entities explicitly covered by the Circular span a wide range of sectors. Public institutions and agencies are required to make all citizen-facing digital services accessible, including online applications, e-government portals, and digital identity services — all of which frequently involve legal commitments and data modification. Banks and financial institutions regulated by the BDDK (Banking Regulation and Supervision Agency) must comply, making 3.3.4 directly relevant to every online banking transaction, fund transfer, and loan application they offer. Hospitals and health institutions operating digital patient portals, appointment booking systems, and electronic health records must ensure that any data entry or modification in those systems meets error-prevention standards. Telecommunications providers with 200,000 or more subscribers — including Turkcell, Vodafone TR, and Türk Telekom — must ensure that subscription management, plan changes, and payment flows are covered. E-commerce platforms, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE) are also within scope, covering a substantial share of high-volume transactional web services in the Turkish market.

Compliance with 3.3.4 is not merely a technical checkbox under this framework. Organizations seeking the Erişilebilirlik Logosu (Accessibility Logo) issued by the Ministry of Family and Social Services must demonstrate full WCAG 2.2 AA conformance. The logo serves as a public trust signal and is increasingly expected by consumers and procurement bodies. Failure to implement error-prevention safeguards on financial or legal workflows can result in both the denial of the logo and potential administrative action under the Circular's enforcement provisions.

For Turkish organizations in the e-commerce and fintech sectors specifically, 3.3.4 aligns closely with existing consumer protection requirements under Turkish law. The Law on Consumer Protection (No. 6502) and associated e-commerce regulations already require clear pre-contractual information and cancellation rights for distance contracts. Implementing a WCAG 3.3.4-compliant review-and-confirm step simultaneously satisfies both the accessibility requirement and the consumer law obligation to present order summaries before binding a purchaser. This dual compliance makes investing in proper error-prevention UX a high-value, low-duplication effort for Turkish digital service providers.