Accessible websites: BFSG requirements, testing, implementation

The most dangerous situation for a website is a green score in the accessibility test. It feels like a mere formality and proves almost nothing.

The W3C, which publishes the Web Content Accessibility Guidelines, puts it this way: Audit tools cannot determine accessibility, they can only assist. And market surveillance carries out checks differently to any tool. In accordance with Annex 1 of the BFSG, it goes through all the steps of a process in the order a typical user would, evaluates forms, error messages and feedback, and tests using assistive technologies such as a screen reader.

Automated tests are therefore not worthless. They are the quickest way to get started and identify errors that can be measured automatically. However, only a person who goes through your checkout process using a keyboard, zoom and a screen reader can determine whether the requirement has been met. This guide explains who the BFSG applies to, what ‘accessible’ means in technical terms, how you can test it yourself in ten minutes, what should be included in the accessibility statement, and how implementation works.

Accessible website: Who is subject to the BFSG

The Accessibility Enhancement Act (BFSG) has been in force since 28 June 2025 and transposes the European Accessibility Act (EAA) into German law. For the first time, it imposes obligations on private companies. In addition to telecommunications, banking services, e-books and passenger transport, Section 1(3) of the BFSG specifies a category that applies to almost every website where contracts are concluded: ‘services in electronic commerce’.

The definition in Section 2(26) of the BFSG is the linchpin. This refers to services provided via websites and apps “in response to an individual request from a consumer with a view to concluding a consumer contract”. It sounds abstract.

The Federal Ministry of Labour explains this in its guidelines on the BFSG: a hairdressing salon with more than ten employees and an annual turnover of over 2 million euros – in other words, not a micro-enterprise – allows appointments to be booked on its website and sells hair care products. It therefore falls within the scope of the regulations. The entire website, including the checkout process, must be accessible, not just the booking form. The same business with four employees and a turnover of 1 million euros, on the other hand, would be exempt.

B2B shops and purely corporate websites

The law applies to consumers, i.e. natural persons who make purchases predominantly for private purposes (Section 2(16) of the BFSG). An online shop that demonstrably sells only to businesses does not meet the definition according to the wording.

The crux of the matter is proof. If private individuals can register and place orders, then the shop is, in fact, entering into consumer contracts. The situation is similar for a website intended solely for businesses: a site that merely provides information and does not offer the conclusion of a contract falls outside the definition. Grey areas, such as an enquiry form that later becomes a quotation, are not expressly regulated by the law. In such cases, it is worth seeking a brief legal assessment before relying on the assumption that you are not covered.

My position on new builds is nevertheless clear: plan for accessibility even where it is not mandatory. In new builds, it is embedded in the components and the design system, and this is the most cost-effective stage you’ll ever have.

Exception for micro-enterprises

Micro-enterprises that provide services are exempt from the accessibility requirements (Section 3(3) of the BFSG). According to Section 2(17) of the BFSG, a micro-enterprise is defined as an enterprise that employs fewer than ten people and has either an annual turnover of no more than 2 million euros or an annual balance sheet total of no more than 2 million euros.

The Federal State Market Surveillance Authority (MLBF) explains on its page for businesses how this is calculated. Employees are counted in annual work units; part-time staff are counted on a pro rata basis; trainees are not counted at all. A one-off instance of exceeding or falling short of the threshold does not change the classification; only two consecutive financial years do. In the case of shareholdings and affiliated companies, their figures may be included.

The exemption applies only to services. Anyone dealing with products as defined by the BFSG, such as hardware or e-book readers, is not exempt, even if they are a micro-enterprise.

Old content and transition periods

Section 1(4) of the BFSG excludes certain content. This includes recorded video and audio files, as well as files from office applications published before 28 June 2025, as well as third-party content that you neither fund, develop nor control, and archives that have not been updated since then.

There is no transition period for the website itself. Section 38 of the BFSG only permits the continued use of products that you were already using for the service prior to the cut-off date until 27 June 2030. Contracts concluded before 28 June 2025 may continue unchanged until their expiry, but no later than that same date.

Web accessibility: What WCAG and EN 301 549 require

The Act defines accessibility in a single sentence. Services are accessible if people with disabilities can “in the usual manner, without undue difficulty and, in principle, without assistance from others” (§ 3(1) BFSG).

