> Does the European Accessibility Act apply to a B2B shop? Scope under BFSG and BaFG, the microenterprise exemption, 2026 enforcement, WCAG 2.2 and a fix plan. > > Web page: https://balazscsorba.com/blog/european-accessibility-act-b2b-shop · Language: English · Also available in: [Deutsch](https://balazscsorba.com/de/blog/european-accessibility-act-b2b-shop.md) · [Magyar](https://balazscsorba.com/hu/blog/european-accessibility-act-b2b-shop.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: European Accessibility Act B2B shop, BFSG B2B Onlineshop, Barrierefreiheit Onlineshop, Spryker barrierefrei, barrierefrei Webshop, BaFG Österreich Webshop, EN 301 549 WCAG 2.2, BFSG Kleinstunternehmen Ausnahme, Pimcore TYPO3 Barrierefreiheit, EAA e-commerce checklist [Blog](https://balazscsorba.com/blog)/Web engineering # European Accessibility Act for B2B shops: what Spryker, Pimcore and TYPO3 teams must fix Does the European Accessibility Act apply to a B2B shop? Scope under BFSG and BaFG, the microenterprise exemption, 2026 enforcement, WCAG 2.2 and a fix plan. [Balázs Csorba](https://balazscsorba.com/about)·October 2, 2026·13 min read - European Accessibility Act - BFSG - WCAG 2.2 - B2B e-commerce ![Diagram: a B2B shop fans out to the consumer-scope question under BFSG and BaFG, WCAG 2.2 AA conformity, the accessibility statement and market surveillance.](https://balazscsorba.com/images/blog/european-accessibility-act-b2b-shop/cover.webp?v=7b819fb5dc) ## Key takeaways - The European Accessibility Act covers e-commerce services offered to consumers, so a shop that truly serves only business customers is outside BFSG and BaFG, but the label "B2B" does not decide it, the actual ordering practice does. - Microenterprises (fewer than 10 staff and at most 2 million euros turnover or balance sheet) are exempt for services, which covers most web shops, but never for products. - Enforcement is live in 2026: Germany has a joint market surveillance body (MLBF) working complaint-first, fines reach 100,000 euros in Germany and 80,000 euros in Austria, and the EN 301 549 standard was updated to WCAG 2.2 in September 2026. - Configurators, faceted filters, quick-order forms, checkout validation, modals and PDF datasheets are where B2B shops on Spryker, Pimcore and TYPO3 typically fail, because they are custom frontend code, not platform defaults. - Automated axe scans find a large share of issues by volume but not conformity, so combine them with keyboard and screen reader checks, and fix by user journey rather than by page. On this page 1. [Does the law apply to a B2B shop?](https://balazscsorba.com/#scope) 2. [Microenterprises, deadlines and enforcement in 2026](https://balazscsorba.com/#enforcement) 3. [What you have to meet: EN 301 549, WCAG 2.1 now, 2.2 next](https://balazscsorba.com/#standards) 4. [What typically fails in Spryker, Pimcore and TYPO3 shops](https://balazscsorba.com/#what-fails) 5. [Testing: axe plus real users](https://balazscsorba.com/#testing) 6. [A remediation plan that fits a B2B team](https://balazscsorba.com/#remediation-plan) 7. [My take](https://balazscsorba.com/#my-take) 8. [Sources](https://balazscsorba.com/#sources) The European Accessibility Act (Directive 2019/882) has applied since 28 June 2025. In Germany it is the Barrierefreiheitsstärkungsgesetz (BFSG), in Austria the Barrierefreiheitsgesetz (BaFG). Most articles about it are written for consumer shops. I get a different question from B2B teams on Spryker, Pimcore and TYPO3: "We only sell to companies, so we are out, right?" The honest answer is "probably, if you can prove it, and it still may be the wrong question". In this article I go through the exact scope wording, the microenterprise exemption, what enforcement looks like in October 2026, what WCAG 2.2 and EN 301 549 mean in practice, where B2B shop frontends typically break, and how I would test and remediate. This is engineering advice, not legal advice: have your counsel confirm the scope for your shop. ## Does the law apply to a B2B shop? The scope sits in the definitions. BFSG section 1(3) lists "Dienstleistungen im elektronischen Geschäftsverkehr" among the covered services, and section 2 number 26 defines them as digital services offered via websites and mobile apps and provided electronically at the individual request of a _consumer_ with a view to concluding a _consumer contract_. A consumer, in section 2 number 16, is a natural person who buys or receives the service for purposes that are predominantly neither commercial nor self-employed professional. The German federal accessibility agency states it plainly in its FAQ: services offered exclusively B2B should not be affected. The Austrian chamber of commerce describes the BaFG the same way, covering e-commerce services under a consumer contract. So the law is B2C by construction. Two details matter for engineers. First, the test is about who _can_ place orders in practice. Second, "consumer" is a natural person acting outside their profession, so a company account with a VAT ID is clearly out, while an anonymous visitor who can buy as a private person is not. - Open registration: anyone can create an account, and no step checks that the buyer is a business. - Guest checkout with private addresses, or a payment method that is typical for consumers. - Public price lists with a visible "buy" button, no login wall, no business-only wording in the terms. - A B2B2C setup, for example a dealer portal where the dealer sells on to private end customers through your shop. - A "B2B" label in the footer while the ordering flow itself never asks for a company. A first-pass scope check. The consumer test is applied to the real ordering flow, which is why the evidence line matters. **The label does not decide, the flow does** A law firm summary I read describes the same logic: a site calling itself B2B is not enough, and hybrid shops where consumers can factually initiate or conclude contracts are high-risk edge cases that need individual review. If you want to rely on the B2B position, make it demonstrable: registration only with a company name and VAT ID that you verify, business-only terms, and no consumer payment flow. Scenario Likely in scope? Why Dealer portal behind login, accounts created by sales after VAT ID check No Only businesses can order, consumers cannot start a contract Open shop, registration with any e-mail, private persons can buy Yes Consumers can conclude a contract B2B shop plus a separate consumer storefront on the same platform Consumer storefront: yes The consumer-facing service is covered, shared components often drag the other shop along Marketing site and PDF catalogue, no ordering Unclear No contract is concluded, but it may initiate one; I would still fix it Microenterprise (under 10 staff, max 2M EUR) selling to consumers No for services Services exemption applies, but not to products ## Microenterprises, deadlines and enforcement in 2026 The microenterprise rule is in BFSG section 3(3): the accessibility duty does not apply to microenterprises that offer or provide services. Section 2 number 17 defines them as fewer than ten persons employed and either an annual turnover of at most 2 million euros or a balance sheet total of at most 2 million euros. The exemption is for services only, so a company that places products on the market stays covered for those. Austria's BaFG uses the same thresholds. I would not assume the exemption without checking the numbers with counsel. On transition periods, do not expect much help for a web shop. Section 38 lets providers keep using products they lawfully used before 28 June 2025 until 27 June 2030, and contracts concluded before that date can continue unchanged until they expire, at most until 27 June 2030. A storefront you change, redesign or extend is not a legacy product in any practical sense. Germany: the market surveillance authority of the federal states for accessibility (MLBF) in Magdeburg was formally established on 26 September 2025, has around 70 staff and adopted its surveillance strategies at the end of January 2026. It works complaint-first, supplemented by risk-based checks: services with high reach, offers critical for independent living and providers with a bad track record, with automated scanners for web services and EN 301 549 as the yardstick. Consumers and recognised associations can ask the authority to open a procedure (section 32). The escalation is a correction request with a deadline, a second request threatening a ban, and finally a distribution ban. The fine for offering a service in breach of section 14, which includes the accessibility information duty, is up to 100,000 euros, and for other breaches such as not answering the authority up to 10,000 euros (section 37). Practitioners also report that warning letters from competitors increased from late 2025, but whether the unfair competition law can be used for BFSG breaches is, as of mid-2026, not settled by case law. Austria: the Sozialministeriumservice is the authority. Consumers can complain free of charge, there is a conciliation step, and administrative fines reach up to 80,000 euros, with lower limits for smaller companies. The European Commission also sent Germany a reasoned opinion in March 2026 about incomplete implementation, which tells me the national details may still move. Country Authority Maximum fine Practical note Germany (BFSG) MLBF Magdeburg, joint body of the Länder 100,000 EUR for non-conforming services or missing statement, 10,000 EUR for other breaches Complaint-first, risk-based checks, correction request before ban Austria (BaFG) Sozialministeriumservice 80,000 EUR, lower for smaller companies Free consumer complaint, conciliation, then administrative procedure My conclusion for B2B teams: if you have a credible B2B-only position, enforcement risk is low today. If you are a hybrid shop, assume you are in scope and treat 2026 as the year the grace period ended. ## What you have to meet: EN 301 549, WCAG 2.1 now, 2.2 next The law itself stays abstract: services must be findable, accessible and usable for people with disabilities in the usual way, without special difficulty and generally without outside help (BFSG section 3(1)). The concrete bar is the harmonised standard. Meeting EN 301 549 creates a presumption of conformity, and the web chapter of EN 301 549 version 3.2.1 references WCAG 2.1 levels A and AA. That changed in September 2026. EN 301 549 version 4.1.1 was published, adopts WCAG 2.2, adds six requirements, drops the obsolete 4.1.1 Parsing criterion and is the first version written with the EAA in mind. It is not yet the legal reference: the presumption of conformity applies once the Commission cites it in the Official Journal. Until then v3.2.1 and WCAG 2.1 AA remain the formal bar. I would still build to WCAG 2.2 AA, because the new criteria hit exactly what B2B shops do: - 2.4.11 Focus Not Obscured (Minimum), AA: sticky headers, cookie banners and mini-carts must not cover the focused element. - 2.5.7 Dragging Movements, AA: sliders and sortable lists need a single-pointer alternative. - 2.5.8 Target Size (Minimum), AA: dense quantity steppers, table icons and filter chips need adequate touch targets. - 3.3.7 Redundant Entry, A: do not make users retype data they already entered in the same checkout, such as the billing address. - 3.3.8 Accessible Authentication (Minimum), AA: no cognitive test in login without an alternative, and password managers must work. - 3.2.6 Consistent Help, A: help and contact stay in the same place across pages. Beyond the markup there are information duties. Providers must prepare the information from annex 3 of the BFSG and publish it in an accessible form, which in practice is an accessibility statement describing the service, the standard applied, known gaps, a way to report barriers and the competent authority. Online shops also have to pass on accessibility information about the products they sell, to the extent the responsible economic operator supplies it. Remember that the statement is a legal duty that can itself be fined. ## What typically fails in Spryker, Pimcore and TYPO3 shops A caveat first: I have found no vendor claim that any of these platforms ships a conformant storefront, and I would not expect one. The failures below are typical storefront patterns, checked against the generic checklists cited in the sources, not from a vendor audit. They sit in the storefront code you wrote or bought, which is why they look the same across stacks. Area Typical failure WCAG criterion Fix Product configurator Custom widgets built from div elements, no keyboard path, price updates not announced 2.1.1, 4.1.2, 4.1.3 Native inputs first, ARIA only where needed, a polite live region for price and validity Faceted filters and sorting Checkboxes that reload the list without notice, focus lost after update, filter chips with tiny targets 2.4.3, 3.2.2, 2.5.8, 4.1.3 Announce the result count, keep focus stable, real buttons with 24 px targets Quick order and bulk upload Inputs without labels, errors only in colour, row-level errors not linked 1.3.1, 3.3.1, 3.3.3 Programmatic labels, error summary with links, text instead of colour alone Checkout and forms Placeholder as label, vague errors, retyping addresses, login with CAPTCHA only 3.3.2, 3.3.7, 3.3.8, 1.3.5 Visible labels, autocomplete attributes, reuse entered data, accessible authentication Modals, mini-cart, mega menu Focus not trapped or not returned, hover-only menus, sticky bars cover focus 2.1.2, 2.4.11, 1.4.13 Dialog pattern with focus return, keyboard-operable menus, scroll padding for sticky UI Product tables and price scales Layout tables without headers, scale prices as images or unlabeled cells 1.3.1, 1.4.4 Real table markup with headers and captions, reflow at 400 percent zoom PDF datasheets and invoices Untagged PDFs, scanned drawings, no reading order 1.1.1, 1.3.1, 2.4.2 Tagged PDFs from the source, HTML alternative, check with a PDF checker ### Spryker Storefront templates are project code on top of the Yves layer, with many custom components for product lists, configurable bundles and quick order. In my experience the problem is not the framework but the dozens of bespoke molecules: a custom dropdown here, an AJAX cart there. I would start with an inventory of every interactive component and decide for each whether a native element can replace it. ### Pimcore Pimcore shops are usually either Twig on Symfony or a headless setup with a separate frontend, so accessibility depends on the frontend team. The extra risk is data-driven rendering: attributes, images and documents coming from product data. If the alt text, the PDF and the heading structure are not data quality rules, no template can repair them. ### TYPO3 TYPO3 renders through Fluid, so semantic output is achievable, but the weak points are editorial content and shop extensions: missing alt text, heading levels chosen for looks, and extension templates with their own markup and forms. I would add editor rules and a template review of every shop extension. If you build agent-facing features on the same markup, accessibility pays twice: semantic HTML and clear labels help screen readers and also help agents, as I discuss in [agentic commerce protocols](https://balazscsorba.com/blog/agentic-commerce-protocols-ucp-acp-guide) and the [WebMCP guide](https://balazscsorba.com/blog/webmcp-agent-ready-website-guide). ## Testing: axe plus real users Deque's study of more than 2,000 audits and 13,000 pages found that automated testing with axe covers 57 percent of issues by volume, far above the old 20 to 30 percent rule of thumb. That is a useful number, but it is share of issues found, not share of criteria, and not conformity. A commentator on the MLBF strategy makes the related point that automated checks typically cover only 30 to 40 percent of the required steps, and that passing a scan is not a free pass. Authorities use scanners, so you need to pass those, and users will find the rest. 1. Run axe-core in CI on the key templates: home, category with filters, product with configurator, cart, each checkout step, login, quick order. Fail the build on new violations. 2. Test with the keyboard only. Every control reachable, visible focus, logical order, no traps, and nothing hidden behind sticky UI. 3. Test with a screen reader on a real journey: NVDA with Firefox or Chrome on Windows, VoiceOver with Safari on macOS and iOS. Search, filter, configure, order. 4. Zoom to 200 percent and 400 percent and use a narrow viewport. Check reflow, target size and that nothing is clipped. 5. Test error paths: submit empty forms, enter an invalid VAT ID, remove an item. Errors must be announced and focus must move sensibly. 6. Check the documents: tag-check the PDF datasheets, invoices and order confirmations that the shop generates. 7. Record results per journey, with a severity and an owner, because that is the base for the accessibility statement. I treat the checklist as a regression suite: axe in the pipeline, a short manual script per release, a deeper audit before major changes. This fits the general pattern I use for [LLM evals](https://balazscsorba.com/blog/llm-evals-for-product-features): automate what is cheap and keep humans on what only humans can judge. ## A remediation plan that fits a B2B team Do not start with a page-by-page audit of 40,000 product pages. Start with the journeys, because templates multiply. This is the order I would use: 1. **Decide the scope.** Settle with legal whether you are B2B-only, hybrid or exempt, and write down the evidence. If you rely on B2B-only, harden the registration and terms. 2. **Inventory templates and components.** List all page templates, interactive components, extensions and generated documents. Group them by journey: find, configure, order, account. 3. **Run a baseline.** Axe over the templates plus a manual pass of the top three journeys. Prioritise by blocking impact: a customer who cannot complete checkout comes first. 4. **Fix shared components first.** Buttons, form fields, dialogs, menus, tables. One fix then lands on every page, and you should add a component test with axe for each. 5. **Fix configurator, filters and checkout.** Replace custom widgets with native controls where possible, add live regions, and fix errors and focus. 6. **Fix content and documents.** Alt text rules in the PIM or CMS, heading rules for editors, tagged PDFs from the generating system or an HTML alternative. 7. **Publish the accessibility statement and a feedback channel.** Include known gaps honestly and a contact for barrier reports, and name the competent authority. 8. **Keep it from regressing.** CI gates, a manual script in the release checklist, and an accessibility owner per team. Re-test when EN 301 549 v4.1.1 becomes the cited reference. Budget honestly: configurators and checkouts are often small areas of the code but large areas of risk, and a rebuild of a custom widget on a native base can be cheaper than patching it. Compared with reworking all templates under time pressure after a complaint, the early fix is also the cheaper one. ## My take Even if you are confident that your B2B shop is out of scope, I would still do the work on the core journeys. The cost is modest when it is part of normal frontend development, the result is better keyboard and mobile usability for every buyer including colleagues who rely on assistive technology, and a clean accessibility position makes questionnaires from large customers easier. That last point is my observation, not a legal obligation. The scope question is where I would spend an hour with a lawyer, the standard question is where I would spend a sprint with the team. If you want help sizing an audit of a Spryker, Pimcore or TYPO3 shop, see my [B2B e-commerce expertise](https://balazscsorba.com/expertise/b2b-ecommerce-developer) page, and for the wider regulatory picture read the [EU AI Act Article 50 checklist](https://balazscsorba.com/blog/eu-ai-act-article-50-developer-checklist). ## Sources 1. [BFSG section 1: purpose and scope (gesetze-im-internet.de)](https://www.gesetze-im-internet.de/bfsg/__1.html) 2. [BFSG section 2: definitions, consumer, microenterprise, e-commerce services](https://www.gesetze-im-internet.de/bfsg/__2.html) 3. [BFSG section 3: accessibility and the microenterprise exemption](https://www.gesetze-im-internet.de/bfsg/__3.html) 4. [BFSG section 14: duties of the service provider](https://www.gesetze-im-internet.de/bfsg/__14.html) 5. [BFSG section 32: rights of consumers and associations in the administrative procedure](https://www.gesetze-im-internet.de/bfsg/__32.html) 6. [BFSG section 37: fines](https://www.gesetze-im-internet.de/bfsg/__37.html) 7. [BFSG section 38: transitional provisions](https://www.gesetze-im-internet.de/bfsg/__38.html) 8. [Bundesfachstelle Barrierefreiheit: FAQ on the BFSG (B2B, microenterprises, EN 301 549)](https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Produkte-und-Dienstleistungen/Barrierefreiheitsstaerkungsgesetz/FAQ/faq_node.html) 9. [AccessibleEU: The European accessibility standard EN 301 549 has been updated (7 September 2026)](https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en) 10. [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) 11. [Deque: Automated testing identifies 57 percent of digital accessibility issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/) 12. [sitebrunch: What is the market surveillance authority for accessibility (MLBF)?](https://www.sitebrunch.com/news/mlbf-marktueberwachungsstelle-barrierefreiheit) 13. [Marcus Herrmann: June 2026, how the MLBF intends to check](https://marcus-herrmann.com/blog/mlbf-verraet-wie-sie-pruefen-will) 14. [axes4: BFSG in practice, what has happened since the deadline (2026)](https://www.axes4.com/de/blog/post/2026/bfsg-in-der-praxis-was-sich-seit-dem-stichtag-getan-hat) 15. [ODC Legal: BFSG for websites, what companies must check in 2026](https://www.odclegal.de/blog/bfsg-website-pflicht) 16. [WKO: Information on the Austrian Barrierefreiheitsgesetz](https://www.wko.at/ce-kennzeichnung-normen/informationen-zum-barrierefreiheitsgesetz) 17. [Web Crossing: One year of the Barrierefreiheitsgesetz, where online shops must improve](https://www.web-crossing.com/news/detail/ein-jahr-barrierefreiheitsgesetz-wo-onlineshops-und-websites-jetzt-nachbessern-muessen/) ## Frequently asked questions Does the European Accessibility Act apply to B2B online shops? Not directly. BFSG in Germany and BaFG in Austria cover e-commerce services provided to consumers, meaning natural persons buying mainly for non-business purposes. A shop that is demonstrably limited to business customers is generally outside the law. If consumers can also start or conclude a contract, for example through open registration or guest checkout, the shop can fall in scope. What is the microenterprise exemption under BFSG? A microenterprise has fewer than ten employees and either at most 2 million euros annual turnover or at most 2 million euros balance sheet total. Such companies are exempt from the accessibility duty for services, which includes running an online shop. The exemption does not apply to products, such as hardware, that they place on the market. What are the fines for an inaccessible online shop in Germany and Austria? Under BFSG section 37, offering a service in breach of section 14, which covers both the accessibility requirements and the information duty, can be fined up to 100,000 euros. Other breaches, such as failing to give the authority information, can be fined up to 10,000 euros. In Austria the Sozialministeriumservice can impose administrative fines of up to 80,000 euros, with lower limits for smaller companies. Authorities usually start with a correction request before escalating. Which standard must an online shop meet, WCAG 2.1 or 2.2? Today the harmonised reference is EN 301 549 version 3.2.1, which points to WCAG 2.1 levels A and AA. Version 4.1.1, published in September 2026, moves to WCAG 2.2 but only gives a presumption of conformity once the European Commission cites it in the Official Journal. I would build to WCAG 2.2 AA now. Is an accessibility overlay or widget enough for BFSG? I would not rely on one. The law asks that the service is findable, accessible and usable by people with disabilities without special difficulty, and the checkable reference is EN 301 549. That is about the underlying markup, focus handling and content, which a script layered on top cannot reliably repair in configurators, filters and checkout. How do I test a shop for Barrierefreiheit before an audit? Run axe in CI on the key templates, then test the critical journeys by hand: keyboard only, a screen reader such as NVDA or VoiceOver, 200 percent zoom and a narrow viewport. Automated tools cover only part of WCAG, so manual testing of search, configurator, cart and checkout is what actually shows whether a customer can finish an order. Written by Balázs Csorba Senior fullstack & AI engineer in Styria, Austria – 10+ years of Vue, Nuxt, Node.js and PHP, now building tooling for AI agents. [B2B e-commerce & PIM →](https://balazscsorba.com/expertise/b2b-ecommerce-developer)[About me →](https://balazscsorba.com/about) ## More articles - [Headless B2B product configurator: rules, pricing and Nuxt on a commerce API](https://balazscsorba.com/blog/headless-product-configurator-b2b) - [Pimcore ERP delta sync: syncing product data between SAP or Infor, PIM and shop](https://balazscsorba.com/blog/pimcore-erp-delta-sync) - [Core Web Vitals for Nuxt sites and shops: fixing LCP, INP and CLS](https://balazscsorba.com/blog/nuxt-core-web-vitals-performance) - [Charging on EPEX Austria prices: what my Home Assistant app saves](https://balazscsorba.com/blog/home-assistant-ev-charging-energy-manager) ## Sounds like what you need? Tell me about your project or role – I’d love to hear from you. [Book a call](mailto:contact@balazscsorba.com) [Connect on LinkedIn](https://www.linkedin.com/in/balazs-csorba)