European Accessibility Act and BFSG: Legal Basics for Online Stores
AI generated
A11Y
WCAG
Accessibility · EAA · BFSG · Legal & Compliance
European Accessibility Act and BFSG
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.

18 min read EAA · BFSG · WCAG 2.1 AA Magento 2.4.8 · Hyva Theme · Compliance

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.

11. FAQ: European Accessibility Act and BFSG

1What is the difference between the EAA and the BFSG?
The EAA is the underlying EU Directive 2019/882. The BFSG is the German national transposition, complemented by an ordinance for technical details.
2Since when has the BFSG applied to online stores?
Since June 28, 2025 for new offerings. Existing contracts have a transitional period until June 28, 2030, unless there is a substantial change.
3Which businesses are exempt from the BFSG?
Micro-enterprises with fewer than 10 employees and at most 2 million euros in annual turnover. The exemption must be proven in a dispute.
4Which areas of an online store must be accessible?
Catalog, search, cart, checkout with payment, customer account, and order communication. Checkout carries the greatest risk.
5Which technical standard counts as proof of conformity?
EN 301 549 references WCAG 2.1, Level AA, for web content. Anyone meeting these criteria is considered compliant.
6Do I have to publish an accessibility statement?
No direct legal obligation like the public sector's BITV statements, but a documentation duty toward authorities. A public statement has become best practice.
7What happens in case of a BFSG violation?
Corrective action orders and fines up to 100,000 euros. In addition, civil action by consumer protection associations is possible.
8Does the BFSG also apply to existing contracts and legacy store systems?
Transitional period until 2030, but any substantial change, such as a theme relaunch, immediately ends the grandfathering.
9How do I get started practically as a Magento store owner?
Audit with axe-core plus manual testing, prioritize checkout, then anchor automated tests permanently in the CI pipeline.
10Does Hyva Theme automatically help with BFSG compliance?
Lean, semantic HTML as a good base, but does not replace targeted implementation of forms, focus management and alt text.