The details are set out in the BFSG Ordinance. Section 12 of the BFSGV requires that websites, online applications and apps be designed to be “perceptible, operable, understandable and robust”. For online retail, Section 19 of the BFSGV stipulates that identification, login, security and payment functions must fulfil these same four characteristics. You must also provide information on the accessibility of the products on offer, insofar as this is supplied by the responsible economic operator, such as the manufacturer or importer.

Digital accessibility in four principles

The four terms originate from the WCAG (Web Content Accessibility Guidelines), the international standard for digital accessibility. Translated into everyday language:

• Perceivable: All information can be accessed even without sight or hearing, for example via alt text for images and subtitles for videos.
• Operable: Everything works using the keyboard, clickable areas are large enough, and no one is kicked out of a form due to a time limit.
• Understandable: Language, navigation and error messages are clear. Forms state what they expect.
• Robust: The code is so cleanly marked up that assistive technologies such as a screen reader can recognise the name, role and state of each element.

WCAG 2.1, WCAG 2.2 and EN 301 549

From a legal perspective, the path is via harmonised standards. Anyone who complies with a standard whose reference is published in the Official Journal of the EU is presumed to meet the requirements (Section 4 of the BFSG). The relevant standard is EN 301 549. Version V3.2.1, as listed in the Official Journal, refers to WCAG 2.1 at Levels A and AA. However, it was listed for the websites of public bodies, not for the EAA.

In September 2026, ETSI published the new version V4.1.1. It adopts WCAG 2.2 and, for the first time, explicitly assigns its requirements to the EAA. It will only trigger a presumption of conformity under Section 4 of the BFSG once its reference has been published in the Official Journal. As of mid-October 2026, this is not yet the case. In fact, no version of the standard has been listed in the Official Journal for the EAA so far.

My recommendation is clear: build and test against WCAG 2.2 Level AA. According to the W3C, content that complies with WCAG 2.2 also complies with WCAG 2.1. This ensures you meet current standards and are prepared for the new standard.

WCAG 2.2 introduces six new criteria for Levels A and AA. Three of these are particularly noticeable in everyday use. Click targets must be at least 24 × 24 CSS pixels in size or have sufficient spacing between them (2.5.8). An element with keyboard focus must not be completely obscured by its own content, such as sticky headers or cookie banners (2.4.11).

The third concerns logins: a login must not impose a cognitive test, such as a puzzle or a password that must be memorised, without providing an alternative or assistance, such as allowing the password to be pasted from a password manager (3.3.8). An old criterion has been removed: 4.1.1 Parsing.

In short: The law requires “perceivable, operable, understandable, robust”; the standard translates this into WCAG criteria, and WCAG 2.2 AA is the target that remains valid both today and following the change in standards.

Testing website accessibility: a self-test in ten minutes

Before you spend money on an audit, get an honest picture of the situation in ten minutes. The self-test has two parts: an automated assessment and a few manual checks that no tool can replace.

Step 1: Automated assessment

Start with the free BFSG Check. It opens your homepage and another page from your sitemap.It runs the XML in a real browser, checks both pages against WCAG 2.1 and 2.2 levels A and AA using the open-source axe-core library, and takes no more than 60 seconds to do so. It also checks whether your homepage links to accessibility information, whether there is a way to contact you, and whether the cookie banner can be accessed using the keyboard.

A score of 100 simply means that no automatically detectable violations were found on these two pages. The W3C explains why: many checks cannot be automated and require human judgement.

Step 2: Manual check

For the manual check, all you need is your browser and a screen reader. VoiceOver is built into macOS and iOS; on Windows, there is NVDA is available free of charge. The following checks are based on the W3C’s Easy Checks.

Which pages you should check

Don’t just test the home page. Annex 1 of the BFSG specifies which pages the authority must include in its sample, including: the home page, login page, sitemap, contact, help pages and pages containing legal information. In addition, there must be at least one page per service, including the search function, the page containing accessibility information, and randomly selected pages amounting to at least ten per cent.

If any of these pages contains a step in a process, the authority checks the entire process. For an online shop, this means: from the product, through the shopping basket and customer account, to payment.

The MLBF selects its random samples based precisely on this list (Section 28(2) of the BFSG). According to its Market Surveillance Strategy for Services, it also relies on automated preliminary checks for web-based services in order to cover a wide range of offerings. It is therefore quite possible that your website will first be flagged by an automated system.

Accessibility Statement: What companies must publish

