Can customers catch a costly mistake before confirming checkout?

Recognise the consequential action

A checkout can move from browsing to a financial commitment in one click. The customer may have selected the right product but the wrong quantity, delivery address, date or payment route. A final review gives them a chance to detect a costly mistake before that click has consequences. WCAG 2.2 success criterion 3.3.4 applies to web pages that cause legal commitments or financial transactions, modify or delete user-controllable stored data, or submit test responses. It requires at least one of three approaches: a reversible submission, a check for input errors with a chance to correct them, or a mechanism to review, confirm and correct information before final submission. The choice depends on the transaction. It does not mean every ordinary save needs a confirmation screen.

First map the point of commitment in your actual flow. A basket update may only change a temporary selection; pressing Place order may accept a price and delivery terms; a later payment step may create another consequence. For services, a booking may reserve a scarce slot or trigger a cancellation policy even if money is collected later. Write down what becomes difficult to change after each step, and what the customer was told at that point. The review should sit immediately before the relevant commitment, not several screens earlier while the details can still change. If a third-party payment page controls the final step, check where your own order is created and what state returns if the payment result is uncertain.

A confirmation step is useful only if it shows the facts the customer can act on. Include item identity and meaningful variant, quantity, unit and total amounts, currency, delivery or service address and time where relevant, additional charges, payment method description and any condition that materially changes the decision. The W3C's order example mentions items, quantities, shipping address and payment method. Avoid burying a material change behind a collapsed panel or replacing actual details with a generic statement that everything is correct. The review is not a second sales page: its job is to let the person compare the intended transaction with the one the system is about to record. Use the same labels and amount basis as earlier steps.

Make every important detail correctable

The W3C's G98 technique describes two practical approaches for a multi-page flow: let the person move back to earlier steps while retaining entered data, or show a final summary with a way to correct it. The technique is an example of meeting the criterion, not a compulsory page design. An Edit address link should open the address field and return the customer to an updated summary. An Edit quantity link should recalculate the total and show any stock or delivery effect. If the correction changes a price, promotion or availability, highlight the new result and ask for confirmation of that result. Do not use a review screen that forces the customer to start over or loses the choices they already entered.

Check for errors at the appropriate moment, but do not confuse technical validation with a correct decision. A valid postal address can still be the wrong address for this order. An integer quantity of ten may be allowed by the software while the customer intended one. A delivery date might be within the allowed range but still unsuitable for the recipient. A review step catches these semantic mistakes by exposing the complete transaction in readable form. Conversely, a review page does not excuse weak field labels or unclear error messages earlier in the process. If the system knows that a value is invalid, identify the field and explain how the customer can correct it before final commitment.

Use a clear button label for the actual action. Review order should move to review; Confirm and place order should perform the consequential submission. If payment happens at another step, describe that sequence honestly. The button text, amount shown beside it and confirmation message should agree about whether an order has merely been saved, accepted or paid. Protect against accidental repeated submission, but do not rely on disabling a button as the only safeguard. After the click, show a receipt or a pending state with a stable reference. If the network response is lost, the page should offer a way to check the result rather than inviting an unqualified second order. This is a separate system reliability concern that supports a truthful review flow.

Be exact about changes after submission

Some businesses can make submission reversible for a stated period instead of relying on a pre-submit review alone. W3C's G164 technique says the page should state how long an online request can be amended or cancelled and the procedure for doing so. Its examples are examples, not a universal cancellation period. Do not copy an illustrative number into your own terms. Use the real policy, including when the period begins, which order types are excluded and whether the route is online or through another accessible channel. If the business cannot reliably stop fulfilment after a certain point, do not promise that every confirmed order can be reversed. A vague Contact us message leaves the customer unable to judge their actual options.

A business may choose review and correction before submission even if post-submit cancellation is difficult. For custom work, a delivery slot or a non-returnable service, that choice may be especially useful. Explain material restrictions before the final button and keep the summary consistent with them. Do not present the existence of a checkbox as proof that the customer understood a hidden term. If a checkbox is used, make its statement specific and keep the surrounding decision details visible. W3C lists a checkbox among possible techniques for certain situations, while the normative criterion offers alternative routes; the best route is the one that actually lets this customer prevent an important error in this particular transaction.

Make post-submit states visible to support staff too. A customer who spots a wrong address moments after paying needs to know whether the order is awaiting fulfilment, already handed to a carrier, or still awaiting payment confirmation. Staff should not promise an amendment until they know whether the downstream system can accept it. Record the customer request, the order state at that time and the action taken, then send a clear outcome. The review screen reduces avoidable mistakes but will not eliminate every correction request. An owner should therefore test both the before-submit path and the after-submit support route, especially where multiple sales channels and fulfilment partners are involved.

Test the decision with realistic tasks

Use a hypothetical checkout test: a customer selects one product, enters a delivery address and proceeds to the final review. Before confirming, change the quantity from one to two and check that the amount, delivery estimate and any threshold-dependent promotion update together. Then edit the address and verify that the summary shows the new address, not the old one. Test with a keyboard and a screen reader so the headings, edit controls, changed totals and final action remain understandable without visual scanning. The figures in this exercise are test inputs, not measured conversion results. Record what the customer was shown and what the resulting order stored; those two records should tell the same story.

Finally, review an exception: the customer presses confirm just as a product becomes unavailable or a price rule changes. Decide whether the system honours the reviewed offer, asks for fresh confirmation of a changed offer, or stops the order with a clear explanation. Never silently substitute a new total after the user reviewed an earlier one. Check how the policy works on mobile screens, translated content and an interrupted connection. The owner can begin with one consequential order type and ask the team to demonstrate three things: the full decision is visible, each material detail can be corrected, and the resulting order matches the confirmed summary. That is a practical acceptance test grounded in the W3C criterion rather than a decorative extra page.