BFSG vs EAA: Germany's Accessibility Strengthening Act 2025 deadline for WordPress shops

#BFSG vs EAA: Germany’s Accessibility Strengthening Act 2025 deadline for WordPress shops

The Barrierefreiheitsstärkungsgesetz (BFSG) applied from 28 June 2025. The accessibility wave that has been arriving for two decades in WCAG documentation, in Section 508, in the Web Accessibility Directive for the public sector, finally extended to private B2C services across the EU through the European Accessibility Act (EAA). Germany transposed it through the BFSG, Spain through Ley 11/2023, and every other member state through its own act. The substance converges; the procedural details and the enforcement bodies differ.

This is a supporting article in the NIS2 and DORA on WordPress pillar because procurement teams now bundle accessibility, NIS2 and DORA into a single supplier scoreboard.

#TL;DR

• BFSG date in force: 28 June 2025.
• BFSG transposes EAA Directive 2019/882.
• Applies to e-commerce services targeting consumers in Germany.
• Microenterprise exception applies to services, not products.
• Four WordPress plugin categories fail audits most often.
• Enforcement: MLBF, the joint market surveillance body of the federal states, with fines of up to 100,000 EUR under BFSG §37.

#BFSG requirements for WooCommerce shops

BFSG §1 lists the products and services in scope. The services line that catches WooCommerce: “Dienstleistungen im elektronischen Geschäftsverkehr” - services in electronic commerce. A WooCommerce shop that sells goods or services to consumers in Germany is in scope unless it qualifies as a microenterprise providing services.

§2 and §3(1) define the key terms. Most important for WordPress shop owners:

• Verbraucher (consumer): a natural person acting outside their trade, business, craft or profession. The BFSG protects consumer-facing transactions, not pure B2B.
• Wirtschaftsakteur (economic operator): manufacturer, importer, distributor, or service provider. A WooCommerce operator is a service provider for the e-commerce service line.
• Barrierefreiheit (accessibility): the requirement that products and services be usable by people with disabilities in the usual manner, without particular difficulty and in principle without external help.

§3(3) carves out the microenterprise exception. A business with fewer than 10 persons employed and annual turnover or balance sheet not exceeding 2 million EUR is exempt for services, not for products. A small WooCommerce operator selling consumer goods may rely on this exemption for the e-commerce service obligation; the goods themselves are a separate question.

§3(1) requires that products and services be accessible in that sense. The concrete technical requirements are not in the act itself: §3(2) delegates them to an ordinance, the BFSGV, which follows EAA Annex I. §4 adds a presumption of conformity for services that meet harmonised standards.

§14(1) No. 2 together with Anlage 3 obliges service providers to publish information on how their service meets the accessibility requirements. In practice this is the accessibility statement; the mandatory content is listed below.

§37 sets fines of up to 100,000 EUR for offering a service that does not meet the requirements and up to 10,000 EUR for other breaches, such as failing to inform or answer the authority. Enforcement sits with one joint body of the federal states, described below.

#How the BFSG implements the EAA directive

The European Accessibility Act is a directive, not a regulation. Member states had to transpose it by 28 June 2022 and apply national rules from 28 June 2025 (Article 31). The substance is in Annex I. Section III lists the general requirements for all services in scope, Section IV the additional requirements for specific services, and point (g) of Section IV covers e-commerce.

Section III requires, among other things, information about how the service works, available through more than one sensory channel, and websites and mobile apps that are perceivable, operable, understandable and robust. Section IV(g) adds three e-commerce duties: accessibility information on the products sold, accessible identification, security and payment functions, and accessible identification methods, electronic signatures and payment services.

National transpositions converge on substance and diverge on procedure. Germany gives market surveillance to a joint body of the federal states. Spain transposed the directive through Ley 11/2023 of 8 May 2023. For a WordPress shop serving several EU countries, the practical answer is to comply with the strictest variant and document the compliance once.

#Who enforces the BFSG against online shops

The federal states do not run sixteen separate BFSG offices. They set up one joint body, the Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF), a public-law institution in Magdeburg that supervises the BFSG for all 16 states (MLBF, about us). It publishes separate market surveillance strategies for products and for services, and its website carries two forms for consumers: a report of a barrier and a formal application under §32(1) BFSG.

