European Accessibility Act im B2B-Shop: was Spryker-, Pimcore- und TYPO3-Teams beheben müssen

Der European Accessibility Act (Richtlinie 2019/882) gilt seit dem 28. Juni 2025. In Deutschland ist er das Barrierefreiheitsstärkungsgesetz (BFSG), in Österreich das Barrierefreiheitsgesetz (BaFG). Die meisten Artikel dazu richten sich an Consumer-Shops. Von B2B-Teams auf Spryker, Pimcore und TYPO3 höre ich eine andere Frage: „Wir verkaufen nur an Unternehmen, also sind wir raus, oder?“

Die ehrliche Antwort lautet „wahrscheinlich ja, wenn du es belegen kannst, und es ist trotzdem vielleicht die falsche Frage“. In diesem Artikel gehe ich den genauen Wortlaut des Anwendungsbereichs durch, die Kleinstunternehmen-Ausnahme, die Durchsetzung im Oktober 2026, was WCAG 2.2 und EN 301 549 praktisch bedeuten, wo B2B-Shop-Frontends typischerweise brechen und wie ich testen und nachbessern würde. Das ist technische Beratung, keine Rechtsberatung: Lass den Anwendungsbereich für deinen Shop von deiner Rechtsberatung bestätigen.

Gilt das Gesetz für einen B2B-Shop?

Der Anwendungsbereich steckt in den Definitionen. § 1 Absatz 3 BFSG nennt „Dienstleistungen im elektronischen Geschäftsverkehr“ unter den erfassten Diensten, und § 2 Nummer 26 definiert sie als digitale Dienste, die über Webseiten und mobile Apps angeboten und elektronisch auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden. Verbraucher ist nach § 2 Nummer 16 jede natürliche Person, die den Dienst zu Zwecken in Anspruch nimmt, die überwiegend weder ihrer gewerblichen noch ihrer selbstständigen beruflichen Tätigkeit zugerechnet werden können.

Die Bundesfachstelle Barrierefreiheit sagt es in ihren FAQ klar: Dienstleistungen, die ausschließlich im B2B-Bereich angeboten werden, sollten nicht vom BFSG betroffen sein. Die Wirtschaftskammer Österreich beschreibt das BaFG genauso, nämlich E-Commerce-Dienstleistungen im Rahmen eines Verbrauchervertrags. Das Gesetz ist also von der Konstruktion her B2C. Für Entwickler zählen zwei Details. Erstens entscheidet, wer in der Praxis bestellen kann. Zweitens ist „Verbraucher“ eine natürliche Person außerhalb ihres Berufs: Ein Firmenkonto mit UID ist eindeutig draußen, ein anonymer Besucher, der als Privatperson kaufen kann, nicht.

• Offene Registrierung: Jeder kann ein Konto anlegen, und kein Schritt prüft, ob der Käufer ein Unternehmen ist.
• Gastbestellung mit Privatadressen oder eine Zahlungsart, die typisch für Verbraucher ist.
• Öffentliche Preislisten mit sichtbarem „Kaufen“-Button, ohne Login-Schranke und ohne Business-Hinweis in den AGB.
• Ein B2B2C-Setup, zum Beispiel ein Händlerportal, in dem der Händler über deinen Shop an Privatkunden weiterverkauft.
• Ein „B2B“-Hinweis im Footer, während der Bestellablauf selbst nie nach einem Unternehmen fragt.

Kleinstunternehmen, Fristen und Durchsetzung 2026

Die Kleinstunternehmen-Regel steht in § 3 Absatz 3 BFSG: Die Barrierefreiheitspflicht gilt nicht für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen. § 2 Nummer 17 definiert sie als Unternehmen mit weniger als zehn Beschäftigten und entweder höchstens 2 Mio. Euro Jahresumsatz oder höchstens 2 Mio. Euro Bilanzsumme. Die Ausnahme gilt nur für Dienstleistungen, ein Unternehmen, das Produkte in Verkehr bringt, bleibt dafür erfasst. Das österreichische BaFG nutzt dieselben Schwellen. Ich würde die Ausnahme nicht annehmen, ohne die Zahlen mit der Rechtsberatung geprüft zu haben.

