WCAG 3.3.4 Error Prevention (Legal, Financial, Data)

What it asks

Some mistakes cost more than others. Sending a payment to the wrong account, signing up to a contract, deleting a year of records or submitting an exam cannot be shrugged off. This criterion covers pages that cause legal commitments or financial transactions, that modify or delete data the person controls, or that submit test responses, and asks for at least one of three protections.

The first is reversibility: the submission can be undone, such as a cancellation window on an order or a recycle bin for deleted items. The second is checking: the site checks what was entered for errors and gives the person a chance to correct them. The third is confirmation: the person can review, correct and confirm the information before it is final, which is what an order review page does. Any one of the three is enough.

It is not about every form. A newsletter sign-up or a contact form is out of scope. It is about the pages where getting it wrong has legal, financial or data consequences, and it is Level AA. A related Level AAA criterion, 3.3.6 Error Prevention (All), applies the same protections to every form.

Its official name is success criterion 3.3.4 Error Prevention (Legal, Financial, Data), at Level AA. It was added in WCAG 2.2, under guideline 3.3 Input Assistance and the principle Understandable. The W3C’s normative text says, in part:

“For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:”

From WCAG 2.2, W3C. Full explanation: Understanding 3.3.4 Error Prevention (Legal, Financial, Data).

Who it helps

People with cognitive disabilities, memory difficulties or reading difficulties, who are more likely to make a mistake in a long or complex process and less likely to catch it without a review step.

People with motor disabilities, who may press the wrong control by accident. Screen reader users and people with low vision, who cannot take in a whole form at a glance and benefit from a summary before committing. In truth, everyone who has ever deleted the wrong thing.

What passes and what fails

These pass

• A checkout with an order review page showing the items, the address and the total, with links to change each, before the "Place order" button.
• A "Delete account" button that opens a dialog asking the person to confirm, and explains what will be deleted.
• A deleted file that goes to a bin from which it can be restored for thirty days.
• A bank transfer form that checks the sort code and account number against the bank’s records and shows the account holder’s name before the payment is confirmed.
• An online test with a review screen listing unanswered questions before final submission.

These fail

• A "Delete" button in a table row that deletes the record at once, with no confirmation and no undo.
• A payment submitted directly from the card form, with no review of the amount and recipient.
• An account closure that takes effect in one click.
• A multi-step application that submits on the last step with no summary of what was entered.
• A test that submits automatically when the timer runs out, with no way to review beforehand.

How to test it by hand

1. List every process on the site that commits money, makes a legal agreement, changes or deletes stored data, or submits a test: checkout, transfers, subscriptions, account settings, record management, exams.
2. Go through each one with test details in a test environment where you can. Stop before any step that would really commit.
3. At the point of commitment, check for at least one protection: can it be undone afterwards, were the entries checked and could you correct them, or were you shown a summary to review and confirm?
4. Check the destructive actions on their own: delete buttons, "remove" links and bulk actions. Press one on test data and see whether a confirmation or an undo appears.
5. Write down every commitment point with none of the three protections.

What automated testing can decide

What a machine can decide

A tool can find the controls that look like commitments: buttons named delete, remove, pay, confirm, submit order, close account. For a destructive action it reaches on test data, it can record whether a confirmation dialog appeared or an undo was offered. For a process it is allowed to follow, it can record whether a review step came before the final submission.

What it cannot

Deciding which flows are legal, financial or data-changing is not something a page reveals. A "Submit" button may order a product or post a comment. The site owner knows which flows are in scope, and a tool should be told rather than guess. Following a real checkout or deletion on a live site is also exactly the kind of thing an automated tool must not do without permission, because it spends money and destroys data.

How Dreven handles it

Dreven asks you which flows are legal, financial or data-changing, rather than guessing. It never goes through a real checkout, deletion or other commitment without your say-so, and never takes a step that spends money or makes a commitment on a live site.

For each flow you ask it to test, you see whether a confirmation, a review step or an undo was present at the point of commitment, with a picture of that step, and a reviewer signs off each result. A flow that was not tested is listed as untested, never as a pass.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.3.1 Error Identification (Level A). Errors the site detects must be identified and described.
• 3.3.3 Error Suggestion (Level AA). When the fix is known, it must be suggested.
• 3.3.7 Redundant Entry (Level A). A review step should show what was entered, not ask for it again.
• 3.2.2 On Input (Level A). A form that submits itself when a setting changes gives nobody a chance to check.

Questions people ask

All WCAG 2.2 criteria, in plain words