Das Barrierefreiheitsstärkungsgesetz (BFSG) ist seit Juni 2025 verbindlich für private Online-Shops in Deutschland. Für WEBSALE-Betreiber stellt sich eine konkrete Frage: Wo in der Architektur löst ihr Barrierefreiheit am effizientesten, und wie vermeidet ihr dauerhaftes Audit-Risiko?

Die kurze Antwort: am Frontend-Layer, nicht im Backend.

Was das BFSG für euren WEBSALE-Shop bedeutet

Das BFSG setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Seit dem 28. Juni 2025 müssen Online-Shops, die Produkte oder Dienstleistungen an Endverbraucher verkaufen, die Anforderungen der EN 301 549 erfüllen. Diese Norm referenziert WCAG 2.1 auf Level AA als Mindeststandard - WCAG 3.0 ist der zukunftssichere Folgestandard, auf den ihr bereits jetzt hinarbeiten solltet.

Konkret betrifft das euren WEBSALE-Shop in folgenden Bereichen:

• Tastaturnavigation durch alle Interaktionspunkte (Produkt-Listing, Warenkorb, Checkout)
• Kontrastverhältnis von mindestens 4,5:1 für normalen Text, 3:1 für große Überschriften
• Alternativtexte für alle funktionalen Bilder
• Fehleridentifikation und -beschreibung in Formularen (z. B. Checkout-Formular)
• Screenreader-kompatible Seitenstruktur (ARIA-Landmarks, korrekte Heading-Hierarchie)

Wer diese Anforderungen nicht erfüllt, riskiert Abmahnungen durch Verbraucherverbände und behördliche Verfahren durch den Marktüberwachungsbehörden der Länder.

Warum Barrierefreiheit eine Frontend-Aufgabe ist

WEBSALE liefert als SaaS-Shopsystem das Backend: Produktdaten, Bestelllogik, Kundenverwaltung, Zahlungsabwicklung. Die Storefront-API stellt diese Daten maschinenlesbar bereit. Was der Browser rendert, entscheidet ausschließlich der Frontend-Layer.

Das bedeutet: Ob ein Screenreader eine Produktliste korrekt traversieren kann, ob ein Keyboard-Nutzer den Checkout abschließen kann, ob Farbkontraste den WCAG-Schwellwert erfüllen - all das liegt in euren Frontend-Komponenten, nicht im WEBSALE-Backend.

Daraus folgt ein klarer Scope für eure BFSG-Umsetzung:

Backend (WEBSALE): Keine Änderungen erforderlich für BFSG. Die Storefront-API liefert semantisch strukturierte Daten.

Frontend-Layer: Vollständige BFSG-Verantwortung. HTML-Semantik, ARIA-Attribute, Fokus-Management, Kontraste, Formular-Accessibility.

Wer den Frontend-Layer mit einem eigenen Custom-Build betreibt, trägt die gesamte Audit-Last selbst: regelmäßige WCAG-Checks, manuelle Fixes pro Komponente, Regression-Tests bei jedem Release. Das ist ein kontinuierlicher Aufwand, kein einmaliges Projekt.

Wie Laioutr BFSG und WCAG 3.0 im Standard liefert

Laioutr setzt als Frontend Management Platform (FMP) auf die WEBSALE Storefront-API auf. Die 70+ Komponenten in der Laioutr-UI-Bibliothek sind ab Werk WCAG-3.0-konform entwickelt:

Tastaturnavigation: Alle interaktiven Komponenten (Produktkarten, Filterleisten, Warenkorb, Checkout-Steps) sind vollständig per Tastatur bedienbar. Fokus-Management bei modalen Dialogen ist standardmäßig implementiert.

Screenreader-Kompatibilität: ARIA-Landmarks, ARIA-Labels und korrekte Heading-Hierarchien sind Bestandteil jeder Komponente. Dynamische Zustandsänderungen (z. B. Warenkorb-Update) kommunizieren über ARIA-Live-Regions.

Kontrast: Alle Standardfarben erfüllen WCAG AA. Das Laioutr-Theme-System blockiert Farbkombinationen, die unterhalb des Schwellwerts liegen - sowohl im Editor als auch in der Vorschau.

Formular-Accessibility: Checkout-Formulare haben korrekte Label-Verknüpfungen, Fehleridentifikation auf Feldebene und autofill-kompatible Attribute.

Lighthouse-Score: Laioutr-Storefronts erreichen Lighthouse 100 im Accessibility-Bereich out-of-the-box - ohne A11y-Nachrüstsprints.

Das bedeutet für euch als WEBSALE-Betreiber: Ihr übernehmt eine Frontend-Schicht, die BFSG-ready ist, bevor ihr die erste Produktseite anpasst.

Was Shop-Betreiber bei einem eigenen Frontend selbst leisten müssen

Zum Vergleich: Wenn ihr den WEBSALE-Custom-Frontend-Build oder ein bestehendes Template-System nutzt und BFSG eigenhändig umsetzen wollt, sind das typischerweise folgende Aufgaben:

Erstaudit: Vollständige WCAG-2.1-AA-Prüfung aller Seiten-Templates (Homepage, PLP, PDP, Warenkorb, Checkout, Account). Tooling: axe DevTools, WAVE, manuelle Screenreader-Tests (NVDA/JAWS + VoiceOver). Aufwand: 3-5 Werktage für mittelgroße Shops.