Bei den Übergangsfristen darfst du für einen Webshop nicht viel erwarten. § 38 erlaubt, Produkte, die vor dem 28. Juni 2025 rechtmäßig eingesetzt wurden, bis zum 27. Juni 2030 weiter zu nutzen, und vor diesem Datum geschlossene Verträge dürfen unverändert bis zu ihrem Ablauf fortbestehen, längstens bis zum 27. Juni 2030. Ein Storefront, den du änderst, neu gestaltest oder erweiterst, ist praktisch kein Altprodukt.

Deutschland: Die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) in Magdeburg wurde am 26. September 2025 formell gegründet, hat rund 70 Beschäftigte und beschloss Ende Januar 2026 ihre Überwachungsstrategien. Sie arbeitet beschwerdeorientiert, ergänzt durch risikobasierte Prüfungen: Dienste mit hoher Reichweite, Angebote mit Bedeutung für die selbstbestimmte Lebensführung und Anbieter mit schlechter Historie, mit automatischen Scannern für Webdienste und EN 301 549 als Maßstab. Verbraucher und anerkannte Verbände können die Behörde um ein Verfahren bitten (§ 32). Die Eskalation läuft über eine Aufforderung zur Korrektur mit Frist, eine zweite Aufforderung mit Untersagungsandrohung und schließlich ein Vertriebsverbot. Das Bußgeld für das Anbieten einer Dienstleistung entgegen § 14, was die Informationspflicht zur Barrierefreiheit einschließt, beträgt bis zu 100.000 Euro, für andere Verstöße wie eine unbeantwortete Behördenanfrage bis zu 10.000 Euro (§ 37). Praktiker berichten außerdem, dass Abmahnungen von Wettbewerbern seit Ende 2025 zugenommen haben, ob das Wettbewerbsrecht bei BFSG-Verstößen genutzt werden kann, ist aber Mitte 2026 nicht durch Rechtsprechung geklärt.

Österreich: Zuständig ist das Sozialministeriumservice. Verbraucher können sich kostenlos beschweren, es gibt einen Schlichtungsschritt, und Verwaltungsstrafen reichen bis zu 80.000 Euro, für kleinere Unternehmen mit niedrigeren Grenzen. Die Europäische Kommission hat Deutschland im März 2026 außerdem eine mit Gründen versehene Stellungnahme zur unvollständigen Umsetzung geschickt, was mir zeigt, dass sich nationale Details noch bewegen können.

Mein Fazit für B2B-Teams: Mit einer glaubwürdigen reinen B2B-Position ist das Durchsetzungsrisiko heute gering. Bist du ein Hybrid-Shop, gehe davon aus, dass du erfasst bist, und betrachte 2026 als das Jahr, in dem die Schonfrist endete.

Was du erfüllen musst: EN 301 549, jetzt WCAG 2.1, bald 2.2

Das Gesetz selbst bleibt abstrakt: Dienste müssen für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sein (§ 3 Absatz 1 BFSG). Die konkrete Latte ist die harmonisierte Norm. Die Einhaltung von EN 301 549 begründet eine Konformitätsvermutung, und das Webkapitel von EN 301 549 in Version 3.2.1 verweist auf WCAG 2.1 Stufe A und AA.

Im September 2026 hat sich das geändert. EN 301 549 in Version 4.1.1 wurde veröffentlicht, übernimmt WCAG 2.2, ergänzt sechs Anforderungen, streicht das überholte Kriterium 4.1.1 Parsing und ist die erste Version, die mit Blick auf den EAA geschrieben wurde. Sie ist noch nicht die rechtliche Referenz: Die Konformitätsvermutung greift, sobald die Kommission sie im Amtsblatt zitiert. Bis dahin bleiben v3.2.1 und WCAG 2.1 AA der formale Maßstab. Ich würde trotzdem auf WCAG 2.2 AA bauen, weil die neuen Kriterien genau das treffen, was B2B-Shops tun:

• 2.4.11 Focus Not Obscured (Minimum), AA: Sticky-Header, Cookie-Banner und Mini-Warenkörbe dürfen das fokussierte Element nicht verdecken.
• 2.5.7 Dragging Movements, AA: Slider und sortierbare Listen brauchen eine Alternative mit einem einzelnen Zeiger.
• 2.5.8 Target Size (Minimum), AA: dichte Mengenfelder, Tabellen-Icons und Filter-Chips brauchen ausreichend große Ziele.
• 3.3.7 Redundant Entry, A: Nutzer müssen Daten, die sie im selben Checkout schon eingegeben haben, etwa die Rechnungsadresse, nicht erneut tippen.
• 3.3.8 Accessible Authentication (Minimum), AA: kein kognitiver Test im Login ohne Alternative, und Passwortmanager müssen funktionieren.
• 3.2.6 Consistent Help, A: Hilfe und Kontakt bleiben auf allen Seiten an derselben Stelle.

Neben dem Markup gibt es Informationspflichten. Anbieter müssen die Informationen nach Anlage 3 des BFSG erstellen und in barrierefreier Form veröffentlichen, in der Praxis eine Barrierefreiheitserklärung, die den Dienst, die angewandte Norm, bekannte Lücken, einen Meldeweg für Barrieren und die zuständige Behörde beschreibt. Onlineshops müssen außerdem Informationen zur Barrierefreiheit der verkauften Produkte weitergeben, soweit der verantwortliche Wirtschaftsakteur sie liefert. Denk daran, dass die Erklärung eine gesetzliche Pflicht ist, deren Verletzung selbst bebußt werden kann.

Was in Spryker-, Pimcore- und TYPO3-Shops typischerweise scheitert

Zuerst ein Vorbehalt: Ich habe keine Herstellerzusage gefunden, dass eine dieser Plattformen einen konformen Storefront ausliefert, und würde auch keine erwarten. Die folgenden Fehler sind typische Storefront-Muster, abgeglichen mit den allgemeinen Checklisten in den Quellen, nicht aus einem Hersteller-Audit. Sie sitzen im Storefront-Code, den du geschrieben oder gekauft hast, deshalb sehen sie über alle Stacks hinweg gleich aus.

Spryker

Storefront-Templates sind Projektcode auf der Yves-Schicht, mit vielen eigenen Komponenten für Produktlisten, konfigurierbare Bundles und Schnellbestellung. Nach meiner Erfahrung liegt das Problem nicht im Framework, sondern in den Dutzenden maßgeschneiderten Molekülen: hier ein eigenes Dropdown, dort ein AJAX-Warenkorb. Ich würde mit einem Inventar aller interaktiven Komponenten beginnen und für jede entscheiden, ob ein natives Element sie ersetzen kann.

Pimcore

Pimcore-Shops sind meist entweder Twig auf Symfony oder ein Headless-Setup mit separatem Frontend, die Barrierefreiheit hängt also vom Frontend-Team ab. Das zusätzliche Risiko ist datengetriebenes Rendering: Attribute, Bilder und Dokumente, die aus Produktdaten kommen. Wenn Alt-Text, PDF und Überschriftenstruktur keine Datenqualitätsregeln sind, kann kein Template sie reparieren.

TYPO3

TYPO3 rendert über Fluid, semantische Ausgabe ist also erreichbar, aber die Schwachstellen sind redaktionelle Inhalte und Shop-Extensions: fehlende Alt-Texte, Überschriftenebenen nach Optik gewählt und Extension-Templates mit eigenem Markup und eigenen Formularen. Ich würde Redaktionsregeln und ein Template-Review jeder Shop-Extension einplanen.

