Why a form should show people their answers before it takes them

Someone mistyped their date of birth on page two, pressed the button on page eleven, and never saw page two again. What lands on your side is a support ticket, a correction email, and a duplicate submission to reconcile.

A check-your-answers page fixes that for the price of one screen, and for a large class of forms it is not a nicety: WCAG 2.2 success criterion 3.3.4 names review-and-confirm as one of exactly three ways to satisfy a Level AA obligation. Below is the spec — what goes on the page, what stays off it, and the case almost nobody writes down: questions the respondent was never asked.

What a check-your-answers page is

One page, after the last question and before the action that cannot be taken back. Structurally it is boring, and that is the point:

• A heading that names the job — "Check your answers before sending your application", not "Summary".
• One row per question the respondent answered: the question as it was worded on the page they saw, and their answer as they gave it.
• A change link on every row, labelled with the thing it changes.
• A declaration above the button, if the process needs one.
• A submit button whose label names the action: "Send your application", not "Submit".

Nothing on it is decorative. Every element does one of two jobs: helping the respondent find a mistake, or letting them fix it without starting over.

It is not a nicety — it is one of three ways to satisfy WCAG 3.3.4

Reversible, checked, or confirmed

3.3.4 Error Prevention (Legal, Financial, Data) is Level AA, and any one of three mechanisms meets it. Submissions are reversible. Or data is checked for input errors and the user gets a chance to correct them. Or, in the criterion's own words, "A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission."

Most teams reach for the second, because validation was on the build list anyway. It is also the weakest. A validator can tell you 1987-13-04 is not a date. It cannot tell you the respondent meant 1978. Format checking is blind to input that is well-formed and wrong — the whole category of mistake a person makes on question nine of eleven.

Reversibility sometimes exists and often does not, because the submission reached a payroll run three seconds later. Route three is the only one that catches a valid but wrong answer, because it is the only one that puts the answer back in front of the person who knows what it should have said.

When 3.3.4 actually binds

It applies to pages that cause a legal commitment or a financial transaction, that modify or delete data the user controls, or that submit test responses. W3C's supporting notes are broader than people expect: alongside stock trades, loans and wills they list contracts of any type, and they count updating an account phone number or deleting past invoices as user-controllable data.

Read that against your own forms and the boundary moves. A sign-up that starts a paid subscription is a contract. A form that changes a delivery address modifies user-controllable data. Plenty of forms are still outside — a contact form, a newsletter signup — and assuming you are outside because your form is short is how teams get this wrong.

The structural point: you need a page, not a plugin

The confirmed route needs somewhere to live. If your builder renders one long scrolling list of fields with a button at the bottom, there is no "before finalizing" — the last field and the irreversible action share a screen. Hand-rolling a summary block above the button gives you a second rendering of the form's state, and second renderings drift.

In Vellform, review is a page kind. Four of them work — Page, Cover, Review and Ending — and Review is one of four page kinds you place in the page graph like any other node, wherever the check belongs. Adding one is a structural edit, not a widget dropped on a screen. That matters for the next section: the route through that graph is also what decides which questions a given respondent was asked.

The criterion next door: 3.3.7 Redundant Entry

3.3.7 is Level A — a lower bar, so a wider obligation. Information already entered in the same process must be auto-populated or offered for selection rather than asked again, with exceptions where re-entry is essential, needed for security, or where the earlier answer is no longer valid.

It does not require a review page. It requires the opposite: not asking twice. But the review page is where you find out that you did. Read your own summary top to bottom and a second "Email address" row is impossible to miss.

What goes on the page

Every question they answered, in the order they answered it

Not database order, not alphabetical, not grouped by your schema. The respondent is checking the page against a memory of typing it, and that memory is sequential. Reorder the rows and they have to read all of them instead of scanning to the one they are unsure about. Past roughly ten rows, break the list with headings mirroring the form's own sections.

An optional question they left blank

Show the row, with "Not provided" where the answer would be. The blank is the only signal the respondent gets that they skipped something optional, and some of them change their mind once it is stated. The gov.scot pattern is explicit: unanswered optional questions appear, marked as not answered.

A question on a branch they were never routed past

Do not show it. Not with "Not provided", not greyed out, not with an em dash in the answer column. It was never asked, so there is nothing to check, and a row for a question they have never seen produces a small panic: did I miss a page?