The second form is the one a shop owner should know about. Under §32 BFSG a consumer who cannot use a service, or a recognised disability association or qualified consumer body acting for that consumer, can require the authority to open proceedings against the operator. The authority decides on the application by formal notice. One customer complaint is therefore enough to start a check; the authority does not have to find the shop itself.

#How the market surveillance authority checks a WooCommerce shop

§28(2) BFSG lets the authority check services without a specific reason, by sampling. For websites and apps, Anlage 1 to the BFSG fixes the method. Every step of a process is checked in the order a typical user follows it, and the check covers forms, controls and dialogs, input confirmations, error messages and other feedback, and the behaviour of the site with different software and assistive technologies.

Anlage 1 No. 2 also defines the sample. Mapped to a WooCommerce shop, it looks like this:

One rule puts the checkout at the centre of every check: if a sampled page is a step in a process, all steps of that process are tested. A product page leads to the cart, so cart, checkout, payment and order confirmation are in scope from the first sampled product.

#What the BFSGV requires from an e-commerce service

The technical requirements live in the Verordnung zum Barrierefreiheitsstärkungsgesetz (BFSGV) of 15 June 2022. Two of its provisions apply to a shop.

§12 BFSGV sets general requirements for all services. Information about how the service works must be available through more than one sensory channel, be findable and understandable, come in text formats that users can convert into other formats, use adequate font size and contrast, and offer an alternative for non-text content. Websites and mobile apps must be perceivable, operable, understandable and robust, which are the four principles WCAG is built on. Support services such as a help desk must provide information on accessibility through accessible means of communication.

§19 BFSGV adds three requirements for e-commerce:

• accessibility information on the products and services on sale, where the responsible economic operator supplies it;
• perceivable, operable, understandable and robust identification, authentication, security and payment functions when they are part of the service;
• perceivable, operable, understandable and robust identification methods, electronic signatures and payment services.

For WooCommerce this points at three areas that themes rarely cover: the login and registration forms, any two-factor or captcha step, and the payment form. An embedded card form or a redirect page of the payment provider is still part of the service the shop offers to the consumer.

#Which standard proves BFSG conformity

§4 BFSG presumes conformity when a service meets harmonised standards whose references are published in the Official Journal of the EU. The Bundesfachstelle Barrierefreiheit, which §3(2) BFSGV tasks with publishing the relevant standards, reports that the European Commission issued standardisation request M/587 for new and revised harmonised standards under the directive (Bundesfachstelle Barrierefreiheit, standards page). Until that work is finished, it names EN 301 549 V3.2.1 as the central technical reference for digital services. The web requirements are in clause 9 and table A.1, and they point to WCAG 2.1 success criteria.

The practical reference today is therefore WCAG 2.1 level AA through EN 301 549. An audit against WCAG 2.2 AA covers it: according to the W3C overview of WCAG 2.2, the 2.1 criteria carry over except 4.1.1 Parsing, which was removed, and new AA criteria such as 2.4.11 Focus Not Obscured, 2.5.8 Target Size and 3.3.8 Accessible Authentication apply directly to sticky headers, mobile checkout buttons and login forms.

#What the accessibility information under Anlage 3 must contain

§14(1) No. 2 BFSG allows a service only if the provider has prepared the information required by Anlage 3 and made it publicly available in an accessible form. Anlage 3 says where and what. The information goes into the general terms and conditions or is published in another clearly perceivable way, and it must contain at least:

• a general description of the service in an accessible format;
• the descriptions and explanations needed to understand how the service is carried out;
• a description of how the service meets the accessibility requirements of the BFSGV;
• the competent market surveillance authority, which today is the MLBF.

§14(2) requires the provider to keep this information for as long as it offers the service. Missing or incomplete information is a formal non-conformity under §30, which the MLBF lists as a separate check next to the technical one.

#Exceptions for fundamental alteration and disproportionate burden

§16 and §17 BFSG let an operator skip a requirement if meeting it would fundamentally change the nature of the service or impose a disproportionate burden. Neither works as a blanket waiver. The operator makes its own assessment, documents it, keeps it for five years after it last provided the service and hands a copy to the authority on request. A service provider relying on §17 must repeat the assessment for each category of service at least every five years, and also whenever the service changes or the authority asks. It must inform the authority when it relies on the exception; microenterprises are exempt from that notice. An operator that received outside public or private funds to improve accessibility cannot invoke the disproportionate burden at all.

