BFSG (Accessibility Strengthening Act)

For digital commerce, this specifically means: anyone who runs an online shop for consumers must build it technically so that people with disabilities can use it without assistance from others.

The Act is therefore not an appeal to goodwill but a condition of market access. Anyone who does not meet the requirements is selling a service that is formally not marketable. This is exactly what distinguishes the BFSG from the voluntary accessibility initiatives of the last fifteen years and explains why, since 2025, the topic has been coming up in management meetings and no longer only in front-end tickets.

Who is affected by the BFSG, and who is not

The first question every company asks is whether it is affected. The BFSG does not work with lists of sectors but with a combination of the type of product or service, the target group and the size of the company. An obligation only arises when all three axes come together.

Products and services within the scope

The scope includes, among other things, e-commerce services, i.e. online shops through which goods or services are offered to consumers in Germany. What matters is the sales market, not the company’s registered office: a provider from another EU country that specifically serves German end customers also falls under the Act. The idea of escaping the obligation through a company in another Member State therefore misses the point. The EAA is European law, the BFSG is its German form, and both target the place where the service reaches the consumer.

In practice, this means that the entire purchase path is in focus. Product search, filters, product detail page, shopping basket, checkout, customer account, order confirmation: wherever a consumer initiates or completes a transaction, the requirement applies. Accompanying information such as shipping terms, the cancellation policy or contact options is also part of this chain, because it is part of the service and not mere decoration.

The exception for microenterprises

The BFSG has an exception for microenterprises that is regularly misread in practice. It only applies to services, not to products (Section 3(3) BFSG), and only applies if both criteria are met at the same time (Section 2 no. 17 BFSG):

• fewer than 10 employees and
• an annual turnover of no more than €2 million or an annual balance sheet total of no more than €2 million.

The mistake almost always lies in the little word “and”. A business with 14 employees and €900,000 in turnover is not a microenterprise within the meaning of the Act, because the employee threshold is exceeded. For the financial figures, on the other hand, one of the two values is enough: a shop with six employees and €3.5 million in turnover still falls under the exception if its annual balance sheet total is no more than €2 million. This is particularly relevant in fast-growing e-commerce, because small teams there generate above-average turnover. Anyone who relies on the exception should document this classification and review it regularly. According to the MLBF, the classification only changes if the thresholds are exceeded or undercut in two consecutive financial years; as evidence, it expects documents from at least the last two financial years.

B2B remains outside

Pure B2B business is not covered by the BFSG. The Act protects consumers, not business buyers. A closed dealer portal with a login, in which only businesses place orders, therefore does not fall within the scope.

However, this distinction is less comfortable than it sounds. Many SMEs actually run mixed models: a public shop with consumer prices, and behind it a B2B area with tiered prices and purchase on account. As soon as the open part sells to consumers, that part is covered; the existence of a B2B segment does not change this. Anyone who wants to limit the scope cleanly must actually implement the separation technically and in sales, not just claim it. In practice, a sober inventory pays off here before building legal arguments that your own shop may disprove if in doubt.

The technical standard: WCAG 2.1 Level AA and EN 301 549

The BFSG itself does not contain a checklist of CSS rules. The specific requirements are set out in the ordinance implementing the BFSG: for services, it requires, among other things, that websites and mobile apps are designed to be perceivable, operable, understandable and robust (Section 12 BFSGV). The ordinance does not prescribe a particular standard or WCAG version. In practice, the reference point is the European standard EN 301 549, whose version V3.2.1 adopts the Web Content Accessibility Guidelines version 2.1, conformance level AA, for web pages.

What EN 301 549 does

EN 301 549 is the European framework for the accessibility of information and communication technology. It largely adopts the WCAG success criteria for web content and adds requirements that go beyond classic websites, for example for software, documents and hardware interfaces. For everyday shop operations, the web part is the most relevant, and it can be reduced to a manageable formula: comply with WCAG 2.1 AA, and the core technical requirements are covered.

The advantage of this chain of references is verifiability. Instead of arguing about the interpretation of vague legal terms, each individual success criterion can be tested: does the button contrast reach 4.5:1? Can the filter be operated with the keyboard? Does the product image have a meaningful alternative? These questions have answers, and answers can be documented.

Status of harmonisation

One detail that is important for planning: since August 2021, EN 301 549 in version V3.2.1, which references WCAG 2.1, has been listed in the Official Journal of the EU. However, this listing applies to Directive (EU) 2016/2102 on the accessibility of the websites of public sector bodies, not to the European Accessibility Act. In September 2026, ETSI published version V4.1.1. It is the first version developed under the standardisation request for the EAA, and it aligns the requirements with WCAG 2.2. However, the presumption of conformity under Section 4 BFSG only arises once the reference of a harmonised standard has been published in the Official Journal. How this works for Directive (EU) 2016/2102 is explained by the European Commission on its page on the changes to EN 301 549: new versions of WCAG or EN 301 549 only change the legal obligations once the standard has been updated and referenced in the Official Journal.