It’s worth taking a closer look here, as even the search term is misleading. The ‘accessibility statement’ stems from EU Directive 2016/2102 and applies to public bodies. For the federal government, Section 12b of the BGG and Section 7 of the BITV 2.0 stipulate what must be included: which content is not accessible and why, a feedback channel, a reference to the conciliation procedure, and an update at least once a year.

Private companies have a different obligation, namely to provide information on accessibility in accordance with Annex 3 of the BFSG. The MLBF expressly warns against confusing the two on its corporate website. Annex 3 does not require a list of non-accessible content with justifications. Instead, you must describe how your service operates and how it meets the requirements.

In common parlance, the page is often still referred to as the ‘Accessibility Statement’. This name is not mandatory. A more precise term is ‘Information on Accessibility’.

Sample: How to structure the information according to Appendix 3

Appendix 3 No. 1 of the BFSG lists four elements which must be included in addition to the standard consumer information required under Section 246 of the EGBGB. This structure works well as an outline for a separate page, linked in the footer:

1. General description of the service (point a): What do you offer, to whom and via which channels? Annex 3 requires this to be in an accessible format. Plain language is not mandatory, but I recommend it.
2. Service process (point b): How do search, ordering or booking, registration, payment and customer service work?
3. How the requirements are met (point c): Which standard you apply, for example WCAG 2.2 Level AA; which measures have been implemented, such as keyboard navigation, contrast, alternative text, form assistance and subtitles; and how you test and maintain accessibility.
4. Competent market surveillance authority (point d): the federal states’ market surveillance body for the accessibility of products and services (MLBF AöR) with a link to mlbf-barrierefrei.de.
5. Voluntary, but advisable: a contact channel through which users can report barriers, and the date of the last update.

You may publish the information in the terms and conditions or ‘in another clearly visible manner’, for example on a website, in accordance with the BMAS guidelines. The information must itself be accessible without barriers (Section 14(1)(2) BFSG), and the page forms part of the authority’s audit sample (Annex 1 No. 2). If the information is missing or incomplete, this constitutes a formal non-compliance (Section 30 of the BFSG), even if the website were technically flawless.

The structure ensures that the technical details are complete. You should consult your legal adviser regarding the legal wording.

Making a website accessible: Implementation in five steps

Implementation is an engineering project within a legal framework. It typically takes place in five steps.

1. Clarify which areas are affected. Which processes involve contracts with consumers? Does the exemption for micro-enterprises apply? Which legacy content falls under Section 1(4)? The end result is a list of core processes, for example, search, product page, shopping basket, account, payment and contact. Since 19 June 2026, shops should also add the withdrawal button to this list.

2. Conduct an audit in accordance with Annex 1. Automatically test all templates, then manually check the core processes using a keyboard and screen reader. The result is a list of findings organised by WCAG criteria and severity.

3. Rectify at source. Modern websites assemble each page from reusable components: header, navigation, product card, form field, dialogue box, checkout. A fixed component affects every page that uses it. That is why corrections are made within the theme and the design system rather than page by page. Embedded third-party providers are included: payment functions are explicitly mentioned in Section 19 of the BFSGV, and consent, chat or review widgets are part of the same checkout process.

4. Revise content. Alt text, subtitles, PDF documents and clear error messages are editorial tasks. Any new content can introduce a new barrier, so a brief training session for the editorial team is part of the project.

5. Provide information and ensure long-term compliance. The information set out in Annex 3 is published; accessibility is included in the ‘Definition of Done’; and automated tests run in the CI pipeline with every release. This is not optional: Section 14(3) of the BFSG requires that the requirements be met ‘at all times’. If you identify a deficiency, you must rectify it and inform the MLBF without delay (Section 14(4)).

The exceptions for fundamental changes and disproportionate burdens (Sections 16 and 17 of the BFSG) are not a way out for those in a hurry. You must carry out the assessment yourself, document it, keep the records for five years and inform the authorities. In the case of a disproportionate burden, a reassessment must be carried out at least every five years, and anyone who has received public or private funding from third parties for accessibility cannot invoke this exception at all.

For our web applications, automated testing, manual QA and accessibility checks in accordance with WCAG are an integral part of the development process. Furthermore, accessibility is just one of several obligations that websites and online shops are now subject to. You can find an overview of the BFSG, e-invoicing and the AI Regulation, can be found under Complying with obligations.

Shopware: What to expect in an online shop

For online shops, the BFSG is the key consideration. Shopware has responded to this: With Version 6.7, accessibilityimprovements for the Storefront are enabled by default. In Shopware 6.6, the changes – which include breaking changes – are hidden behind the feature flag ACCESSIBILITY_TWEAKS and must be explicitly enabled.

