Euer Brand-Magazin aufbauen: Ein Content-Hub auf eurem composable FrontendEin Brand-Magazin, ein red…
commercetools und BFSG/WCAG: Barrierefreiheit im Composable-Stack richtig lösen
commercetools und BFSG/WCAG: Barrierefreiheit im Composable-Stack richtig lösen
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland. Für die meisten B2C-Onlineshops heißt das: Barrierefreiheit ist keine Kür mehr, sondern Pflicht. Wer auf commercetools setzt, stellt sich dann schnell die Frage: Macht das Backend das für mich? Die kurze Antwort ist nein. Barrierefreiheit entsteht dort, wo der Nutzer tatsächlich klickt, tippt und liest, und das ist die Storefront, nicht die Commerce-API.
Warum das BFSG die Storefront trifft, nicht das Backend
commercetools ist ein API-first Commerce-Backend. Es liefert Produktdaten, Preise, Warenkorb- und Checkout-Logik über GraphQL und REST. Was es bewusst nicht vorgibt, ist das Frontend, also genau die Schicht, die WCAG-Kriterien erfüllen muss: Tastaturbedienbarkeit, Fokus-Reihenfolge, Kontrastwerte, semantische Struktur, Screenreader-Labels, Formular-Fehlermeldungen. Ein composable Setup entkoppelt Backend und Frontend absichtlich, und das ist eine Stärke. Aber es bedeutet auch: Die Verantwortung für Barrierefreiheit liegt vollständig in Ihrer Frontend-Schicht. Die WCAG-2.1-AA-Kriterien, auf die das BFSG in der Praxis abzielt, werden nicht in der commercetools-API erfüllt, sondern im gerenderten Markup, das Ihr Storefront ausliefert.
Das Problem beim „nachträglichen" Barrierefrei-Machen
Viele Teams behandeln Accessibility als Sprint am Quartalsende: ein Audit, eine Liste mit Findings, ein paar Wochen Nachrüsten. Das Problem ist, dass Barrierefreiheit eine Eigenschaft jeder einzelnen Komponente ist, nicht ein Feature, das man einmal einbaut. Ein Fokus-Ring, der beim nächsten Redesign wieder verschwindet. Ein Karussell, das mit der Tastatur nicht bedienbar ist. Ein Custom-Dropdown ohne ARIA-Rollen. Wenn diese Dinge komponentenweise entstehen und komponentenweise wieder kaputtgehen, wird jeder Relaunch zum erneuten Accessibility-Risiko. Bei einem composable Stack mit vielen einzelnen UI-Bausteinen multipliziert sich dieses Risiko.
Barrierefreiheit als Plattform-Eigenschaft, nicht als Sprint
Der belastbarere Weg ist, Barrierefreiheit in die Komponenten-Basis einzubauen, sodass jeder Baustein von Anfang an konform ist und es auch nach dem nächsten Redesign bleibt. Genau hier setzt der backend-agnostische Frontend-Ansatz an, den wir bei Laioutr verfolgen: commercetools bleibt Ihr Backend, aber die Frontend-Schicht liefert WCAG-3.0-Ready-Komponenten ab Werk. Standard-Bausteine, Formulare, Navigation und interaktive Elemente erfüllen die Kriterien, ohne dass Ihr Team pro Sprint gegen Regressionen ankämpfen muss. Das ist der Unterschied zwischen „wir haben ein Accessibility-Ticket" und „unsere Storefront ist strukturell barrierefrei".
Was das für commercetools-Teams konkret heißt
| Aspekt | Backend (commercetools) | Frontend-Schicht (BFSG-relevant) |
|---|---|---|
| Zuständigkeit | Produktdaten, Preise, Checkout-Logik | Rendering, Semantik, Tastatur, Kontrast |
| WCAG-Kriterien | nicht adressiert | vollständig hier zu erfüllen |
| Regressions-Risiko | gering | hoch bei komponentenweisem Aufbau |
| Lösung | API bleibt unverändert | WCAG-konforme Komponenten ab Werk |
Praktisch heißt das: Sie müssen Ihr commercetools-Backend für das BFSG nicht anfassen. Der Hebel liegt darin, die Frontend-Schicht so zu wählen, dass Accessibility eingebaut statt nachgerüstet ist. Wenn Sie ohnehin vor einer Frontend-Entscheidung stehen, ist das BFSG ein weiterer Grund, die Storefront-Schicht bewusst und unabhängig vom Backend zu wählen. Wie modular commercetools inzwischen selbst wird, haben wir in unserem Beitrag zu commercetools und den neuen Standalone-Modulen beschrieben, dieselbe Entkopplungs-Logik gilt für Barrierefreiheit.
FAQ
Macht commercetools mein Shop automatisch barrierefrei? Nein. commercetools ist ein Commerce-Backend und liefert keine Storefront-UI. Alle WCAG-relevanten Kriterien werden in der Frontend-Schicht erfüllt, die das Markup rendert.
Reicht ein einmaliges Accessibility-Audit für das BFSG? Ein Audit zeigt den Ist-Zustand, hält aber nicht. Barrierefreiheit ist eine Eigenschaft jeder Komponente und kann bei jedem Redesign erneut brechen. Nachhaltiger ist eine Komponenten-Basis, die konform ausgeliefert wird.
Muss ich mein commercetools-Backend für das BFSG umbauen? Nein. Der relevante Hebel ist die Frontend-Schicht. Das Backend bleibt unverändert.
Nächste Schritte
Wenn Ihre commercetools-Storefront BFSG-konform werden soll, lohnt sich der Blick auf eine Frontend-Schicht mit Accessibility ab Werk. Sehen Sie sich die WCAG-Ready-Basis an oder buchen Sie ein Gespräch, in dem wir Ihre aktuelle commercetools-Frontend-Situation im Detail durchgehen.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Mitgründer von Laioutr. Er arbeitet mit commercetools-Teams im DACH-Raum, die ihre Storefront BFSG-konform und unabhängig vom Backend aufstellen wollen.
Alle Angaben beruhen auf öffentlich verfügbaren Informationen und eigener Plattform-Erfahrung. Stand Juli 2026. Das BFSG und die WCAG-Kriterien sowie commercetools-Funktionen können sich seither weiterentwickelt haben. Dieser Beitrag ist keine Rechtsberatung.