Wenn du agentenfähige Funktionen auf demselben Markup baust, zahlt sich Barrierefreiheit doppelt aus: Semantisches HTML und klare Labels helfen Screenreadern und auch Agenten, wie ich in Agentic-Commerce-Protokolle und im WebMCP-Leitfaden beschreibe.

Testen: axe plus echte Nutzer

Deques Studie mit mehr als 2.000 Audits und 13.000 Seiten ergab, dass automatisches Testen mit axe 57 Prozent der Probleme mengenmäßig abdeckt, weit über der alten Faustregel von 20 bis 30 Prozent. Das ist eine nützliche Zahl, aber es ist der Anteil gefundener Probleme, nicht der Anteil der Kriterien und keine Konformität. Ein Kommentator der MLBF-Strategie macht den verwandten Punkt, dass automatische Prüfungen typischerweise nur 30 bis 40 Prozent der geforderten Schritte abdecken und ein bestandener Scan kein Freifahrtschein ist. Behörden nutzen Scanner, du musst sie also bestehen, und Nutzer finden den Rest.

1. Lass axe-core in der CI auf den Schlüssel-Templates laufen: Startseite, Kategorie mit Filtern, Produkt mit Konfigurator, Warenkorb, jeder Checkout-Schritt, Login, Schnellbestellung. Lass den Build bei neuen Verstößen fehlschlagen.
2. Teste nur mit der Tastatur. Jedes Element erreichbar, sichtbarer Fokus, logische Reihenfolge, keine Fallen und nichts hinter Sticky-UI verborgen.
3. Teste mit einem Screenreader auf einer echten Journey: NVDA mit Firefox oder Chrome unter Windows, VoiceOver mit Safari auf macOS und iOS. Suchen, filtern, konfigurieren, bestellen.
4. Zoome auf 200 und 400 Prozent und nutze einen schmalen Viewport. Prüfe Reflow, Zielgröße und dass nichts abgeschnitten wird.
5. Teste die Fehlerpfade: leere Formulare abschicken, eine ungültige UID eingeben, einen Artikel entfernen. Fehler müssen angekündigt werden, und der Fokus muss sinnvoll wandern.
6. Prüfe die Dokumente: Kontrolliere die Tags der PDF-Datenblätter, Rechnungen und Bestellbestätigungen, die der Shop erzeugt.
7. Halte die Ergebnisse pro Journey fest, mit Schweregrad und Verantwortlichem, denn das ist die Grundlage für die Barrierefreiheitserklärung.

Ich behandle die Checkliste als Regressionssuite: axe in der Pipeline, ein kurzes manuelles Skript pro Release, ein tieferes Audit vor großen Änderungen. Das passt zu dem Muster, das ich bei LLM-Evals nutze: automatisiere, was billig ist, und lass Menschen beurteilen, was nur Menschen beurteilen können.

Ein Fahrplan, der zu einem B2B-Team passt

Starte nicht mit einem Seite-für-Seite-Audit von 40.000 Produktseiten. Starte mit den Journeys, denn Templates vervielfachen sich. In dieser Reihenfolge würde ich vorgehen:

1. Anwendungsbereich klären. Kläre mit der Rechtsabteilung, ob du reines B2B, Hybrid oder ausgenommen bist, und halte die Belege fest. Wenn du dich auf reines B2B stützt, härte Registrierung und AGB.
2. Templates und Komponenten inventarisieren. Liste alle Seiten-Templates, interaktiven Komponenten, Extensions und erzeugten Dokumente auf. Gruppiere sie nach Journey: finden, konfigurieren, bestellen, Konto.
3. Basislinie messen. axe über die Templates plus ein manueller Durchlauf der drei wichtigsten Journeys. Priorisiere nach blockierender Wirkung: Ein Kunde, der den Checkout nicht abschließen kann, kommt zuerst.
4. Gemeinsame Komponenten zuerst beheben. Buttons, Formularfelder, Dialoge, Menüs, Tabellen. Eine Korrektur landet dann auf jeder Seite, und du solltest für jede einen Komponententest mit axe ergänzen.
5. Konfigurator, Filter und Checkout beheben. Ersetze eigene Widgets wo möglich durch native Elemente, ergänze Live-Regionen und behebe Fehler und Fokus.
6. Inhalte und Dokumente beheben. Alt-Text-Regeln im PIM oder CMS, Überschriftenregeln für Redakteure, getaggte PDFs aus dem erzeugenden System oder eine HTML-Alternative.
7. Barrierefreiheitserklärung und Feedback-Kanal veröffentlichen. Nenne bekannte Lücken ehrlich, gib einen Kontakt für Barrierenmeldungen an und benenne die zuständige Behörde.
8. Rückfälle verhindern. CI-Gates, ein manuelles Skript in der Release-Checkliste und ein Verantwortlicher für Barrierefreiheit pro Team. Teste erneut, wenn EN 301 549 v4.1.1 zur zitierten Referenz wird.

Plane ehrlich: Konfiguratoren und Checkouts sind oft kleine Teile des Codes, aber große Teile des Risikos, und der Neubau eines eigenen Widgets auf nativer Basis kann günstiger sein als es zu flicken. Verglichen mit dem Umbau aller Templates unter Zeitdruck nach einer Beschwerde ist die frühe Korrektur auch die günstigere.

Meine Einschätzung

Auch wenn du sicher bist, dass dein B2B-Shop nicht erfasst ist, würde ich die Arbeit an den Kern-Journeys trotzdem machen. Die Kosten sind gering, wenn sie Teil der normalen Frontend-Entwicklung ist, das Ergebnis ist bessere Tastatur- und Mobilbedienung für jeden Käufer, auch für Kolleginnen und Kollegen, die assistive Technik nutzen, und eine saubere Barrierefreiheits-Position erleichtert Fragebögen großer Kunden. Der letzte Punkt ist meine Beobachtung, keine rechtliche Pflicht.

Bei der Frage des Anwendungsbereichs würde ich eine Stunde mit einem Juristen verbringen, bei der Frage des Standards einen Sprint mit dem Team. Wenn du Hilfe bei der Aufwandsschätzung eines Audits für einen Spryker-, Pimcore- oder TYPO3-Shop willst, sieh dir meine Seite B2B-E-Commerce-Expertise an, und für das größere regulatorische Bild lies die Checkliste zu EU AI Act Artikel 50.

Quellen

1. BFSG section 1: purpose and scope (gesetze-im-internet.de)
2. BFSG section 2: definitions, consumer, microenterprise, e-commerce services
3. BFSG section 3: accessibility and the microenterprise exemption
4. BFSG section 14: duties of the service provider
5. BFSG section 32: rights of consumers and associations in the administrative procedure
6. BFSG section 37: fines
7. BFSG section 38: transitional provisions
8. Bundesfachstelle Barrierefreiheit: FAQ on the BFSG (B2B, microenterprises, EN 301 549)
9. AccessibleEU: The European accessibility standard EN 301 549 has been updated (7 September 2026)
10. W3C: Web Content Accessibility Guidelines (WCAG) 2.2
11. Deque: Automated testing identifies 57 percent of digital accessibility issues
12. sitebrunch: What is the market surveillance authority for accessibility (MLBF)?
13. Marcus Herrmann: June 2026, how the MLBF intends to check
14. axes4: BFSG in practice, what has happened since the deadline (2026)
15. ODC Legal: BFSG for websites, what companies must check in 2026
16. WKO: Information on the Austrian Barrierefreiheitsgesetz
17. Web Crossing: One year of the Barrierefreiheitsgesetz, where online shops must improve