Legal Basics for Online Stores
Since June 2025, the German Accessibility Strengthening Act, based on the European Accessibility Act, has obligated numerous online stores to provide digital accessibility. This article explains which businesses are affected, which store areas must be compliant, which deadlines apply, and which concrete steps Magento and Hyva store owners take to meet the legal requirements in practice.
Table of Contents
- 1. What the European Accessibility Act and BFSG Regulate
- 2. Who Falls Under the Obligation: Businesses and Exemptions
- 3. Affected Products and Services in Online Retail
- 4. June 28, 2025: Deadlines and Transitional Rules
- 5. WCAG 2.1 AA as the Technical Benchmark
- 6. Accessible Checkout: Concrete Requirements for the Store
- 7. The Accessibility Statement: Building Mandatory Documentation
- 8. First Steps for Magento Store Owners
- 9. Enforcement, Market Surveillance and Fines Compared
- 10. Summary
- 11. FAQ
1. What the European Accessibility Act and BFSG Regulate
The European Accessibility Act (EAA, Directive EU 2019/882) is an EU directive that requires member states to legally mandate digital accessibility for certain products and services. In Germany, the directive was transposed into national law through the Barrierefreiheitsstaerkungsgesetz (BFSG), the Accessibility Strengthening Act, complemented by the BFSGV ordinance, which specifies technical requirements in detail. Unlike the already existing BITV 2.0, which applies exclusively to public bodies, the BFSG addresses private businesses for the first time, including online stores, banks, e-book providers and telecommunications services.
For Magento store owners this means: an online store is no longer an optional convenience feature. Since the deadline in June 2025 it is subject to a legal obligation for digital accessibility. Anyone who ignores the requirements risks fines, warning letters from consumer protection associations, and reputational damage. At the same time, accessibility opens up a larger customer segment: according to the European Commission, around 87 million people with disabilities live in the EU, many of them active online shoppers who directly benefit from clearly structured, keyboard-operable, high-contrast stores.
2. Who Falls Under the Obligation: Businesses and Exemptions
The BFSG applies to economic operators offering products or services covered by its scope to consumers in the EU. For e-commerce this specifically means: any provider that concludes contracts with consumers via a website or app, meaning a typical online store, generally falls under the law. This does not just affect the store operator itself, but potentially also payment service providers whose checkout components are embedded.
An important exception applies to micro-enterprises: companies with fewer than ten employees and an annual turnover or annual balance sheet total not exceeding two million euros are exempt from the BFSG's service obligations. However, this exemption does not apply automatically in all cases and must be interpreted restrictively, especially when a micro-enterprise acts as a manufacturer of physical products rather than merely offering a service. Anyone relying on the exemption should document the classification, since in a dispute the provider bears the burden of proof.
3. Affected Products and Services in Online Retail
Electronic commerce, meaning e-commerce, is explicitly named in the BFSG as an affected service. That covers not just the visible storefront but the entire contract conclusion process: product catalog, search and filters, cart, checkout including payment processing, customer account management, and the communication surrounding an order such as confirmation emails and invoices. Mobile apps, provided they mirror the same ordering process, fall under the same obligation as the desktop version of the store.
Not every subpage carries the same risk. The checkout flow, where users actually conclude a contract, is at the center of scrutiny because forms, error messages and time limits create the biggest barriers there. Pure marketing content such as a blog article does technically fall under the general duty of care for an accessible website, but in practice is deprioritized against the core processes that enable an immediate contract conclusion.
4. June 28, 2025: Deadlines and Transitional Rules
The central deadline is June 28, 2025. From this date, all newly placed products and all newly offered services falling under the BFSG must meet the requirements. For online stores this specifically means: a store already live at that point had to ensure conformity from that date, not gradually catch up afterward.
For existing service contracts concluded before the deadline, a transitional period until June 28, 2030 applies, provided the service does not change substantially. For self-service terminals that were already legally in use before the deadline, an extended usage period until mid-2030 also applies. Important for store owners: any major relaunch project, any fundamental theme migration, or any switch of the checkout solution counts as a substantial change and immediately ends the grandfathering, not only at the end of the transition period.
5. WCAG 2.1 AA as the Technical Benchmark
The BFSG itself formulates requirements largely technology-neutrally. Practical proof of conformity happens through the harmonized standard EN 301 549, which for web content refers to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. Anyone who demonstrably meets WCAG 2.1 AA is considered compliant by market surveillance authorities. The four principles of WCAG, known by the acronym POUR, perceivable, operable, understandable and robust, form the framework for all individual criteria.
In practice this means for developers: semantic HTML instead of pure div soup, correct landmark roles, a logical focus order, and alt text for images are not nice-to-haves but mandatory criteria with a direct link to specific WCAG success criteria. A skip link to the page start, for example, fulfills criterion 2.4.1 (Bypass Blocks) and is equally relevant for keyboard users and screen reader users.
<!-- Hyva phtml: semantic landmarks and skip link for keyboard and screen reader users -->
<a href="#maincontent" class="skip-link sr-only focus:not-sr-only focus:absolute focus:top-2 focus:left-2 focus:z-50 focus:bg-white focus:text-black focus:px-4 focus:py-2 focus:rounded">
<?= $escaper->escapeHtml(__('Skip to main content')) ?>
</a>
<header role="banner">
<nav aria-label="<?= $escaper->escapeHtmlAttr(__('Main navigation')) ?>">
<!-- primary navigation -->
</nav>
</header>
<main id="maincontent" role="main" tabindex="-1">
<h1><?= $escaper->escapeHtml($block->getPageTitle()) ?></h1>
<!-- page content -->
</main>
<footer role="contentinfo">
<!-- footer content -->
</footer>
6. Accessible Checkout: Concrete Requirements for the Store
Checkout is the most business-critical area because the actual contract conclusion happens there, and barriers directly lead to cart abandonment. Form fields need a visible, programmatically linked label element, not just placeholder text that disappears on focus. Required fields must be identifiable both visually and for screen readers, for example through aria-required="true". Error messages must not be communicated by color alone and must be announced to assistive technology right when they occur, typically via a role="alert" region.
Time limits, for instance during payment processing, must be extendable or display a warning before expiry. Focus management is another critical point: if a modal dialog opens for an address correction, keyboard focus must programmatically move into the dialog and return to the triggering element on close, otherwise a keyboard user loses orientation completely within the form.
<!-- Accessible checkout form field with error handling -->
<div class="mb-4">
<label for="email" class="block font-semibold mb-1">
<?= $escaper->escapeHtml(__('Email address')) ?>
<span aria-hidden="true">*</span>
</label>
<input
type="email"
id="email"
name="email"
required
aria-required="true"
aria-invalid="false"
aria-describedby="email-error"
x-on:blur="validateEmail"
class="w-full border border-gray-300 rounded-lg px-3 py-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2"
>
<p id="email-error" class="text-red-600 text-sm mt-1" role="alert" x-show="emailError" x-text="emailError"></p>
</div>
/* Visible focus indicator for keyboard users, matches WCAG 2.1 SC 2.4.7 */
:focus-visible {
outline: 2px solid #18181b;
outline-offset: 2px;
}
/* Do not remove focus outlines without a visible replacement */
button:focus:not(:focus-visible) {
outline: none;
}
/* Respect user preference for reduced motion */
@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
/* Sufficient color contrast for error states, WCAG 2.1 SC 1.4.3 */
.form-error {
color: #b91c1c;
font-weight: 600;
}
7. The Accessibility Statement: Building Mandatory Documentation
Economic operators must demonstrate that their products and services conform to the requirements of EN 301 549 and keep this technical documentation available for the responsible market surveillance authority for five years. In practice, modeled on the BITV statements of the public sector, voluntarily publishing an accessibility statement has become established as best practice: an easy-to-find page that names the standard applied, the current conformance status, known limitations, and a contact for feedback.
A well-maintained statement not only documents outward-facing information but also forces an honest internal inventory: which components have been checked, which limitations are known, by when should they be fixed. This self-commitment significantly reduces the risk of a warning letter, because it shows the operator is actively working toward conformance instead of ignoring accessibility entirely.
{
"accessibilityStatement": {
"standard": "EN 301 549 (WCAG 2.1 Level AA)",
"conformityStatus": "partially conformant",
"lastAssessment": "2026-05-15",
"knownLimitations": [
"PDF invoices before 2026-01-01 are not tagged",
"Product filter uses a custom widget without full keyboard support"
],
"feedbackContact": {
"email": "accessibility@mironsoft.de",
"responseTime": "5 business days"
},
"enforcementBody": "Market surveillance authority of the responsible federal state",
"documentationRetentionYears": 5
}
}
8. First Steps for Magento Store Owners
The first sensible step is a current-state audit: automated tools like axe-core or Lighthouse cover a relevant but limited portion of the WCAG criteria, typically around a third. The rest, such as the logic of focus order or the clarity of error messages, requires manual testing with a keyboard and a screen reader. Priority goes to the checkout flow, followed by product pages and search, because these areas carry the greatest legal and business risk.
Automated tests belong in the CI pipeline, so regressions are caught with every deployment instead of only during an external audit. In Hyva stores this combines well with Playwright and axe-core, run directly against the pages generated by the build. In parallel, training for the development team pays off: once a team has internalized the WCAG core principles, they avoid the most common mistakes while writing new templates instead of fixing them afterward.
// Automated accessibility testing in CI using axe-core and Playwright
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('checkout page has no critical accessibility violations', async ({ page }) => {
await page.goto('/checkout');
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
.analyze();
const critical = results.violations.filter(v => v.impact === 'critical' || v.impact === 'serious');
expect(critical, JSON.stringify(critical, null, 2)).toEqual([]);
});
// Run locally: npx playwright test accessibility.spec.js
9. Enforcement, Market Surveillance and Fines Compared
The market surveillance authorities of the German federal states check compliance with the BFSG, respond to consumer complaints, and can order corrective action when violations are found. If a provider remains inactive, the BFSG provides for fines of up to 100,000 euros, graduated by severity and duration of the violation. In addition, consumer protection associations can pursue civil action against non-compliant providers under the Injunctions Act, independent of the administrative procedure.
The following overview compares typical problem areas in Magento stores with the corresponding compliant implementation.
| Area | Non-compliant | BFSG-compliant | Recommended implementation |
|---|---|---|---|
| Product images | No alt text | Descriptive alt text | Maintain alt attribute per product image |
| Checkout form | Placeholder instead of label | Visible label element | Link label for/id consistently |
| PDF invoices | Untagged image PDF | Tagged, structured PDF | Generate PDF/UA-conformant files |
| Product videos | No captions | Captions and transcript | Embed a WebVTT track |
| Color contrast | Contrast below 4.5:1 | Contrast at least 4.5:1 | Test design tokens with a contrast checker |
Using this table as a checklist for the next sprint already covers the most common issues found in practice. What matters is that these points are not treated as a one-off project but permanently anchored in the definition of done and code review, because every new component can reintroduce the same mistakes.
Mironsoft
BFSG audits, WCAG implementation and accessible Hyva stores
Ready to make your store BFSG-compliant?
We audit your Magento or Hyva store against WCAG 2.1 AA, prioritize the legally critical areas such as checkout and forms, and implement the changes together with your team, including the accessibility statement.
BFSG Audit
Automated and manual testing against WCAG 2.1 AA with risk-based prioritization
Checkout Implementation
Retrofit forms, focus management and error messages for accessibility
CI Integration
Integrate axe-core and Playwright into the pipeline, catch regressions automatically
10. Summary
The European Accessibility Act and BFSG make digital accessibility mandatory for a large share of online stores in Germany. Since June 28, 2025, businesses that are not micro-enterprises must align their e-commerce presence, including checkout, forms, and customer communication, with WCAG 2.1 AA, proven through the harmonized standard EN 301 549. Existing contracts enjoy a transitional period until 2030, which ends immediately upon any substantial change.
Acting now provides a double benefit: legal certainty against market surveillance and warning letters, plus access to a customer segment of around 87 million people with disabilities in the EU. A structured audit, prioritized implementation in checkout, and automated tests in the CI pipeline are the most pragmatic way to turn a legal obligation into a resilient, lasting process.
European Accessibility Act and BFSG, the essentials at a glance
Who is affected
All online stores with consumer contracts, except micro-enterprises with fewer than 10 employees and at most 2 million euros in annual turnover.
Key deadline
June 28, 2025 for new offerings, existing contracts until June 28, 2030, provided no substantial change occurs.
Technical benchmark
EN 301 549 referencing WCAG 2.1, Level AA, as the recognized proof of conformity.
First steps
Audit with axe-core and manual testing, prioritize checkout, publish an accessibility statement, anchor tests in CI.