The German Barrierefreiheitsstärkungsgesetz (BFSG) applied from 2025-06-28 and transposes EAA Directive 2019/882. Practical guide for WooCommerce shops on what changed and what plugins fail under audit.
EN

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

4.60 /5 - (12 votes )
Last verified: May 1, 2026
7min read
Guide
500+ WP projects

#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. France transposed it through a décret. Spain through a Royal Decree. 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: federal-state market surveillance authorities, with monetary penalties in BFSG §37.

#What the BFSG actually requires

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 defines 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.

§4 mandates that products and services placed on the market or made available comply with accessibility requirements. §10 lists the substantive accessibility requirements. They are the same as those in EAA Annex I.

§13 covers the obligations of service providers to publish accessibility information. For an e-commerce service, this includes how the service is provided in an accessible format, what assistive technologies are supported, and where the user can find accessibility statements.

§37 sets administrative penalties up to 100,000 EUR for some breaches, with the federal-state market surveillance authorities responsible for enforcement.

#The relationship to EAA Directive 2019/882

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. The substance is in Annex I, which lists the accessibility requirements for each product and service category. Annex I Section III applies to services, including e-commerce services.

Under Annex I Section III, accessibility requirements for e-commerce services include providing information about the functioning of the service, ensuring the website, mobile applications, and electronic identification methods are accessible, supporting alternative input modes, and providing accessibility statements.

National transpositions converge on substance and diverge on procedure. The BFSG runs market surveillance through federal-state authorities. The Spanish Royal Decree runs it through provincial bodies. The French décret runs it through DGCCRF. For a WordPress shop serving multiple EU countries, the practical answer is to comply with the strictest variant and document the compliance once.

#Four WordPress plugin patterns that fail audit

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, Owl Carousel and the WordPress block-editor cover-block 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 an audit by the federal-state market surveillance authority”. The audit checklist runs against WCAG 2.2 AA for the conformance backbone of EAA Annex I.

#What a BFSG-ready WordPress shop looks like

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.

#Where the BFSG meets NIS2 and DORA

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.

#Cluster reading

Next step

Turn the article into an actual implementation

This block strengthens internal linking and gives readers the most relevant next move instead of leaving them at a dead end.

Related cluster

Explore other WordPress services and knowledge base

Strengthen your business with professional technical support in key areas of the WordPress ecosystem.

Article FAQ

Frequently Asked Questions

Practical answers to apply the topic in real execution.

SEO-ready GEO-ready AEO-ready 5 Q&A
When did the BFSG start applying?
The Barrierefreiheitsstärkungsgesetz applies from 28 June 2025 in Germany. It was published in the Bundesgesetzblatt in 2021 (BGBl. I S. 2970) and provided a transition period until that date. It transposes Directive (EU) 2019/882 (the European Accessibility Act) into German law.
Does the BFSG apply to a WordPress shop selling B2C in Germany?
Yes for products and services within scope. BFSG §1 lists products (e-readers, payment terminals, ATMs, ticketing machines) and services (e-commerce, banking services, e-book reading, electronic communications). A WooCommerce shop targeting consumers in Germany falls under the e-commerce category. Microenterprises providing services are exempt under §3, but only for services, not products.
Is the BFSG identical to the EAA?
The BFSG is the German national transposition of EAA Directive 2019/882. The substance is the same; the obligations on operators in Germany are the same. Other EU member states have their own transpositions (Spain: Royal Decree, France: décret), each may add national specifics on enforcement, market surveillance and penalties.
What WordPress plugins typically fail BFSG audit?
Four patterns recur: cookie banners that trap keyboard focus, slider and carousel plugins without keyboard navigation, popup builders without focus return on close, and product gallery plugins with images missing accessible names. Audit-stage rejection rate on these four categories is the highest in my reviews.
What about microenterprises?
BFSG §3(3) exempts microenterprises (fewer than 10 persons employed and annual turnover or balance sheet not exceeding 2 million EUR) from obligations on services. Products remain in scope regardless of enterprise size if the operator places them on the German market.

Need an FAQ tailored to your industry and market? We can build one aligned with your business goals.

Let’s discuss

Related Articles

WCAG 2.2 was first published as a W3C Recommendation on 2023-10-05; the current published version on www.w3.org/TR/WCAG22/ is dated 2024-12-12. The EU Accessibility Act (Directive 2019/882) applies from 2025-06-28. Germany's Barrierefreiheitsstärkungsgesetz transposes it into federal law on the same date. This article is the implementation map for a WordPress site in 2026.
wordpress

WCAG 2.2, BFSG, and the EU Accessibility Act: the 2026 compliance stack for WordPress

WCAG 2.2 was first published as a W3C Recommendation on 2023-10-05; the current published version on www.w3.org/TR/WCAG22/ is dated 2024-12-12. The EU Accessibility Act (Directive 2019/882) applies from 2025-06-28. Germany's Barrierefreiheitsstärkungsgesetz transposes it into federal law on the same date. This article is the implementation map for a WordPress site in 2026.

Article 28 of Regulation 2022/2554 makes financial entities responsible for the ICT risk of every third-party they touch. I walk through the supplier due-diligence checklist I ship with WordPress engagements for banks and insurers in 2026.
wordpress

DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit

Article 28 of Regulation 2022/2554 makes financial entities responsible for the ICT risk of every third-party they touch. I walk through the supplier due-diligence checklist I ship with WordPress engagements for banks and insurers in 2026.

Article 28(3) of Regulation 2022/2554 obliges financial entities to keep a Register of Information on every ICT third-party arrangement. The fields a WordPress agency must populate to be entered.
wordpress

DORA Register of Information for WordPress vendors: required fields

Article 28(3) of Regulation 2022/2554 obliges financial entities to keep a Register of Information on every ICT third-party arrangement. The fields a WordPress agency must populate to be entered.