WCAG 3.3.4 · Level AA · EN 301 549 9.3.3.4

Error Prevention (Legal, Financial, Data)

Requires that legal, financial and data-changing submissions can be reversed, are checked for errors, or can be reviewed and confirmed first.

In brief

A slip on a shop page costs a few seconds. A slip in a payment, a contract or a deletion can cost money, rights or years of data. People who mistype, misread or mis-click, including those with reading or motor disabilities, need a chance to catch the mistake before it is final.

This criterion requires that, for pages that cause legal commitments or financial transactions, modify or delete user-controllable data, or submit test responses, at least one of three things is true: submissions are reversible, data is checked and the user can correct it, or there is a way to review, confirm and correct before finalising.

What does it cover?

  • Which pages: Pages that create legal commitments or financial transactions for the user, that modify or delete data that the user can control in a data storage system, or that submit user test responses.
  • Reversible: The user can undo the submission, for example by cancelling within a stated time (G164) or recovering deleted information (G99).
  • Checked: The data is checked for input errors and the user can correct them.
  • Confirmed: There is a mechanism to review, confirm and correct information before finalising (G98, G155, G168).
  • Only one is needed: At least one of the three. A review step is the most common.
  • Legal commitments: Transactions that create a binding obligation or benefit, such as a loan, a will or a contract.
  • Financial transactions: Costly or hard-to-change purchases or trades, such as non-refundable tickets or stock orders.
  • User-controllable data: Information users can view and choose to change or delete, such as contact details or past invoices. Internet logs and search-monitoring data are not included.
  • Proportion: The goal is to prevent serious, hard-to-reverse results, not to add a confirmation to every routine save.
  • Out of scope: Identifying errors is 3.3.1. Suggestions are 3.3.3.

Who does it affect?

People with reading or motor disabilities, who may mistype or miss an error. People with cognitive disabilities, who are more likely to make mistakes under pressure. Screen reader users, who cannot scan the whole page for an error. Everyone, since a safeguard against serious mistakes helps all users.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Protection against serious mistakes is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.4 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 3.3.4 appears in EN 301 549
ClauseType of ICTWhat it requires
9.3.3.4Web pagesWeb content must satisfy WCAG success criterion 3.3.4.
10.3.3.4Non-web documents (PDF, Office files)Documents must allow reviewing, correcting or reversing important submissions where the standard applies the criterion to them.
11.3.3.4Non-web software (native mobile apps)Software must let users reverse, check or confirm legal, financial and data-changing submissions.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.3.4 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A review page before payment (G98)

Show everything the user entered, and let them correct it before the final step.

Incorrect
<form action="/pay"><!-- pay button pays immediately --></form>
Correct
<h2>Review your order</h2>
<dl>…</dl>
<a href="/checkout">Change order</a>
<button type="submit">Confirm and pay</button>

2. A confirmation checkbox (G155)

A checkbox, unchecked by default, next to the submit button asks the user to confirm.

Incorrect
<button type="submit">Transfer funds</button>
Correct
<input type="checkbox" id="ok" required>
<label for="ok">I confirm that the amount and recipient are correct.</label>
<button type="submit">Transfer funds</button>

3. A time to cancel (G164)

State a period within which the user can amend or cancel.

Incorrect
<p>Order placed.</p>
Correct
<p>Order placed. You can cancel or change it within 30 minutes from your <a href="/orders">orders</a> page.</p>

4. Recover deleted data (G99)

Delay permanent deletion, or keep a log so a delete can be undone.

Incorrect
deleteBtn.addEventListener("click", () => purge(item)); // permanent
Correct
deleteBtn.addEventListener("click", () => {
  moveToTrash(item);
  showToast("Moved to trash", { action: "Undo", onAction: () => restore(item) });
});

5. Ask for confirmation (G168)

Explain what the action will do and ask to continue. Use a real dialog with focus management.

Incorrect
<button onclick="deleteAccount()">Delete account</button>
Correct
<button type="button" id="del">Delete account</button>
<dialog id="confirm" aria-labelledby="t">
  <h2 id="t">Delete your account?</h2>
  <p>This removes all your data and cannot be undone.</p>
  <button>Cancel</button> <button>Delete</button>
</dialog>

6. Let test takers review answers (G98)

A testing application should let users review and correct answers before submitting.

Incorrect
<button>Submit exam</button> <!-- no review of answers -->
Correct
<h2>Review your answers</h2>
<ol>…</ol>
<button type="submit">Submit exam</button>

Code examples for mobile

Native apps handle payments, deletions and sign-offs. Add a review step, a confirmation with a clear consequence, or an undo.

iOS (SwiftUI)

import SwiftUI

struct AccountView: View {
    @State private var confirmDelete = false

    var body: some View {
        Button("Delete account", role: .destructive) { confirmDelete = true }
            .confirmationDialog("Delete your account?",
                                isPresented: $confirmDelete,
                                titleVisibility: .visible) {
                Button("Delete", role: .destructive) { deleteAccount() }
                Button("Cancel", role: .cancel) { }
            } message: {
                Text("This removes all your data and cannot be undone.")
            }
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun DeleteAccount(onDelete: () -> Unit) {
    var confirm by remember { mutableStateOf(false) }
    TextButton(onClick = { confirm = true }) { Text("Delete account") }

    if (confirm) {
        AlertDialog(
            onDismissRequest = { confirm = false },
            title = { Text("Delete your account?") },
            text = { Text("This removes all your data and cannot be undone.") },
            confirmButton = { TextButton(onClick = { confirm = false; onDelete() }) { Text("Delete") } },
            dismissButton = { TextButton(onClick = { confirm = false }) { Text("Cancel") } }
        )
    }
}

How to test

  • List the high-risk actions: Find payments, orders, contracts, bookings, deletions, changes to account data and exam submissions.
  • Look for a safeguard: For each, is the action reversible, checked or confirmed?
  • Test the review step: Can the user see everything, go back and correct before the final step?
  • Test the undo: Can a deletion or order be undone or cancelled, and is the time to do so stated?
  • Check confirmations: Does the confirmation say what will happen and work with a keyboard and a screen reader?
  • Check scope: Is the data user-controllable? Logs and monitoring data are not included.
  • Use a checker as a starting point: Automated tools cannot tell which actions are high-risk or whether a safeguard exists. A person must walk through each process.

Common mistakes

  • A single-click payment with no review: The money is gone before the user checks.
  • Permanent deletion with no recovery: No undo, no trash, no confirmation.
  • A confirmation that does not explain: "Are you sure?" with no consequences.
  • A confirmation dialog that is not accessible: It cannot be reached or closed by keyboard.
  • Warning fatigue: Confirming every minor edit, which this criterion does not ask for.
  • No stated cancellation time: The user cannot know how long they have.
  • A review page that cannot be edited: The user must start over to correct a mistake.
  • Forgetting tests and exams: Answers submitted with no chance to review.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.