The Accessibility Act for online shops: where the money actually leaks.

The purchase journey, step by step, and what breaks

Step	Typical barrier	What the customer experiences
Search and filters	Results update silently after a filter change	A screen reader user hears nothing and assumes the site froze
Category listing	Infinite scroll with no keyboard route to the footer	Pagination and legal links become unreachable
Product page	Gallery operable only by swipe or hover	Images cannot be reviewed before buying
Variant picker	Colour or size as unlabelled swatches	The selection is made blind, or not at all
Cart	Quantity changes without announcement	The total is wrong and the customer does not know why
Checkout form	Placeholder instead of label, errors shown only in red	The order fails repeatedly with no explanation
Payment step	Third-party iframe with its own focus trap	The keyboard cannot leave or complete the payment
Confirmation	Success message not announced	The customer pays twice, or calls support

Six of those eight are ordinary development work: labels, announcements, focus management. Two involve a supplier, and those are the ones worth raising with the supplier in writing, because you are not the only customer asking.

What the statement says while you are still fixing

Very few shops pass a first audit cleanly, and the Directive does not expect them to. What it expects is a truthful description and a route for the customer. A statement published mid-remediation typically names three or four issues in plain language, gives the alternative available today, and a quarter for resolution.

The alternative matters more than shop owners expect. If the variant picker is not yet operable by keyboard, a phone line or an email address that can place the order is a real alternative, and saying so protects the customer and you. The annotated example shows exactly how that paragraph is written.

What testing a shop actually involves

1. A real basket. We buy something: search, filter, choose a variant, add, change the quantity, apply a code, reach payment. A test that stops at the product page misses everything that matters.
2. Keyboard only. The same journey without touching the mouse, watching focus order, traps, skip links and the behaviour of every overlay and pop-up on the way.
3. Screen reader. The journey again with assistive technology on desktop and on mobile, checking names, roles, states, announcements and error association.
4. Stress conditions. Zoom to 400%, reflow at 320 pixels, increased text spacing, reduced motion, and the site in its dark mode if it has one.
5. Support paths. Contact form, chat widget and help pages, because a barrier plus an unreachable support channel is a complaint waiting to happen.

The method is the one described on the audit page, applied to the flows where a shop earns money.

Five findings we see in almost every shop

None of what follows comes from a checklist of theoretical criteria. These are the items that appear, in some form, in nearly every first audit of a working shop, regardless of platform or budget.

The filter that updates silently. A customer selects a size, the grid refreshes, and nothing is announced. Sighted users see the change; everyone else waits. The fix is a live region and a short message stating how many products remain, and it takes a developer an hour.

The swatch without a name. Colour options rendered as coloured squares with no text. To a screen reader they are unlabelled buttons, so the customer chooses at random or abandons. Adding the colour name as accessible text costs nothing and also helps people who do not distinguish the shades visually.

The discount code error. The code is rejected, the message appears in small red text above the field, and it is neither announced nor linked to the input. The customer retypes the same code three times and leaves convinced the site is broken.

The pop-up that arrives on scroll. Newsletter overlays typically take focus without returning it, so keyboard users end up trapped behind a modal they cannot close. This is the single most common blocking issue we find, and it is usually installed by marketing rather than engineering.

The confirmation nobody hears. Payment succeeds, the page updates in place, and the success message is a visual banner with no announcement. Support then receives a call asking whether the order went through, which costs more per incident than the fix.

A sixth deserves its own line because it is invisible until someone tries: the session timer. Checkouts that expire a basket after a fixed period are common, and for a customer who types slowly, uses speech input or reads with a screen reader, a ten-minute window is not generous. The Directive does not ban timers; it asks that the user can extend them. A single control offering more time solves it, and it also rescues the sighted customer interrupted by a phone call.

Who owns this inside a shop

In practice three teams touch the same pages. Marketing installs apps and campaign banners, the agency owns the theme, and a platform vendor owns the checkout. When nobody owns accessibility, each change is safe in isolation and the sum is a barrier. The organisations that keep a clean result do one simple thing: the monthly test result goes to a named person who decides, every month, whether anything new needs a ticket. It takes ten minutes and it prevents the annual rediscovery of the same problems.