Accessible online checkout: a practical test for small businesses

A sale can fail long before payment is declined. A customer may be unable to choose a service, understand a form error or reach the order confirmation. Accessibility is therefore not a visual polish task: for a small shop, repair business or booking-based service, it is part of completing the customer journey.

For EU readers, the European Accessibility Act is the common starting point and covers certain e-commerce services. National implementation, scope and exemptions differ. In Germany, for example, the BFSG applies its main service rules from 28 June 2025 and has its own microenterprise definition. The EAA is not UK law; UK readers should check the applicable UK consumer, equality and sector rules. This article is operational guidance, not legal advice.

Test the completed task, not just the homepage

Use a real task: find a product or appointment, select a required option, enter details, check the total and receive confirmation. The question is not merely “can someone see it?” but “can they complete it without guessing?”

A 25-minute release check

1. Start at the homepage using only Tab, Shift+Tab, Enter and Space.
2. Find one offering, select all required options and add it.
3. Change the basket and remove an item.
4. Submit deliberately invalid form data first.
5. Correct every error without a mouse. The message should explain what is wrong and how to fix it.
6. Open and close dialogs, consent choices and payment options; focus should move predictably and return to its trigger.
7. Check the confirmation on a narrow viewport and at browser zoom.
8. Record browser, device, date, path and blocker—not only pass/fail.

Automated checks are useful for repeated technical defects, but they cannot prove that a checkout is understandable. Keep a manual keyboard run in the release process and, where possible, include feedback from people using different assistive technologies.

A practical technical baseline

The WCAG 2.2 gives teams a shared language: perceivable, operable, understandable and robust. It is not a blanket legal guarantee. A resilient implementation still starts with familiar basics:

• use semantic HTML before ARIA: real buttons, labels, headings and lists;
• provide visible focus and a logical focus order;
• pair field-level error text with a linked error summary;
• communicate totals, availability and success/failure without colour or motion alone;
• mark the page language and genuine language changes;
• offer a plain support route when the digital route is blocked.

Treat suppliers as part of the checkout

Payment, scheduling, consent, maps and chat components can sit outside your code but inside your customer’s path. Keep a short supplier record: purpose, locations, owner, version/configuration, known limitation, accessibility contact and fallback.

At procurement or renewal, ask for dated conformance information, known issues and remediation plans, keyboard and screen-reader test evidence, and confirmation that custom styling cannot break accessible defaults. A supplier statement does not replace testing your configured journey.

Accessibility becomes manageable when it is treated as quality control: test a small path, record what happened and repeat after every change.