Requires that legal, financial and data-changing submissions can be reversed, are checked for errors, or can be reviewed and confirmed first.
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.
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.
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.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.3.3.4 | Web pages | Web content must satisfy WCAG success criterion 3.3.4. |
| 10.3.3.4 | Non-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.4 | Non-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
Show everything the user entered, and let them correct it before the final step.
<form action="/pay"><!-- pay button pays immediately --></form><h2>Review your order</h2>
<dl>…</dl>
<a href="/checkout">Change order</a>
<button type="submit">Confirm and pay</button>A checkbox, unchecked by default, next to the submit button asks the user to confirm.
<button type="submit">Transfer funds</button><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>State a period within which the user can amend or cancel.
<p>Order placed.</p><p>Order placed. You can cancel or change it within 30 minutes from your <a href="/orders">orders</a> page.</p>Delay permanent deletion, or keep a log so a delete can be undone.
deleteBtn.addEventListener("click", () => purge(item)); // permanentdeleteBtn.addEventListener("click", () => {
moveToTrash(item);
showToast("Moved to trash", { action: "Undo", onAction: () => restore(item) });
});Explain what the action will do and ask to continue. Use a real dialog with focus management.
<button onclick="deleteAccount()">Delete account</button><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>A testing application should let users review and correct answers before submitting.
<button>Submit exam</button> <!-- no review of answers --><h2>Review your answers</h2>
<ol>…</ol>
<button type="submit">Submit exam</button>Native apps handle payments, deletions and sign-offs. Add a review step, a confirmation with a clear consequence, or an undo.
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.")
}
}
}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") } }
)
}
}