Anlage 4 lists the criteria for the assessment, starting with the ratio between the net cost of accessibility and the total operating and investment cost of providing the service. Under §28(3) the authority checks whether the assessment exists, whether it applies those criteria correctly, and whether the remaining requirements are met.

#What happens when a shop fails a BFSG check

§29 BFSG escalates in three steps. The authority first asks the provider to restore conformity within a reasonable deadline. If nothing happens, it repeats the request and threatens to prohibit the service. If the second deadline passes too, it can order the provider to stop offering the service, and lifts the order once conformity is shown. A provider that knows its service does not comply must tell the authority on its own initiative under §14(4), with details of the non-conformity and the corrective measures.

The two fine levels in §37(2) follow the same split as the checks. Offering a service that does not meet the requirements (§37(1) No. 8) can cost up to 100,000 EUR. Failing to give the authority information or documents falls into the lower tier of up to 10,000 EUR.

#BFSG transition period until 2030

§38 BFSG is often read as a grace period for existing shops. It is narrower than that. Service providers may keep using products (in the sense of §1(2), such as payment terminals) that they lawfully used before 28 June 2025 until 27 June 2030. Service contracts concluded before 28 June 2025 may continue unchanged until they expire, but no longer than 27 June 2030. Self-service terminals already in use may stay in service until the end of their economic life, at most fifteen years after they were put into use.

None of this postpones the requirements for the shop website. §1(3) applies the act to services provided to consumers after 28 June 2025, and every order placed in the shop after that date is such a service.

#Which WordPress plugins fail accessibility audits

I run accessibility audits for WooCommerce shops preparing for BFSG. Four plugin categories recur as the highest-rejection-rate findings:

1. Cookie banners that trap keyboard focus. A modal cookie consent layer that captures focus and does not return it after dismissal. The user cannot tab to the body content. Common in cookie plugins built before WCAG 2.1 keyboard guidance was widely understood. The fix: focus return to the trigger element, escape-key support, no focus loops outside the modal.

2. Slider and carousel plugins without keyboard navigation. Slick, Swiper and Owl Carousel. Default configurations often lack keyboard arrow navigation, focus indicators on slide controls, and pause-on-focus behaviour. Auto-rotating carousels also fail WCAG 2.2.2 (Pause, Stop, Hide). The fix: keyboard-accessible navigation arrows, pause control, manual rotation only or pause on focus.

3. Popup builders without focus return on close. Lead-capture popups, exit-intent popups, marketing modals built with popup-builder plugins. The pattern is the same as the cookie banner: focus enters the modal, the close button is reachable, but on close focus does not return to the element that triggered the popup. Screen reader users land in a random part of the document.

4. Product gallery plugins with images missing accessible names. WooCommerce gallery, lightbox plugins, product variation swatches. The visual designer specifies the image but the accessible name is left empty or set to a filename. Decorative images can be empty (alt=""); informative images must carry a meaningful accessible name. Variation swatches presented as colour squares without text need an accessible name (aria-label) for the swatch, not just for the visible label.

These four patterns close the gap between “the site looks accessible in the browser” and “the site survives a check by the market surveillance authority”. The audit checklist runs against WCAG 2.2 AA, which includes the WCAG 2.1 AA criteria that EN 301 549 currently references (see the standards section above).

The same audit question belongs before you buy an extension. On 20 October 2026 Equalize Digital published its WooCommerce case study: between June 2025 and August 2026 it audited 43 official extensions and logged 519 issues failing 32 WCAG success criteria. Teams at Automattic and Fueled fixed the 41 extensions WooCommerce maintains, and the Amazon Pay and Affirm findings went back to those two vendors. WooCommerce publishes accessibility conformance reports (ACRs) for them on its accessibility page. The WooCommerce Bookings report, for example, names version 3.1.0, a report date of 24 July 2026, the Twenty Twenty-Five theme used for testing and the barriers still open. A shop on Shopify, Shopware, PrestaShop or a custom stack also runs on apps and modules it did not build, so ask every vendor for an ACR before purchase and check the edition, version, theme and exceptions. ITI publishes four VPAT editions: the WooCommerce reports use the WCAG edition, while the EU and INT editions also cover EN 301 549. When a vendor has no report, put the extension’s checkout, account and booking flows into the accessibility audit before launch, or into a WooCommerce EU readiness review.

