Einen Produktkonfigurator in eine Magento-Storefront einbauen, ohne das Frontend aufzublähenEinen Pr…
Magento 2 und BFSG: Barrierefreiheit ohne Theme-Audit-Sprint lösen
Magento 2 und BFSG: Barrierefreiheit ohne Theme-Audit-Sprint lösen
Seit dem 28.06.2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für digitale Produkte und Dienstleistungen, die an Verbraucherinnen und Verbraucher gerichtet sind, das schließt B2C-E-Commerce ausdrücklich mit ein. Wer einen Magento-2-Shop betreibt, merkt dabei schnell: Das Problem sitzt nicht in der Business-Logik, sondern im Theme. Markup-Struktur, Fokus-Reihenfolge, Kontrastwerte und Formular-Labels entscheiden darüber, ob ein Shop barrierefrei ist, und genau diese Ebene liegt in Magento tief im Theme-Layer verankert. Der naheliegende Reflex ist ein Theme-Audit-Sprint. Der ist aber selten die strukturell richtige Antwort.
Was das BFSG von einem Magento-Shop konkret verlangt
Das BFSG selbst definiert keine eigene technische Norm, es verweist auf harmonisierte Standards. Für Webshops ist das in der Praxis WCAG 2.1 auf Konformitätsstufe AA, wie sie auch in der europäischen Norm EN 301 549 referenziert wird. Das betrifft unter anderem Farbkontraste, Tastatur-Navigation ohne Maus, korrekte Formular-Labels bei Checkout und Registrierung, Alternativtexte für Produktbilder und eine logische Fokus-Reihenfolge durch die Seite. Ausgenommen sind Kleinstunternehmen unter bestimmten Schwellenwerten, die meisten Magento-Betreiber mit relevantem Umsatz fallen aber in den Geltungsbereich.
Warum das Problem im Theme sitzt, nicht im Backend
Magentos Katalog-, Preis- und Order-Logik ist von den BFSG-Anforderungen kaum betroffen, die Business-Ebene war nie das Problem. Betroffen ist die Präsentationsschicht: Luma-Theme-Markup, das historisch gewachsen ist, Custom-Theme-Anpassungen ohne konsequente Semantik, und Third-Party-Extensions, die eigenes Frontend-Markup mitbringen, ohne sich um Accessibility zu kümmern. Genau diese Kombination macht Magento-Themes zu einem besonders schwer zu prüfenden Feld: Jede Extension kann neue Verstöße einführen, ohne dass das Kern-Theme sich geändert hat.
Warum ein Theme-Audit-Sprint der teure Weg ist
Ein klassischer Theme-Audit-Sprint läuft so ab: externe Prüfung des bestehenden Themes, Liste von Findings, anschließend Custom-Fixes im Theme-Code, danach Re-Test. Das Problem ist struktureller Natur, nicht organisatorischer: Jeder Fix landet wieder im selben Theme-Layer, der die Verstöße ursprünglich verursacht hat. Kommt eine neue Extension dazu oder ändert sich ein Template, ist der nächste Audit fällig. Der Sprint behebt den aktuellen Zustand, nicht die Ursache, dass Accessibility hier eine reine Theme-Verantwortung ist, verteilt über Dutzende Templates, ohne zentrale Kontrollebene. Das macht jeden Re-Audit wieder teuer, unabhängig davon, wie gründlich der vorherige war.
Was ein entkoppelter Frontend-Layer strukturell anders macht
Ein von Magento entkoppelter Frontend-Layer verschiebt Accessibility von einer verteilten Theme-Verantwortung in eine zentrale Komponenten-Verantwortung. Barrierefreie Komponenten wie Formulare, Navigation und Produktkarten werden einmal korrekt gebaut, mit sauberem Markup, korrekter Fokus-Reihenfolge und ARIA-Attributen, und dann konsistent über den gesamten Shop wiederverwendet. Eine neue Kategorie-Seite oder eine neue Kampagnen-Landingpage erbt diese Eigenschaften automatisch, statt dass sie im nächsten Theme-Audit neu geprüft werden muss. Magentos Katalog, Preislogik und Checkout-Backend bleiben dabei unverändert, das Frontend übernimmt lediglich das Rendering, ohne die Business-Logik zu duplizieren. Das ist der Composable-Commerce-Gedanke direkt auf das BFSG angewendet: Verantwortung dort verankern, wo sie strukturell hingehört, statt sie wiederholt im Theme zu reparieren.
Was das für laufende Magento-Shops praktisch bedeutet
Ihr müsst euer Backend dafür nicht wechseln. Der entkoppelte Frontend-Layer setzt auf Magentos APIs auf und übernimmt die Präsentationsschicht, während Magento weiterhin Katalog, Preise und Bestellungen verwaltet. Das reduziert auch die Third-Party-Extension-Problematik: Statt jede Extension einzeln auf Accessibility zu prüfen, wird die Präsentation zentral in wiederverwendbaren Komponenten kontrolliert, unabhängig davon, welche Extension die zugrunde liegenden Daten liefert.
Unsere Einschätzung
Das BFSG ist kein einmaliges Compliance-Projekt, es ist ein dauerhafter Betriebszustand, den jede neue Seite und jede neue Extension aufrechterhalten muss. Ein Theme-Audit-Sprint kann einen Zustand herstellen, an dem gemessen wird, aber er hält diesen Zustand nicht. Wer die Verantwortung stattdessen in einer zentralen Komponenten-Bibliothek verankert, muss nicht bei jeder Theme-Änderung neu prüfen, ob die Barrierefreiheit noch steht. Das ist kein Argument gegen einen initialen Audit, ein sauberer Ausgangsbefund bleibt sinnvoll, es ist ein Argument dafür, wo die dauerhafte Lösung strukturell verankert werden sollte.
Häufige Fragen
Betrifft das BFSG auch B2B-Magento-Shops?
Das BFSG adressiert in erster Linie Angebote an Verbraucherinnen und Verbraucher. Reine B2B-Plattformen ohne Endkunden-Kontakt fallen typischerweise nicht direkt darunter, viele Magento-Betreiber haben aber Mischmodelle mit B2C-Anteil, hier lohnt eine rechtliche Einordnung im Einzelfall.
Reicht ein einmaliger Theme-Fix aus, um dauerhaft konform zu sein?
Nein. Neue Templates, Extensions oder Kampagnen-Seiten können neue Verstöße einführen. Ohne zentrale Komponenten-Kontrolle ist jede Änderung ein neues Risiko.
Muss ich Magento als Backend verlassen, um das zu lösen?
Nein. Ein entkoppelter Frontend-Layer arbeitet über Magentos APIs, Katalog, Preislogik und Checkout-Backend bleiben unverändert in Magento.
Was genau bedeutet WCAG 2.1 AA praktisch für ein Theme?
Unter anderem ausreichende Farbkontraste, vollständige Tastatur-Bedienbarkeit, korrekt verknüpfte Formular-Labels, Alt-Texte für Bilder und eine nachvollziehbare Fokus-Reihenfolge durch die Seite.
Nächste Schritte
Wenn ihr wissen wollt, wie ein entkoppelter Frontend-Layer eure Magento-Accessibility strukturell absichert, buche eine 30-Minuten-Demo und wir zeigen es an eurem bestehenden Theme.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich täglich mit der Frage, wie Commerce-Teams ihre Backend-Investition schützen, während sie das Frontend modernisieren.