gov.scot states the rule outright — do not show questions the user was not asked because of form logic. The trouble is telling the difference. If the only thing you have to read afterwards is the answer map, "asked and left blank" and "never asked" both arrive as a field with no value in it. There is no third state in the data, so a summary built from answers alone prints a blank row and hopes.

What makes the third state recoverable is that the routing rules are kept apart from the answers. A rule whose target is a page moves the respondent off the straight line, using one of 10 operators to describe the condition — so replaying those rules against their answers reproduces the route they took. "Never asked" is then the absence of a page from that route: something you derive, rather than something you guess from an empty value. Field-level show and hide rules replay the same way, one level down — given the same answers, the same fields were on screen.

That distinction outlives the review page. It is the same "asked versus answered" distinction in your webhook payload, and the same branching is why a branching form can't honestly say "Step 3 of 7".

Change links, labelled with what they change

One per row, and the visible label should name its destination: "Change your delivery address", not "Change". A screen reader user listing the page's links gets twelve entries reading "Change", which is a list of nothing. If your design system insists on the short label, gov.scot's pattern uses aria-describedby pointing at the question text — the compromise, not the target.

The link returns to the question page with the field pre-populated. Do not clear it; someone fixing one typo in three sentences should find three sentences waiting. When they are done, that page's button returns them to review, not onward through a form they already finished.

When a change reroutes the branch

Re-ask only what the new path requires, then return to review. Someone answered "No" to a question that routed them past a three-page branch; on the review page they change it to "Yes". The pages they saw are now off the path, and the pages the new answer needs have never been shown. gov.scot describes the behaviour: the question page's button either returns the user to check-answers or diverts them through further questions following the logic, and the summary comes back updated.

File uploads and signatures

Show the filename and the size. A row saying "Uploaded" is not a review: the respondent has three similarly named PDFs and cannot tell you which one went. Show a signature as the image they drew, big enough to recognise, and give a way to replace either. None of the public pattern pages cover this — gov.scot stops at text answers, which is a gap rather than a consensus. Vellform supports uploads and signatures, so the decision is yours.

The button says what happens next

"Submit" describes an HTTP verb, not a consequence, and the point of this screen is that the respondent understands what is about to become irreversible. Write the consequence: "Send your application", "Book the appointment", "Delete these three records". gov.scot says the same — tailor the button text to what the form does. A declaration, if you need one, goes immediately above the button as text; make it a checkbox only when you need an individually recorded consent.

Does a review step hurt completion?

The honest answer

It adds a screen. It removes the most common cause of a re-submission. I am not going to hand you a percentage for either, and be suspicious of the ones you will find — the completion figures circulating for this pattern trace back to nothing you can check: no form, no sample size, no counterfactual. The number that matters is completion rate multiplied by correctness. A form submitted with the wrong phone number completed perfectly and then cost somebody an hour.

Where it earns its place, and where it does not

• Long forms — past about eight questions, nobody remembers page two by the time they reach page eleven.
• Forms with a commitment at the end: an application, a booking, a declaration.
• Forms where a wrong answer costs a human being a phone call — an address, a date, a reference number.
• Forms the respondent cannot easily send again: one application per person, a deadline, an account that now exists.

A three-field contact form does not need one, and neither does anything the respondent can resubmit in ten seconds. If submission is effectively reversible you already satisfy 3.3.4 by the first route, and a review page costs a screen while buying nothing.

After the review step

The Ending page and what a confirmation must contain

Ending is the fourth working page kind, and the confirmation has three jobs: say the thing is done, give the respondent something to keep, and say what happens next and roughly when. If your process issues a reference, put it in the page text, not only in a message that may never arrive. "Thanks!" over a green tick is not a confirmation; it is a colour.

The part the respondent cannot see

A respondent sees a confirmation the moment they submit; whether the delivery to your systems succeeded is a separate story, told on a separate page. Vellform's webhook delivery is three attempts in total, roughly one second and then roughly four seconds apart, signed with HMAC-SHA256 over the raw request body. The Ending page does not wait on any of it, and should not. What happens to the submission after they confirm is a question for your side of the wire.

To find out whether your own review page handles branches correctly: build a form with a single split, take both routes, then go back from the summary and change the answer that decides the split. Ten minutes, and it surfaces the stale-branch bug immediately if you have one. Build one free — 25 credits a month, no card covers it.