Germany's Barrierefreiheitsstarkungsgesetz (BFSG) has been mandatory for private online shops since June 2025. For WEBSALE operators, one question matters most: where in the architecture do you solve accessibility most efficiently, and how do you avoid ongoing audit exposure?

The short answer: at the frontend layer, not the backend.

What the BFSG Means for Your WEBSALE Shop

The BFSG implements EU Directive 2019/882 (the European Accessibility Act) into German law. Since June 28, 2025, online shops selling products or services to end consumers must comply with EN 301 549 requirements. This standard references WCAG 2.1 Level AA as a baseline - WCAG 3.0 is the future-proof successor standard you should already be building toward.

In practice, your WEBSALE shop is affected in these areas:

• Keyboard navigation through all interaction points (product listings, cart, checkout)
• Contrast ratio of at least 4.5:1 for normal text, 3:1 for large headings
• Alternative text for all functional images
• Error identification and description in forms (e.g., checkout)
• Screen reader-compatible page structure (ARIA landmarks, correct heading hierarchy)

Shops that don't meet these requirements risk warnings from consumer associations and regulatory proceedings from state market surveillance authorities.

Why Accessibility is a Frontend Problem

WEBSALE delivers the backend as a SaaS commerce system: product data, order logic, customer management, payment processing. The Storefront API makes this data available in a machine-readable format. What the browser renders is entirely determined by the frontend layer.

That means: whether a screen reader can correctly traverse a product listing, whether a keyboard user can complete checkout, whether color contrasts meet WCAG thresholds - all of this lives in your frontend components, not in the WEBSALE backend.

This gives you a clear scope for BFSG compliance:

Backend (WEBSALE): No changes required for BFSG. The Storefront API delivers semantically structured data.

Frontend layer: Full BFSG responsibility. HTML semantics, ARIA attributes, focus management, contrast ratios, form accessibility.

If you run a custom frontend build, you carry the entire audit burden yourself: regular WCAG checks, manual fixes per component, regression testing on every release. That is ongoing effort, not a one-time project.

How Laioutr Delivers BFSG and WCAG 3.0 as Standard

Laioutr sits on top of the WEBSALE Storefront API as a Frontend Management Platform (FMP). The 70+ components in the Laioutr UI library are built WCAG-3.0-compliant out of the box:

Keyboard navigation: All interactive components (product cards, filter panels, cart, checkout steps) are fully operable by keyboard. Focus management within modal dialogs is implemented as standard.

Screen reader compatibility: ARIA landmarks, ARIA labels, and correct heading hierarchies are part of every component. Dynamic state changes (e.g., cart updates) communicate via ARIA live regions.

Contrast: All default colors meet WCAG AA. The Laioutr theme system blocks color combinations that fall below the threshold - both in the editor and in preview.

Form accessibility: Checkout forms have correct label associations, field-level error identification, and autocomplete-compatible attributes.

Lighthouse score: Laioutr storefronts reach Lighthouse 100 in the Accessibility category out of the box - no remediation sprints required.

For you as a WEBSALE operator, this means: you inherit a frontend layer that is BFSG-ready before you customize a single product page.

What Operators with Custom Frontend Builds Must Handle Themselves

For comparison: if you run a custom WEBSALE frontend build or an existing template system and want to implement BFSG yourself, these are the typical tasks:

Initial audit: Full WCAG 2.1 AA review of all page templates (homepage, PLP, PDP, cart, checkout, account). Tooling: axe DevTools, WAVE, manual screen reader tests (NVDA/JAWS + VoiceOver). Effort: 3-5 working days for mid-size shops.

Remediation: For each identified issue, determine priority, implement fix, run regression tests. Average issue count in first audits of untested templates: 40-80 per page.

Documentation: The BFSG requires an Accessibility Statement on your website, including a feedback contact and the date of last review.

Ongoing maintenance: Every frontend release must check new components for compliance. CI/CD integration of A11y linting helps but does not replace manual testing.

Release regression: Every new campaign page, every new product category must be tested against WCAG. With a custom build, that is developer effort per feature.

With Laioutr, this core burden disappears: the components are already compliant. You configure - you don't audit the foundation.

EN 301 549 and the Path to WCAG 3.0

WCAG 3.0 is not yet a formal ISO/EN standard as of 2026, but the W3C Working Draft is largely stable in content. EN 301 549 is expected to reference WCAG 3.0 in its next revision.

Laioutr components are already built to WCAG 3.0 draft criteria, particularly the new contrast model (APCA instead of WCAG 2.x luma method) and the expanded requirements for focus visibility (Focus Appearance).

Building on WEBSALE with Laioutr today means you are prepared for the next EN revision - without a new retrofit project.

Multi-Storefront Scaling: Accessibility Follows

WEBSALE supports B2B and B2C models on a single backend, including customer group hierarchies and multi-market scenarios. Laioutr solves the multi-storefront requirement: multiple storefronts, multiple brands, multiple markets - all from one shared component pool.

This matters for BFSG: you maintain accessibility standards once in the shared component library. An A11y fix or improvement deployed once is immediately active across all storefronts.

The alternative: separate frontend codebases per brand multiply audit effort proportionally.

The Bottom Line: BFSG is a Frontend Decision

BFSG is not a backend question. Your WEBSALE installation is API-first and delivers structured data - BFSG responsibility sits entirely in the frontend layer you control.

The choice of frontend layer is your decisive BFSG decision: either continuous audit work with a custom build, or a platform that brings WCAG 3.0 compliance as standard.

Laioutr builds on the WEBSALE Storefront API and delivers WCAG-compliant components out of the box. For WEBSALE operators who want to solve BFSG without ongoing audit overhead, that is the most direct path.

Learn more about the WEBSALE integration or view pricing. Questions about your specific BFSG implementation? Talk to us.

---

FAQ: BFSG and WCAG for WEBSALE Shops

Does the BFSG apply to my WEBSALE shop?

If you sell products or services online to end consumers and your business exceeds the micro-enterprise threshold (10 employees or 2 million EUR annual revenue), the BFSG applies since June 28, 2025.

Does WEBSALE itself need to change anything?

No. The accessibility obligation sits in the frontend - in what the browser renders. WEBSALE delivers structured data via the Storefront API; BFSG compliance is the responsibility of your frontend layer.

Is WCAG 2.1 AA sufficient or is WCAG 3.0 required?

The BFSG currently requires EN 301 549, which references WCAG 2.1 AA. WCAG 3.0 is not yet legally binding, but the direction is clear. Building to WCAG 3.0 today prepares you for the next EN revision.

What does a BFSG retrofit cost with a custom frontend?

Depending on your template's starting state: 3-6 weeks of development effort for the initial audit and remediation, plus ongoing maintenance per release. Exact costs vary by codebase size.

How does Laioutr test accessibility?

All Laioutr components are tested with automated A11y tests (axe-core) and manual screen reader tests. The Lighthouse Accessibility score is a fixed part of every release gate.

Can I use Laioutr on my existing WEBSALE backend without changing the backend?

Yes. Laioutr connects to the WEBSALE Storefront API. No backend migration, no WEBSALE version upgrade required.