Accessibility

Accessible checkout: from basket to payment confirmation

20 February 2026Zensations

An accessible checkout enables customers to select products and variants, review their order, enter information and complete payment independently. The order form is only one part of this: the basket, authentication, payment provider and confirmation all belong to the purchase journey. If variant selection does not work with a keyboard, for example, or a payment error is indicated only in red, an otherwise accessible order button cannot compensate.

Test complete shopping journeys, including errors and interruptions. WCAG 2.2 Level AA, covering all applicable Level A and AA criteria, provides a useful technical target. The examples below are hypothetical test scenarios, not statements about particular shops or client projects. They explain what implementation should achieve and which observations support meaningful acceptance testing.

1. Define the assessment scope and responsibilities

Before implementation, identify the routes your shop actually offers: guest checkout, customer accounts, delivery options, vouchers and different payment methods. Also document where external systems take over. These include embedded payment fields, redirects to banks and identity checks. An assessment that stops at the handover to a payment provider does not establish whether customers can finish their purchase.

In Austria, the BaFG has applied to covered services since 28 June 2025, not automatically to every website. Microenterprises providing services are exempt if they employ fewer than ten people and have either annual turnover of no more than two million euros or an annual balance sheet total of no more than two million euros. Information-only offerings and exclusively B2B activities generally do not constitute consumer e-commerce; the classification of a contact form alone is disputed, according to WKO: Barrierefreiheitsgesetz im E-Commerce – FAQ. See our guide to accessible websites in Austria for details. WCAG and EN 301 549 are not interchangeable, and a technical audit does not establish complete legal compliance.

2. Treat variant selection as part of checkout

A hypothetical purchase starts with a shoe in a particular size and colour. Every option needs an understandable name, an identifiable state and keyboard support. Native selection controls or correctly implemented radio groups are often more robust than custom-built tiles. Colour swatches also need colour names. Unavailable sizes must be understandable as unavailable, rather than simply appearing paler.

If a variant changes the price, availability or delivery time, that information must be accessible before the item is added to the basket. A short status message can communicate relevant changes without moving focus. Check specifically: can someone select the required variant without a mouse? Does a screen reader convey selection and unavailability? Does the resulting basket item contain exactly that variant? A visual tick without a programmatically identifiable state does not pass this test.

3. Make basket changes understandable

Within the basket, the product, variant, quantity and price must clearly belong together. Several buttons named “Remove” are not particularly helpful in isolation; their accessible names should identify the relevant item. Quantity fields need labels and understandable limits. After an adjustment, both the item and the total should update consistently. A background process must not silently use a different price when the order is placed.

One hypothetical failure occurs when removing an item sends focus to the top of the page. The correction involves more than adding a success message. Define a useful next focus position, such as the next item or the heading of the empty basket. Qualifying status messages should be programmatically determinable without moving focus; the entire basket does not need to be read out repeatedly. Acceptance evidence consists of a reproducible interaction sequence with understandable feedback and no loss of orientation.

4. Simplify guest checkout and data entry

If you offer guest checkout, make that route easy to find alongside sign-in. Do not hide it as inconspicuous text below a dominant account creation option. Request only the information needed for the transaction, and distinguish required information from optional information using text. Delivery and billing addresses need clear grouping, while visible labels must be technically associated with their fields.

The WAI Forms Tutorial explains labelling, grouping and feedback as connected tasks. Use appropriate input purposes and autocomplete attributes rather than obstructing autofill. Under WCAG 2.2, information already entered during the same process should not be requested again unnecessarily; the specified exceptions still apply. Revealing fields specifically for a different billing address is more useful than presenting a second complete address block that everyone must work through.

Test with a hypothetical address containing a long street name and an apartment number. Does information remain after a validation error? Does the form accept plausible ways of writing an address rather than only its preferred pattern? Does a format example describe an actual requirement? These questions reveal barriers that tests using short sample entries often miss.

5. Support authentication without unnecessary memory tests

Account-based purchases need accessible sign-in and recovery. Password managers, pasting from the clipboard and clearly labelled password visibility controls support different ways of working. A hypothetical problem involves six separate code fields that prevent pasting and move focus unpredictably after every entry. A single field, or a carefully implemented multi-field solution, can remove that obstacle.

The WCAG criterion for Accessible Authentication (Minimum) restricts cognitive function tests while allowing for alternatives, assistance mechanisms and exceptions. It does not mean that every CAPTCHA is prohibited. Assess the route actually offered, including expired codes and account recovery. Security remains necessary, but it should not depend on a single sensory ability or on transcription. An accessible alternative must be discoverable and usable within the real process.

6. Test keyboard access, focus and mobile magnification together

It must be possible to complete the entire order without a mouse. Focus order should follow the task, and visible focus must provide orientation. Sticky headers, cookie notices or a fixed order bar must not entirely obscure the focused component under WCAG 2.2 AA. Keeping focus fully visible is the better design objective, but it goes beyond this particular minimum requirement.