However, a good foundation does not in itself make for an accessible shop. Barriers arise wherever the standard is deviated from: in your own theme, in experience worlds, in the listing filters and in plugins for payment, reviews, chat or cookie consent. Anyone updating from 6.6 to 6.7 should check their own template customisations against the new Storefront structure.

The ten checkpoints for Shopware 6, with template examples, can be found in our BFSG checklist for Shopware 6. This guide provides the framework, whilst the checklist serves as the to-do list for the shop.

Costs and effort: What to expect

The cost of implementation depends less on the number of pages than on the number of templates and components, the proportion of in-house development and the third-party providers involved. A shop with a standard theme and few customisations is quite different from a bespoke web app with its own design system.

This is offset by the risk. In the event of non-conformities, the MLBF first issues a request for correction; as a second step, it threatens to issue a prohibition; and as a third step, it may prohibit the offer until compliance has been demonstrated (Section 29 of the BFSG).

Anyone offering a service in contravention of Section 14(1) – that is, without meeting the requirements or without providing the information set out in Annex 3 – risks a fine of up to 100,000 euros. For breaches of reporting and information obligations, the fine is up to 10,000 euros (§ 37 BFSG). Consumers and recognised associations may apply to the MLBF to initiate proceedings, which the authority is then obliged to commence (Section 32 BFSG).

Whether competitors can also issue warnings for breaches of the BFSG has not yet been clarified by the courts (as of October 2026).

Conclusion: Where to start tomorrow

Accessibility has been mandatory for online shops and booking processes since June 2025, and it is verifiable. Start with what can be measured: run the BFSG check, carry out the keyboard test on your own checkout page, and check the information against the four mandatory elements as set out in Annex 3.

You’ll then know whether you have a component issue or a content issue. Both can be resolved. It’s the things nobody checks that end up being the most expensive.

Frequently asked questions about accessible websites

Does the BFSG also apply to B2B websites?

According to the wording, no. The Act covers services for consumers, i.e. natural persons acting predominantly in a private capacity. An online shop that sells exclusively to businesses does not enter into consumer contracts. If private individuals are able to register and place orders, this no longer applies. Anyone relying on the fact that they sell only to businesses should restrict access to business customers, both technically and in the terms and conditions.

Must a company website without a shop be accessible?

A purely informational website where no contracts are concluded is not covered by the Act under Section 2(26) of the Federal Accessibility Act (BFSG). As soon as consumers can place orders, make bookings or enter into a contract via the site, the obligation applies to the entire website. The Federal Ministry of Labour cites as an example a hairdressing salon with online appointment booking and product sales, which, with more than ten employees and a turnover of over 2 million euros, is not a micro-enterprise. Micro-enterprises providing services are exempt.

Is an accessibility overlay or a plugin sufficient?

Our position: no. In accordance with Annex 1 of the BFSG, the regulatory authority checks whether people can use your processes with their own assistive technologies, and a screen reader requires properly marked-up HTML in the template to do so. A toolbar can offer additional convenience, but it is no substitute for rectifying the issue in the code.

WCAG 2.1 or WCAG 2.2: Which version applies?

EN 301 549 V3.2.1, as listed in the Official Journal, refers to WCAG 2.1 Level AA. The new version V4.1.1 from September 2026 adopts WCAG 2.2, but its reference in the Official Journal is still pending (as of October 2026). As content that complies with WCAG 2.2 also complies with WCAG 2.1 according to the W3C, WCAG 2.2 Level AA is the sensible target for any implementation from today onwards.

Who checks whether my website is accessible?

The Market Surveillance Authority for the Accessibility of Products and Services (MLBF) in Magdeburg is responsible for this. It carries out checks on a case-by-case basis, for example following requests from consumers or associations, and conducts random spot checks without specific cause. According to its market surveillance strategy, it uses automated preliminary checks for web-based services.

How much does it cost to make a website accessible?

A reliable figure is only possible after looking at your templates and processes. The biggest factor is the number of your own templates and components. The free BFSG Check provides an initial overview in no more than 60 seconds.

How often do I need to check accessibility?

The BFSG does not specify a fixed interval, but requires that the requirements be met ‘at all times’ (Section 14(3) BFSG). In practice, this means: automated tests with every release and a manual check of core processes following major changes to design, check-out or plugins.