Accessibility in your online shop: test the purchase journey

Does my online shop have to be accessible?

Since 28 June 2025, the BFSG has covered certain consumer services, including electronic commerce. An online shop through which consumers conclude contracts is the typical example.

There is an exemption for services provided by micro-enterprises with fewer than ten employees and an annual turnover or annual balance sheet total of no more than two million euros. Shops that are genuinely aimed only at businesses need to be assessed separately. The article on BFSG obligations explains the details. The work pays off even without an obligation: a purchase journey that works with a keyboard, magnification and a screen reader is usually clearer for everyone else too. Classify your specific offer against the law and have open legal questions reviewed by an expert; this article is not legal advice.

Which requirements apply to online shops?

In § 12, the regulation accompanying the BFSG (BFSGV) requires websites and apps to be perceivable, operable, understandable and robust. For electronic commerce, § 19 BFSGV adds that identification, authentication, security and payment functions must be accessible as well.

You must also provide information on the accessibility of the products you sell, insofar as the responsible economic operator, such as the manufacturer, makes it available. If the service conforms to harmonised standards published in the Official Journal of the EU, § 4 BFSG presumes that it meets the requirements those standards cover. WCAG 2.2 at level AA is a suitable practical working basis for shop teams.

How do you test the purchase journey step by step?

Use a product with variants, a typical delivery address and a real, available payment method in a suitable test environment. Test both guest checkout and logging in, if your shop offers both.

Repeat the run with the keyboard, at 200 per cent zoom, on a smartphone and with a screen reader. For each stage, note whether the task succeeds, succeeds only with a workaround, or fails.

• Product search and filters: Usability, clear labels and noticeable changes to the list of results.
• Product page: Meaningful image descriptions, accessible variants and availability.
• Basket: Changing quantities, removing products and following the totals.
• Checkout: Field labels, error correction and clearly explained required fields.
• Payment and confirmation: External redirects, returning to the shop and a recognisable completion.

Where do purchase journeys most often fail?

1. 1Colour or size options as small swatches without text names: with a screen reader you only hear ‘button’.
2. 2Filters that change the list of results without announcing the new number, such as ‘24 products found’.
3. 3Plus and minus buttons for the quantity without labels.
4. 4A basket that updates without screen readers announcing the change.
5. 5A cookie banner or fixed header that hides the focused element (WCAG 2.4.11).
6. 6Click targets on smartphones that are smaller than 24 × 24 CSS pixels without enough spacing (WCAG 2.5.8).
7. 7Error messages in the checkout that are only recognisable by a red border.
8. 8A CAPTCHA at login or when ordering, with no accessible alternative.
9. 9Information on shipping costs or delivery times that only appears when you hover over it with the mouse.
10. 10A basket reservation time that runs out and cannot be extended.

What belongs on an accessible product page?

Product images need text alternatives that show relevant features, such as colour, material or a special fastening. Price, unit price, delivery time and availability appear as real text on the page, not only in a graphic.

Size charts belong in a real HTML table with header cells. Product videos need captions. If the manufacturer provides information on a product’s accessibility, for example for an e-book reader, it belongs in the description. Variants should be built as selection fields with names, so that ‘Colour: navy, selected’ is announced. Notices such as ‘Only 2 left’ or a discount should not be recognisable only by colour or an icon.

How do you deal with payment providers and plugins?

Payment dialogs, review widgets and consent banners are part of the real user journey. The BFSG excludes third-party content that you neither fund nor develop nor control. For components you deliberately build into your purchase journey, do not rely on this exemption without checking.

Include external components in your tests and document problems. Ask the provider for information on accessibility and compare alternatives if necessary. Pay particular attention to redirects to the bank or payment service: does the focus land in a sensible place after returning, and is the order confirmation recognisable? Offer several payment methods where possible. If one fails, there is still another way to complete the purchase. An additional widget cannot simply repair an inaccessible checkout.

What accessibility information do you have to provide?

Under § 14 and Annex 3 BFSG, you describe the service, explain how it is carried out, set out how it meets the requirements and name the competent market surveillance authority. The Bundesfachstelle Barrierefreiheit (Federal Accessibility Centre) recommends making the information easy to find, for example via a link labelled ‘Accessibility’ in the header or footer. The information itself must be accessible. Describe specifically what you have implemented, such as keyboard operation, contrast, forms and payment methods, instead of just naming a standard.

Keep the information up to date when you change your checkout, theme or payment methods. § 14(3) BFSG requires changes in the way the service is provided to be taken into account appropriately.

What can an automated check do for a shop?

The Accessonaut BFSG check tests a publicly accessible page automatically and shows findings by importance. After the home page, also check a product page, a category page and forms. Test the steps behind the basket and payment manually. Repeat the check after theme and plugin updates, because templates can change in the process. A good result is not proof of BFSG conformance.