Who is covered — and who is not
The German Accessibility Improvement Act (Barrierefreiheitsstärkungsgesetz, BFSG) transposes the European Accessibility Act into German law and has applied since 28 June 2025. It covers electronic commerce services aimed at consumers: the classic B2C online shop, booking and appointment journeys, retail banking, long-distance and air passenger transport, telecommunications and e-books. What matters is not whether you think of yourself as a shop, but whether someone can conclude a contract with you online. Anyone covered who does not meet the requirements has to expect objections from the market surveillance authorities. Alongside this, competition-law warning letters are circulating that attack BFSG breaches through § 3a of the German Unfair Competition Act (Gesetz gegen den unlauteren Wettbewerb, UWG); whether that argument holds has not yet been decided in court.
Two groups stay outside. Purely B2B offerings are in principle not covered, because the act is aimed at consumers. For services there is an additional exemption for micro-enterprises: fewer than 10 employees and no more than 2 million euros in annual turnover or annual balance sheet total. For products that exemption does not apply. Federal public bodies have been obliged for years anyway under BITV 2.0, the German federal accessibility regulation, and the states and municipalities under their own legislation — a different legal framework. Whether your offering is covered in a given case is for a lawyer to assess; we implement the technical requirements. And one widespread misunderstanding while we are at it: § 38 BFSG does contain transitional periods, but they concern products and self-service terminals — not websites and online shops. For those, 28 June 2025 applied without a grace period.
The benchmark: EN 301 549 and WCAG 2.1 AA
The practical benchmark for testing is the European standard EN 301 549 — it describes the recognised state of the art; what is legally binding is the BFSG and the BFSGV, its implementing regulation. The version currently cited in the Official Journal of the EU refers, for web content, to the Web Content Accessibility Guidelines in version 2.1, conformance level AA; a successor version with WCAG 2.2 AA has been announced. So we already test against 2.2 — the additional criteria are manageable and save a second round. This is not a catalogue of opinions but a list of testable criteria.
In practice that means: sufficient colour contrast, at least 4.5:1 for normal text. Full keyboard operation, with a visible focus at every stop. Alternative texts that convey what an image shows rather than its file name. Correct HTML semantics and a heading hierarchy that follows the structure, not the layout. Labelled form fields with error messages that say what to do. Information never conveyed by colour alone. Zoom to 200 per cent without loss of information. Captions on video. ARIA only where native HTML is not enough. Plus an accessibility statement with a way to send feedback.
Why overlays solve nothing — and how testing works
An accessibility overlay — often sold as an “accessibility widget” — is a script that lays itself over a website and offers font sizes, contrasts or a read-aloud function. It does not repair what lies underneath. If a button has no label, it still has none with the widget in place; if the heading structure is wrong, it stays wrong. Accessibility happens in the markup, not in an embedded script. Screen reader users have long worked with their own assistive tools anyway — an overlay tends to get in their way rather than help.
Testing is no push-button job either. Automated tools such as axe, Lighthouse or WAVE reliably find what a machine can decide: missing alternative texts, insufficient contrast, broken labels. Whether an alternative text actually describes the image, whether the tab order follows any sense, whether a dialogue keeps the focus — that only shows up in a manual test. So we test in two stages: automated across the whole site, manual with keyboard and screen reader on the journeys that really matter.
Implementation in existing systems and in new builds
With existing systems we begin with an audit: representative pages and the complete purchase, booking and contact journeys, tested against WCAG 2.1 AA. Out of that comes a prioritised plan of action — first the blockers that make an order impossible, then the defects that make it harder, and finally the details. You can see what will cost effort and what is done in an afternoon. Implementation happens in TYPO3, WordPress and Shopware 6, in the theme and in the templates.
In new projects accessibility is not an addendum but part of the plan, the design and the frontend. Contrasts are fixed in the colour system, components are built to work with a keyboard from the start, and editors learn how to maintain alternative texts and headings. One side effect we do not make the main argument: what is cleanly structured for a screen reader is also read better by search engines and AI assistants. Semantics pays twice. We answer questions about the state of your website Monday to Friday, 9:00 to 16:00 CET, on +49 441 21 21 63 0 or at info@sharpness.de.