Remediation: Für jeden gefundenen Fehler Priorität bestimmen, Fix implementieren, Regression testen. Durchschnittliche Fixquote bei erstmaligen Audits: 40-80 Fehler pro Seite bei ungetesteten Templates.

Dokumentation: BFSG verlangt eine Erklärung zur Barrierefreiheit (Accessibility Statement) auf eurer Website mit Kontaktweg für Feedback und Datum der letzten Prüfung.

Laufende Pflege: Bei jedem Frontend-Release müssen neue Komponenten geprüft werden. CI/CD-Integration von A11y-Linting ist empfehlenswert, ersetzt aber keine manuelle Prüfung.

Release-Regression: Jede neue Kampagnen-Seite, jede neue Produktkategorie muss gegen WCAG getestet werden. Bei Custom-Build ist das Entwickler-Aufwand pro Feature.

Mit Laioutr entfallt dieser Aufwand im Kern: Die Komponenten sind bereits konform. Ihr konfiguriert - ihr audiert nicht die Grundlage.

EN 301 549 und der Weg zu WCAG 3.0

WCAG 3.0 ist aktuell (Stand 2026) noch kein formaler ISO/EN-Standard, aber das W3C-Working-Draft ist inhaltlich weitgehend stabil. EN 301 549 wird bei seiner nächsten Revision voraussichtlich auf WCAG 3.0 hochziehen.

Laioutr-Komponenten sind bereits auf die WCAG-3.0-Draft-Kriterien entwickelt, insbesondere auf das neue Kontrast-Modell (APCA statt WCAG-2.x-Luma-Methode) und die erweiterten Anforderungen für Fokus-Sichtbarkeit (Focus Appearance).

Wer heute mit Laioutr auf WEBSALE baut, ist für die kommende EN-Revision vorbereitet - ohne erneutes Retrofit.

Mehrsprachigkeit und Multi-Storefront: Accessibility skaliert mit

WEBSALE unterstützt B2B- und B2C-Modelle auf einem Backend, inklusive Kundengruppen-Hierarchien und Marktplatz-Szenarien. Laioutr löst die Multi-Storefront-Anforderung: Mehrere Storefronts, mehrere Marken, mehrere Märkte - alle aus einem Komponenten-Pool.

Das ist für BFSG relevant: Ihr pflegt Accessibility-Standards einmal in der gemeinsamen Komponentenbibliothek. Bugfix oder Verbesserung an einer A11y-Eigenschaft - einmal deployt, sofort in allen Storefronts aktiv.

Gegenteil: Eigene Frontend-Codebasen pro Marke multiplizieren den Audit-Aufwand.

Fazit: BFSG ist eine Frontend-Entscheidung

Das BFSG ist keine Backend-Frage. Eure WEBSALE-Installation ist API-first und liefert strukturierte Daten - die BFSG-Verantwortung liegt vollständig im Frontend-Layer, den ihr kontrolliert.

Die Entscheidung, welchen Frontend-Layer ihr nutzt, ist die entscheidende BFSG-Entscheidung: entweder kontinuierliche Audit-Arbeit mit eigenem Build, oder eine Plattform, die WCAG 3.0 im Standard mitbringt.

Laioutr baut auf der WEBSALE Storefront-API auf und liefert WCAG-konforme Komponenten ab Werk. Für WEBSALE-Betreiber, die BFSG ohne dauerhaften Audit-Overhead lösen wollen, ist das der direkteste Weg.

Mehr zur WebSale-Integration erfahren oder Preise ansehen. Fragen zur konkreten BFSG-Umsetzung? Sprecht uns an.

---

FAQ: BFSG und WCAG für WEBSALE-Shops

Gilt das BFSG für meinen WEBSALE-Shop?

Wenn ihr Produkte oder Dienstleistungen online an Endverbraucher verkauft und euer Jahresumsatz über dem Kleinstunternehmen-Schwellwert liegt (10 Mitarbeiter oder 2 Mio. EUR Jahresumsatz), gilt das BFSG seit dem 28. Juni 2025.

Muss WEBSALE selbst etwas ändern?

Nein. Die Barrierefreiheitspflicht liegt im Frontend - in dem, was der Browser rendert. WEBSALE liefert strukturierte Daten über die Storefront-API; die BFSG-Umsetzung ist Aufgabe eures Frontend-Layers.

Reicht WCAG 2.1 AA oder muss es WCAG 3.0 sein?

Das BFSG verlangt aktuell EN 301 549, die WCAG 2.1 AA referenziert. WCAG 3.0 ist noch kein rechtlich verbindlicher Standard, aber die Richtung ist klar. Wer heute auf WCAG 3.0 entwickelt, ist für die nächste EN-Revision vorbereitet.

Was kostet eine BFSG-Nachrüstung bei eigenem Frontend?

Je nach Ausgangszustand eures Templates 3-6 Wochen Entwicklungsaufwand für das Erstaudit und die Remediation, plus laufender Pflegeaufwand pro Release. Exact costs vary by codebase size.

Wie testet Laioutr Accessibility?

Alle Laioutr-Komponenten werden mit automatisierten A11y-Tests (axe-core) und manuellen Screenreader-Tests geprüft. Der Lighthouse-Accessibility-Score ist fester Bestandteil jedes Release-Gates.

Kann ich Laioutr auf meinem bestehenden WEBSALE-Backend aufsetzen, ohne das Backend zu ändern?

Ja. Laioutr verbindet sich mit der WEBSALE Storefront-API. Keine Backend-Migration, kein WEBSALE-Versionsupgrade erforderlich.