Update, 27 October 2026. Storefront plugins are where shops most often fail an accessibility check: a custom control replaces a native one, an icon has no name, a progress bar has no value, a modal ignores the keyboard. Test each plugin you add with the keyboard alone and with a screen reader. In my own plugins, accessible behaviour looks like this. Swatch shows the chosen value beside the attribute label in words, as in “Colour: Red”, and screen readers announce the change. Badgevo prints a caption under each badge, and that caption is what screen readers hear. In the Elektilo quiz, arrow keys move between answers and Space or Enter picks one. The Reel lightbox steps through images with arrow buttons, the Left and Right keys or a swipe, and announces “Image N of M”. Peek opens its quick view in an accessible modal. Hold any plugin you test to the same bar, mine or another vendor’s.

#BFSG checklist for WooCommerce shops

The agency-side checklist that ships with BFSG-ready WooCommerce engagements:

• Accessibility statement page, in German, accessible from every footer, listing the WCAG 2.2 conformance level, known limitations, contact for accessibility issues.
• Theme audited at WCAG 2.2 AA. Heading hierarchy, landmark regions, sufficient colour contrast, keyboard focus indicators on every interactive element, skip-to-content link.
• Forms with labels, error messaging, success messaging. Each input has a visible label and an accessible name. Errors are announced to screen readers. Success messages are visible and read by assistive tech.
• Plugin audit, with the four patterns above as primary checks. Cookie banner, slider, popup, gallery. Plus product variation swatches. Plus checkout flow.
• Document upload accessibility. PDFs in product downloads need to be accessible PDFs (tagged structure, alt text on images, reading order). Inaccessible PDFs are a recurring audit finding.
• Video accessibility. Captions on every product video. Audio descriptions for content that conveys information visually only.
• Tested with at least two assistive technologies. Screen reader (NVDA on Windows, VoiceOver on macOS), keyboard-only navigation, high-contrast mode.

Pricing for an accessibility-engineering engagement is individual; the audit and remediation hours depend on the theme, the active plugin set, and the number of templated page types.

#BFSG, NIS2 and DORA in supplier reviews

Procurement teams in regulated sectors (banking, insurance, health) increasingly bundle three filters into a single supplier review:

• BFSG / EAA accessibility conformance.
• NIS2 Article 21 risk management evidence.
• DORA Article 28 third-party clauses (for financial entities).

A WordPress shop operator outside the regulated sectors only deals with BFSG. A WordPress shop operator that also processes payments, holds insurance partnerships or supplies regulated industries deals with all three. The supplier security pack I ship in those engagements addresses each filter with its own short document, cross-referenced. The other EU duties of a shop are covered in WooCommerce EU readiness.

#Related articles on NIS2 and DORA

• Pillar: NIS2 and DORA on WordPress: 2026 compliance stack
• NIS2 Annex II for WordPress agencies: scope, deadlines, evidence trail
• DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit
• Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress

#How to prepare a shop for a BFSG audit

First, establish whether the shop is in scope. Selling to consumers in Germany is an e-commerce service under §1 BFSG. A business with fewer than 10 employees and turnover or balance sheet of up to 2 million EUR can rely on the exemption in §3(3), but it only covers service obligations, and the products sold remain in scope.

If the shop is in scope, start with the plugins that fail audits most often: cookie banner, slider, popup and product gallery. Go through each one with the keyboard only and check where focus returns when a window closes. Then audit the theme against WCAG 2.2 AA, and the checkout forms with it.

Finally, prepare the accessibility information in German, linked from the footer, with the conformance level, known limitations, a contact and the MLBF as the competent authority. Record what you tested with: NVDA on Windows, VoiceOver on macOS, navigation without a mouse. Fines under §37 reach 100,000 EUR, so the statement must describe what actually works in the shop. Selling in several EU countries? Document conformity once, against the strictest transposition.