For practice, this results in a pragmatic stance: the ordinance implementing the BFSG requires the state of the art to be taken into account and does not itself name a WCAG version (Section 3 BFSGV). In practice, WCAG 2.1 AA is considered the minimum, because EN 301 549 V3.2.1, the version listed so far, is based on it. Anyone building from scratch or refactoring anyway should nevertheless go straight to WCAG 2.2 AA: the newer version is backwards compatible, and anyone who already gets there today will not have to do the work a second time with the next standards update. This is not an expressly stated obligation, but simply the cheaper order.

Penalties, market surveillance and open legal questions

The BFSG is enforced not through consumer lawsuits as the rule, but through state market surveillance. This is a different risk profile from the GDPR or competition law and is therefore often underestimated.

Range of fines under Section 37 BFSG

The real severity lies not in the amount of money but in the procedure under Section 29 BFSG. If a service does not meet the requirements, the market surveillance authority first sets a deadline for correction. If it expires without suitable measures, a second deadline follows with the threat of a prohibition. After that, the authority can order the offering or provision of the service to cease; the order is only lifted once you demonstrate conformity. For a shop whose turnover runs entirely through the purchase path, that is in a different league from a fine. This is precisely why accessibility belongs in management’s risk assessment and not exclusively in the development team’s backlog.

The MLBF as the market surveillance body

The competent body is the Market Surveillance Authority of the German Federal States for the Accessibility of Products and Services (MLBF), a joint institution of all federal states based in Magdeburg. It began its nationwide activities in September 2025; on 29 January 2026, its administrative board adopted the market surveillance strategies for products and services. The MLBF works in two ways: reactively on the basis of reports and complaints, and actively along its market surveillance strategies. For web-based services, it also relies on automated preliminary checks.

Important for an honest risk assessment: no publicly documented individual fines are known so far. If you hear in the market that penalties have already been imposed, ask for the source. This does not mean that nothing is happening. It means that the authority is in a build-up and inspection phase and that complaints, alongside its own priority inspections, are a major trigger. A single user who fails at the checkout with a screen reader and complains can set proceedings in motion.

Risk of warning letters under Section 3a UWG: a question of the individual case

A question that concerns many shop operators: can BFSG infringements be subject to warning letters under competition law via Section 3a of the Act against Unfair Competition (UWG) as a breach of law? Then competitors and associations could take action independently of the authority. Experience shows that this mechanism generates considerably more movement in German e-commerce than any supervision.

Under Section 3a UWG, a person acts unfairly if they violate a statutory provision that is also intended to regulate market conduct in the interest of market participants, and the breach is suited to appreciably harming the interests of consumers, other market participants or competitors. The BFSG does not expressly settle whether the accessibility requirements meet these conditions; in a dispute, the courts decide. Only one statement is serious here: the risk exists as an open flank, and its extent cannot be quantified across the board. Anyone who sells you a blanket answer is selling an opinion as a fact.

What this means for an online shop in concrete terms

Between the text of the law and the shop front end lies a translation task. The requirements sound abstract but affect very concrete components, mostly those that already exist in the standard theme and break during customisation.

An example from everyday shop operations

A manufacturer of personal protective equipment sells via a shop to both businesses and private customers. The filter in the category is an elaborately designed custom element: colour swatches as tiles, sizes as buttons, all via JavaScript. Visually convincing, but not operable with the keyboard, because the tiles are implemented as div elements without focus and without a role. Anyone who cannot use a mouse gets stuck at this point.

Added to this is a second, even more common pattern: error messages in the checkout that are communicated exclusively via red borders. No text, no association with the input field, no announcement for the screen reader. The user learns that the form was not submitted, but not why. Both defects are technically manageable to fix: the filter needs real, focusable controls with a state indication, and the error message needs an associated text. Both reliably occur when accessibility is only checked after the design instead of during it.

From testing to implementation

The usual first reflex, an automated scan of the home page, helps only to a limited extent. Automated tests cover some of the success criteria, but not the larger remainder: keyboard operation, focus order, the meaningfulness of alternative texts and understandability cannot be decided by machine. A realistic testing approach therefore combines three levels: an automated scan across the entire purchase path, a manual keyboard test of the same route, and at least one run with a screen reader.

What this testing and the subsequent implementation look like in a specific shop system, from contrast values in the theme and focus styles to form errors in the checkout, is shown in our BFSG checklist for Shopware 6. This glossary entry answers the questions of applicability, scope and penalties; the checklist answers the question of which steps are needed in the system.

Accessibility as product quality

One last point that gets lost in the pure compliance discussion: almost every measure that the BFSG requires also improves the shop for users without disabilities. Sufficient contrast helps anyone looking at a mobile phone display in sunlight. Clear error messages in the checkout reduce abandonment regardless of who is ordering. Clean HTML with correct semantics is at the same time the basis for search engines and AI systems to understand the page.

Anyone who works through the BFSG purely as a compulsory exercise pays for a project that brings nothing in return. Anyone who takes it as an opportunity to fundamentally check the purchase path for usability gets better conversion and a legally compliant basis for the same budget. The difference lies not in the effort but in the order of the questions.