Building a Brand Magazine: A Content Hub on Your Composable FrontendA brand magazine, an editorial c…
commercetools and BFSG/WCAG: Getting Accessibility Right in a Composable Stack
commercetools and BFSG/WCAG: Getting Accessibility Right in a Composable Stack
Since June 28, 2025, the German Accessibility Strengthening Act (BFSG) has been in force. For most B2C online shops, that means accessibility is no longer optional, it's mandatory. If you run on commercetools, the first question is usually: does the backend handle this for me? The short answer is no. Accessibility happens where the user actually clicks, types, and reads, and that's the storefront, not the commerce API.
Why the BFSG hits the storefront, not the backend
commercetools is an API-first commerce backend. It serves product data, prices, cart, and checkout logic over GraphQL and REST. What it deliberately does not prescribe is the frontend, which is exactly the layer that has to satisfy WCAG criteria: keyboard operability, focus order, contrast ratios, semantic structure, screen-reader labels, form error messages. A composable setup decouples backend and frontend on purpose, and that's a strength. But it also means the responsibility for accessibility sits entirely in your frontend layer. The WCAG 2.1 AA criteria the BFSG effectively targets aren't met inside the commercetools API, they're met in the rendered markup your storefront ships.
The problem with bolting accessibility on afterwards
Many teams treat accessibility as an end-of-quarter sprint: an audit, a list of findings, a few weeks of retrofitting. The problem is that accessibility is a property of every single component, not a feature you add once. A focus ring that disappears again at the next redesign. A carousel that can't be operated by keyboard. A custom dropdown with no ARIA roles. When these things get built component by component and break component by component, every relaunch becomes a fresh accessibility risk. In a composable stack with many individual UI building blocks, that risk multiplies.
Accessibility as a platform property, not a sprint
The more durable approach is to build accessibility into the component base, so every building block is compliant from the start and stays that way after the next redesign. That's exactly where the backend-agnostic frontend approach we take at Laioutr comes in: commercetools stays your backend, but the frontend layer ships WCAG-3.0-ready components out of the box. Standard building blocks, forms, navigation, and interactive elements meet the criteria without your team fighting regressions every sprint. That's the difference between "we have an accessibility ticket" and "our storefront is structurally accessible."
What this means concretely for commercetools teams
| Aspect | Backend (commercetools) | Frontend layer (BFSG-relevant) |
|---|---|---|
| Responsibility | Product data, prices, checkout logic | Rendering, semantics, keyboard, contrast |
| WCAG criteria | not addressed | fully met here |
| Regression risk | low | high with component-by-component builds |
| Solution | API stays unchanged | WCAG-ready components out of the box |
In practice: you don't have to touch your commercetools backend for the BFSG. The lever is choosing a frontend layer where accessibility is built in rather than retrofitted. If you're facing a frontend decision anyway, the BFSG is one more reason to choose the storefront layer deliberately and independently of the backend. We covered just how modular commercetools itself is becoming in our piece on commercetools and the new standalone modules, and the same decoupling logic applies to accessibility.
FAQ
Does commercetools make my shop accessible automatically? No. commercetools is a commerce backend and ships no storefront UI. All WCAG-relevant criteria are met in the frontend layer that renders the markup.
Is a one-off accessibility audit enough for the BFSG? An audit shows the current state but doesn't hold. Accessibility is a property of every component and can break again at any redesign. A component base that ships compliant is more sustainable.
Do I have to rebuild my commercetools backend for the BFSG? No. The relevant lever is the frontend layer. The backend stays unchanged.
Next steps
If your commercetools storefront needs to become BFSG-compliant, it's worth looking at a frontend layer with accessibility out of the box. See the WCAG-ready base, or book a call where we walk through your current commercetools frontend situation in detail.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr. He works with commercetools teams in the DACH region making their storefront BFSG-compliant and independent of the backend.
All data is based on publicly available information and our own platform experience. As of July 2026. The BFSG, WCAG criteria, and commercetools features may have evolved since. This article is not legal advice.