A hypothetical delivery dialog needs appropriate initial focus, a contained tab sequence within the modal dialog, dismissal with Escape and meaningful focus restoration. ARIA attributes alone do not create that behaviour. Also test text resizing to 200 per cent and reflow at a width of 320 CSS pixels, taking the specified exceptions into account. An order button must not disappear into an area that cannot be reached by scrolling. Test the open dialog, not just the page underneath it.

The Web Content Accessibility Guidelines (WCAG) 2.2 generally require a contrast ratio of 4.5:1 for normal text and 3:1 for large text. Relevant control boundaries and graphical information require 3:1 where the criterion applies. At Level AA, target sizes generally need to be 24 by 24 CSS pixels, subject to exceptions; this does not create a universal requirement for a 24-pixel gap. Pay particular attention to small quantity controls and remove icons.

7. Report errors in ways that enable correction

Validation must explain what is wrong and how customers can proceed. “Invalid entry” rarely provides enough information for a postcode error. A specific message might explain that the postcode does not match the selected delivery country. Associate the message technically with the field, and do not identify the error through colour alone. When several errors occur, a summary linking to the affected fields can help.

A hypothetical form deletes the entire address after an invalid telephone number. The first correction is to preserve information, not to write a friendlier error message. Then define a consistent focus strategy, such as moving to the error summary after submission. Acceptance testing includes another attempt: can all errors be reached and corrected without re-entering valid information? Does a resolved error message reliably disappear? Is a server-side rejection handled as clearly as a local formatting error?

8. Treat payment providers as part of your purchase journey

External payment providers are not an invisible technical detail. Customers experience embedded card fields, bank approvals and return redirects as one shopping journey. Test every offered payment route in an appropriate test environment. For embedded frames, meaningful titles, field labels, focus transitions and reachable error messages matter. For redirects, the purpose and next step must be clear without relying exclusively on a new window.

Consider a hypothetical test case: someone cancels bank approval and then returns to an empty basket. An appropriate correction preserves the order context and explains whether an order or payment already exists. Record provider barriers with reproducible steps and agree responsibilities for remediation. Another payment method can help in practice, but it does not automatically make an inaccessible route conformant. Also test the return journey, timeouts and renewed authorisation.

9. Prevent financial errors before completion

Before placing an order that requires payment, customers must be able to understand what they are buying and the total amount involved. Present variants, quantities, delivery charges, the selected payment method and relevant delivery information clearly. Changes must remain reachable before the binding order is placed. Editing an address must not silently change the previously selected delivery method or price. Where a change has consequences, those consequences must become understandable again.

The criterion Error Prevention (Legal, Financial, Data) requires at least one specified safeguard for applicable transactions: reversibility, checking with an opportunity to correct, or review with confirmation and correction. A well-implemented order summary is a practical approach to this, not merely an additional screen. Test a hypothetical incorrect quantity: can it be identified and changed, and does the final confirmation actually show the corrected amount?

10. Avoid ambiguous payment states and duplicate orders

After payment has been initiated, a network interruption can leave the state unclear. “Error, please try again” is dangerous if the payment may already have been processed. Distinguish operationally between declined, cancelled, pending and confirmed. The interface must communicate that state clearly and provide a safe next action. An ongoing process should be announced accessibly without repeating the same message every second.

On the technical side, repeated requests should not accidentally produce duplicate orders or charges. Suitable server-side mechanisms, such as idempotency, complement an accessible interface; they do not replace it. Test a hypothetical double click, resubmission and use of the browser’s back button. A disabled button alone is insufficient evidence. What matters is that the interface, order system and payment status continue to represent one consistent transaction after an interruption.

11. Make confirmation and acceptance testing reliable

The confirmation page should clearly state whether the order has been received and whether payment is confirmed or still pending. Provide the order reference, summary and next steps as accessible text. An email supplements the confirmation but must not be the only way to recognise immediate success. If receipts are provided as PDFs, those documents also need accessible structure; a document that merely looks correct is not enough.

Combine automated checks with manual keyboard, screen reader and magnification testing. For every finding, document the starting state, steps, expected and actual behaviour, browser and assistive technology. Acceptance means repeating the same route after correction, including negative cases. Also check whether the change affects other payment methods. Include these scenarios in release checks, especially after changes to form libraries, payment integrations or shared dialog components.

12. Frequently asked questions and your next step

Is an automated checkout test enough?

No. Automated tools identify certain technical errors but cannot reliably assess the complete order journey, understandable correction routes or every focus transition. Manual testing remains necessary.

Does every shop have to offer guest checkout?

WCAG does not universally require guest checkout. If an account is required, however, sign-in, authentication and recovery within the assessed process must be accessible.

Is a payment provider outside the assessment scope?

You should not exclude it when evaluating the actual shopping journey. Record technical boundaries and responsibilities rather than assuming successful completion without testing.

Does WCAG 2.2 AA prove complete BaFG compliance?

No. Technical conformity and legal obligations are not identical. The specific scope of the law and any further requirements need separate assessment.

If you want to examine your purchase journey systematically, a Zensations accessibility audit is a useful next step. Bring your payment methods, known failure cases and access to a test environment. These provide the basis for a testable scope from product selection to confirmation. Our accessibility services also support subsequent implementation and quality assurance, without blanket promises of conformity.

Sources

Content reviewed on 7 November 2026.