Adding a multi-language field to the backend takes an afternoon. The part that takes months sits in …
EAA, BFSG, and WCAG 2.1 AA: How to Build Accessibility Into Your Components, Not Into a One-Time Audit
If you run an online shop or a corporate site in the EU, you have probably already read a version of the accessibility explainer: European Accessibility Act, BFSG, WCAG 2.1 AA, fines, deadlines. That explainer answers what the law requires. It rarely answers the harder operational question: once you have fixed the violations your last audit found, what stops the next release, the next third-party extension, or the next campaign page from reintroducing them? This is a practical answer to that second question, not another summary of the first. We keep the legal framing short on purpose, then spend the rest of this piece on the how-to.
The legal foundation, briefly
The European Accessibility Act, Directive (EU) 2019/882, has applied EU-wide since June 28, 2025, and Germany transposed it into national law through the Barrierefreiheitsstärkungsgesetz (BFSG), which took effect on the same date. For most consumer-facing digital products and services, including B2C online shops, the directive does not define its own technical rules. It points to the harmonized standard EN 301 549, which incorporates WCAG 2.1 at Conformance Level AA in full as the accepted way to demonstrate conformity. Microenterprises, meaning businesses with fewer than 10 employees and either annual turnover or a balance sheet total below EUR 2 million, are exempt from the EAA's service-related obligations under Article 4 of the directive, though this exemption is narrow and does not cover product obligations in general. In Germany, enforcement is active: Section 37 BFSG sets administrative fines of up to EUR 10,000 for most violations and up to EUR 100,000 for the more serious categories, and the cross-state market surveillance body for accessibility reported in January 2026 that enforcement has moved from a grace period into an active monitoring phase. None of this is legal advice. Whether a specific offering falls inside or outside scope, and which exemptions apply, is a question for counsel, not for a blog post.
Why the audit-project model stops working after the first pass
A theme audit, a design-system review, an external accessibility test, they all follow the same shape: someone external reviews the current state, produces a list of findings, a team fixes them inside the existing markup, and a re-test confirms the fix. That model answers a snapshot. It does not answer what happens the day after, when a new landing page, a new checkout step, or a third-party widget ships without going through the same review. Every one of those changes can reintroduce a violation the last audit already closed, because the responsibility for conformance lived in the page, not in a layer that governs every page that will ever exist. The result is a compliance program that resets closer to zero with every release cycle, no matter how thorough the last audit was.
How to engineer conformance into the component layer
Step 1: Write down an accessible component contract per component type
Start with an explicit list, not a general policy: which components exist, what accessible behavior each one guarantees, and what would break that guarantee. A form component guarantees labeled inputs, visible error states, and a defined tab order. A navigation component guarantees a skip link and consistent landmark roles. A product card guarantees a described image and a focus-visible state. Write it down as a contract a component either fulfills or does not, not as a page-level checklist someone re-runs by hand for every launch.
Step 2: Encode contrast and typography as tokens, not per-page choices
Color-contrast failures rarely come from a deliberate design decision. They come from a marketer or designer picking a shade that looks fine on one background and fails WCAG's 4.5:1 minimum on another. Move contrast-safe color pairs and font sizes into design tokens that the component layer enforces, and a campaign page inherits a compliant palette by default, instead of needing a manual contrast check before every launch.
Step 3: Centralize keyboard and focus logic once, reuse it everywhere
Focus order and full keyboard operability are two of the most common WCAG 2.1 AA failure points, and also two of the hardest to fix consistently by hand across dozens of templates. Build the logic once, inside the shared modal, dropdown, and form components, and every page that reuses those components inherits correct behavior without a developer re-implementing it from scratch each time.
Step 4: Gate every component in CI before it reaches a page
An audit tests the finished page, weeks or months after it launched. A component gate tests the building block before it ships: automated contrast checks, ARIA-attribute linting, and keyboard-navigation tests running against the component in isolation, inside the same pipeline that already runs your other CI checks. A component that fails the gate does not reach production, regardless of which page eventually uses it, and regardless of which team built that page.
Step 5: Assign ownership and a fixed review cadence, not a one-off project
A component contract without an owner drifts. Name who is responsible for the accessible component library, whether that sits with a frontend guild, a design-system team, or a single senior engineer, and set a fixed review cadence, for example every quarter or with every major design-token release, so the contract keeps up with new WCAG guidance and new component types instead of freezing at the state of the last audit.
Step 6: Extend the same contract to AI-generated content and variants
If AI agents or content tools generate copy variants, layout tests, or personalized product descriptions inside your storefront, the accessible component contract has to apply to them too. An agent that swaps a headline for an A/B test should not be able to place it inside a component that breaks the contrast contract, and a generated product image should not skip the alt-text requirement just because a human did not write it by hand. Building that boundary into the Agentic Frontend Management Platform itself, rather than into a review step someone has to remember, is what keeps AI-assisted content inside the same conformance guarantee as everything else on the page.
What this looks like at the platform level
At Laioutr, this is what WCAG-Ready components mean in practice: forms, navigation, cards, and modals are built once with the contract above baked in, and every Content Management workflow, every new page, and every Composable Digital Experience Platform integration reuses them instead of re-implementing markup per page. Developers own the component contract, and product and UX teams compose new pages from components that already carry the guarantee, instead of testing accessibility as a separate, late-stage step before launch.
Where this differs from our other accessibility content
We have covered accessibility from a platform-specific angle before: Magento 2 and the German BFSG looks at why the theme layer specifically is where Magento shops run into trouble, and what a decoupled frontend changes for that one stack. This piece is deliberately platform-agnostic: the legal framework is the same regardless of your backend, and the engineering answer, moving conformance into the component contract instead of the audit, applies whether you run Magento, Shopware, commercetools, or a custom stack. If you already read the Magento piece, treat this as the general version of the same argument, built for developers working outside a single platform.
Our take
An audit is not wrong to run. A clean baseline finding still matters, and courts and market-surveillance authorities will still ask for one. But an audit describes a state, it does not maintain one. Conformance holds up over time only where it is a property of the thing you reuse on every page, the component, not a property of the page itself. That is an engineering decision, not a legal one, and it is one your team can make before the next audit finds the same class of issue again.
Frequently asked questions
Does this replace the need for an accessibility audit? No. An initial audit still establishes your baseline and is often expected by market-surveillance authorities and courts as evidence of good-faith effort. What changes is what happens after: instead of re-running a full audit for every release, you gate individual components before they ship.
Does WCAG 2.1 AA guarantee legal compliance with the EAA or BFSG? Following EN 301 549, which incorporates WCAG 2.1 AA, is the accepted way to demonstrate conformity for most digital products and services in scope. Whether your specific offering is in scope, and whether any exemption applies, is a legal question your counsel should confirm, not something this article can determine for you.
Do I need to rebuild my frontend to apply a component contract? No. The first step is writing the contract down for the components you already have and gating new components against it. Existing pages can be brought into the contract incrementally as they get touched, rather than through a big-bang rebuild.
Does the microenterprise exemption mean small online shops can ignore this? The exemption under the EAA is narrow: it covers service-related obligations for businesses under 10 employees with turnover or a balance sheet total under EUR 2 million, not product obligations in general. Most merchants running a meaningful online storefront should not assume they qualify without checking the specifics with counsel.
Next steps
If you want to see what an accessible component contract looks like against your current frontend, book a 30-minute demo, and we will walk through which of your components already meet it and which do not.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr and works on how teams keep their storefront both compliant and fast to iterate on, without treating accessibility as a recurring emergency.