BFSG website requirements: who must comply, what to fix, and how to get there

What are the BFSG website requirements in plain terms?

The BFSG website requirements are the accessibility duties that the Barrierefreiheitsstärkungsgesetz places on the digital side of consumer services: the website, the app and the booking or buying process must work for people who are blind, have low vision, cannot use a mouse, are deaf or have cognitive impairments. The law is Germany's implementation of the European Accessibility Act, and the detailed rules sit in the accompanying regulation, the BFSGV.

The law itself does not list WCAG success criteria. It describes outcomes: information must be perceivable through more than one sense, controls must be operable by keyboard and assistive technology, content must be understandable, and the code must be compatible with assistive tools. The Bundesfachstelle Barrierefreiheit points to the harmonised standard EN 301 549 V3.2.1 as the practical way to show conformity, and for web content that standard in turn refers to WCAG 2.1 Level AA.

So when a developer talks about the BFSG website requirements, they mean in practice: pass the 50 WCAG 2.1 success criteria at levels A and AA on every page and state of your consumer journey, apply the extra EN 301 549 clauses that concern software and apps, and publish the accessibility information the law asks for. That is concrete enough to test, quote and fix.

Does the BFSG apply to my website or online shop?

It applies if consumers can conclude a contract with you through your website or app. Section 1 of the BFSG lists the covered services: e-commerce services, consumer banking, telecommunications, elements of passenger transport services such as websites, apps and electronic tickets, and e-books. For most readers of this page the deciding category is "Dienstleistungen im elektronischen Geschäftsverkehr", which means consumer contracts concluded online.

That wording catches more businesses than people expect. An online shop is the obvious case, but so is a gym that sells memberships online, a hotel with its own booking engine, a language school that takes course registrations with payment, or a ticketing page for events. A site that only presents information and a phone number, with no way to conclude a contract, usually falls outside the BFSG website requirements, although accessibility still helps its users and search visibility.

Pure B2B shops, where only business customers can register and buy, are generally outside the scope because the law protects consumers. Be careful here: if your "B2B" shop accepts anyone who types a company name, a regulator may see it differently. Your lawyer should confirm the classification; we can show them how your registration and checkout actually behave.

• Covered in most cases: B2C online shops, booking engines with online contract conclusion, consumer banking portals and apps, ticketing for passenger transport, e-book stores.
• Usually not covered: information-only company sites, B2B-only portals with verified business customers, internal tools.
• Grey zones worth a legal check: mixed B2B/B2C shops, marketplaces, subscription sign-ups on third-party platforms.

Is my small business exempt from the BFSG website requirements?

Only if you provide services and qualify as a microenterprise: fewer than 10 employees and an annual turnover or annual balance sheet total of no more than 2 million euros. Both conditions must be met, and the exemption in section 3 of the BFSG covers services only. A small manufacturer placing covered products on the market does not get the same relief.

Many small online shops fall inside this exemption, and it is worth checking honestly before spending money. Count staff the way the law does, look at last year's figures, and keep a note of the calculation. If you grow past the threshold, the BFSG website requirements apply from then on, so a shop that plans to grow should not build itself into a corner.

There is a practical reason to build accessibly even when exempt. Your shop platform, payment provider and marketplace partners are moving towards accessible defaults anyway, and fixing a theme later costs more than choosing a clean one now. Accessible sites also tend to perform better with search engines because the same structure that helps a screen reader helps a crawler. Our view: if you are exempt, treat accessibility as a quality goal rather than a legal project, and skip the formal documentation.

BFSG website requirements mapped to WCAG 2.1 AA and EN 301 549

The fastest way to understand the BFSG website requirements is to read them through WCAG's four principles. Each principle turns into a handful of checks that catch most real barriers on German shop and booking sites.

EN 301 549 adds clauses beyond WCAG for software and mobile apps, such as respecting the platform's accessibility settings and text size. For a web shop, WCAG 2.1 AA covers the bulk of the work.

BFSG website requirements for online shops: the checkout path

For a shop, the BFSG website requirements matter most along the path that ends in a contract: finding a product, choosing a variant, adding it to the basket, entering an address, paying and receiving the confirmation. A barrier anywhere on that path can stop a disabled customer from buying at all, which is exactly what the law is trying to prevent.

The usual problems we find are predictable. Filters built as clickable divs cannot be reached by keyboard. Size and colour swatches show only a colour, with no text name. Cart drawers open without moving focus and cannot be closed with Escape. Address forms use placeholder text instead of labels, so the hint disappears as soon as someone types. Payment steps load a provider's embedded form that the shop cannot change, and consent banners trap keyboard focus before the page can be used at all.

We fix these at component level. A filter becomes a real button group with checkbox semantics, swatches get visible or programmatic names, the drawer becomes a proper dialog with focus management, and every field gets a persistent label and a clear error message. For third-party payment widgets we test what the provider delivers and, where it fails, document it and choose the provider's accessible variant if one exists.

• Search and filters: operable by keyboard, results count announced.
• Product page: image alternatives, variant names, price and unit price readable.
• Basket: quantity controls labelled, updates announced, remove buttons named.
• Checkout: labels, autocomplete attributes, error text, order review before the final button.
• Confirmation: order summary readable, email confirmation in accessible HTML.

Do the BFSG requirements cover apps and booking systems too?

Yes. The BFSG treats the service as a whole, so a consumer app that sells tickets, books appointments or runs a bank account must meet the same accessibility goals as the website. EN 301 549 has a separate chapter for software, which applies to native and cross-platform apps.

In Flutter we check the Semantics tree, text scaling with the system font size, contrast in both light and dark themes and the order in which TalkBack and VoiceOver read the screen. In React Native we set accessibility labels, roles and states on custom touchables and make sure modal sheets trap focus correctly. Touch targets should be comfortably large; Apple's Human Interface Guidelines recommend at least 44 by 44 points.

Booking systems bring their own traps. Date pickers are often inaccessible grids with no keyboard support, time slots are shown only by colour, and a timer releases the slot without warning. A compliant booking flow offers a typed date input or an accessible calendar, names each slot in text, and warns before a hold expires. If your booking engine is a third-party product, ask the vendor for its own accessibility information; if it cannot provide any, that is a sign to consider a replacement, which we can build as a portal or custom web app.

What must the BFSG accessibility statement contain?

Under section 14 and Annex 3 of the BFSG, a service provider must publish information on how the service meets the accessibility requirements, in accessible form, for as long as the service is offered. Annex 3 lists four elements: a general description of the service, explanations needed to understand how it is carried out, a description of how the service meets the relevant requirements, and the name of the competent market surveillance authority.

The law allows this information to sit in the general terms or be made available in another clearly perceptible way. Most shops publish a dedicated page, often called "Erklärung zur Barrierefreiheit", and link it from the footer next to the Impressum and privacy policy. It should be a normal HTML page, not a PDF, so that it is itself accessible.

We draft the technical part of this statement from our test results: which standard we tested against, which journeys were tested, known remaining issues and the planned fix date, and how users can report a barrier. Your lawyer reviews the text and adds anything legal. We do not copy generic statements from other sites, because a statement that claims full conformity while the checkout fails a keyboard test is worse than none.

• General description of the service in plain language.
• How to use the service, including alternative routes such as phone or email ordering.
• How the requirements are met, with the standard used and any known gaps.
• The competent market surveillance authority and its contact details.
• A contact route for users to report barriers (good practice, and useful evidence).

How is a BFSG website audit carried out?

A proper audit combines tools and people, because automated scanners catch only part of the WCAG issues. We start with a list of templates and journeys, test each one with scanners, then walk through it by keyboard only, at 200% and 400% zoom, and with screen readers: NVDA with Firefox or Chrome on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.

The output is a spreadsheet you can act on. Each finding names the page or component, the WCAG success criterion, the user impact, a screenshot or recording, and the fix. We rank findings by how badly they block a purchase or booking, not by how many times a scanner repeats them. One missing label on a shared form component can generate a thousand scanner errors but needs one fix.

Audits are sampled, not exhaustive. On a shop with 20,000 products, we test representative product types, not every item. That sample is documented, so that you and your lawyer can see what was covered. After fixes, we retest the same sample and record the result, which becomes the evidence base for your accessibility statement. If you want an independent audit by a German certification body afterwards, our documentation shortens that work.

How much does meeting the BFSG website requirements cost?

It depends on template count, platform, third-party code and whether an app is included, so honest quotes vary widely. A 12-template brochure site with a contact form is a small job; a shop with a custom checkout, a configurator and an app is a project. We quote the audit first and the fixes after, so you never pay for guesses.

The biggest cost drivers are easy to spot. Page builders that generate nested div soup take longer to fix than clean themes. Custom JavaScript widgets such as sliders, mega menus and configurators need rebuilding rather than patching. Every third-party script in the checkout (reviews, chat, payment, consent) is a component you may not be able to change. And content matters: thousands of product images without alt text are an editorial task as much as a technical one.

Where rebuilding is cheaper, we say so. A new accessible website starts at US$150, a large SEO site at US$300, and an accessible online shop at US$750. For a wider view of German web budgets, including DSGVO and Impressum line items, see our guide to website development cost in Germany.

In which order should you fix BFSG website requirements issues?

Fix the shared building blocks first, then the checkout, then content. This order gives the largest improvement per hour of work and keeps you from fixing the same issue on 400 pages one by one.

• Global layout: skip link, landmarks, heading hierarchy, page language, visible focus style.
• Navigation: main menu, mega menu and mobile menu operable by keyboard and screen reader.
• Consent banner: reachable, closable, with an equally accessible reject option.
• Checkout and account: labels, errors, autocomplete, order review, confirmation.
• Product and listing templates: variant pickers, filters, image alternatives, unit prices.
• Media and content: captions, alt text for editorial images, readable PDFs or HTML replacements.
• Accessibility statement and feedback route, published once the main fixes are live.

Each step ends with a retest, and each retest result goes into the audit file. Content editors get a one-page guide on alt text, headings and link wording, so that new pages keep meeting the BFSG website requirements after we leave.

Can an accessibility overlay plugin make my site BFSG compliant?

No overlay can guarantee it, because the BFSG website requirements concern how your site is built. Overlay widgets add a toolbar for font size or contrast and try to patch the page with JavaScript at runtime. They cannot reliably invent correct labels for your checkout fields, fix a keyboard trap in a third-party iframe or restructure a heading hierarchy that your theme generates wrongly.

Many screen-reader users already have their own tools and settings; a second layer on top of the page can interfere with them. The European standard measures the page that users receive, and a toolbar does not change failures in the underlying markup. Some overlay providers promise legal protection; read those promises carefully and ask your lawyer what they are worth.

Plugins are different when they fix things at source. A WordPress plugin that adds a skip link to the theme, or a Shopify theme update from the vendor that repairs the cart drawer, changes the real HTML, and we are happy to use them. The rule we apply is simple: if the fix is visible in the page source and passes a screen-reader test, it counts.

Who enforces the BFSG, and what are the risks?

The Länder have set up a joint market surveillance authority for accessibility, the Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen, based in Magdeburg. According to the Bundesfachstelle Barrierefreiheit it became operational in September 2025. For services it checks on a sample basis and in response to complaints, and it can order fixes and, as a last resort, stop a service.

Section 37 of the BFSG sets fines of up to one hundred thousand euros for offering a service that does not meet the requirements, and up to ten thousand euros for other breaches such as missing information. Consumers and recognised associations can also ask the authority to act.

The second risk is civil. German lawyers are still debating whether the BFSG rules count as market conduct rules under competition law, which would let competitors or associations send an Abmahnung. Treat it as a live risk rather than a settled one and ask your own lawyer. From a developer's side, the defence is the same either way: a site that works with a keyboard and a screen reader, a documented audit, and a truthful statement.

BFSG website requirements on Shopify, Shopware, WooCommerce and TYPO3

Every platform can meet the BFSG website requirements, and every platform can fail them. The platform core is rarely the problem; themes, apps and page builders are.

Do accessible websites rank better on Google and in AI search?

Accessibility is not a direct ranking factor, but the work overlaps heavily with what search engines and AI assistants need. Clear heading hierarchies, descriptive link text, text alternatives for images, transcripts for video and semantic HTML make it easier for Google, Bing and AI answer engines to understand and quote your pages.

There is also a performance angle. Removing heavy overlay scripts and bloated sliders improves Core Web Vitals, which Google Search Console reports for your real users. A cleaner DOM loads faster on the mid-range Android phones many customers use.

We handle both at once when we fix templates: accessible markup, structured data for products and FAQs, and fast pages. Nobody can guarantee rankings, and we will not promise any. If your relaunch changes URLs while you fix accessibility, protect your rankings with the steps on our website relaunch SEO page.

How does a German business work with an Indian team on BFSG fixes?

Remotely, in English, with a German-speaking reviewer on your side. India runs 3.5 hours ahead of Germany in summer and 4.5 hours in winter, so the European business day from late morning overlaps with our afternoon and evening. A 10:00 call in Hamburg is 13:30 or 14:30 in India, and fixes pushed in our evening are waiting on your staging site the next morning.

Week one: you give us staging access, a list of key journeys and your platform details. We run the audit and send the findings file, ranked by impact. Week two: we agree priorities and start on global components. You or your editor review any German text we touch, because we write English and do not rewrite German copy ourselves; alt text and error messages in German are supplied or approved by you.

Contracts are in English, the code, theme and app accounts stay yours, and invoices come from India in USD or EUR, paid by Wise or bank wire. We make no site visits and have no office in Germany. Quotes are itemised within about two working days, and nothing is billed before you approve them in writing. See the Germany overview for how other projects run.

Worked example: a small tea shop in Freiburg meets the BFSG website requirements

Here is a hypothetical case to show how the process plays out. A Freiburg tea retailer with 14 staff sells loose tea to consumers through a WooCommerce shop built on a page builder five years ago. It is above the microenterprise threshold, so the BFSG website requirements apply.

The audit covers seven templates: home, category, product, basket, checkout, account and blog article. It finds a mega menu that opens only on hover, product tins shown in colour swatches without names, a cookie banner that traps keyboard focus, placeholder-only checkout fields, and 1,100 product images with file names as alt text. The payment step works with a keyboard but announces nothing on errors.

The team replaces the page-builder header with a block-theme header, rebuilds swatches as labelled radio buttons, swaps the consent tool for one with an accessible reject button, and adds labels, autocomplete and error summaries to checkout. The owner's staff write German alt text in batches using a short guide. After a retest with NVDA, VoiceOver and TalkBack, we draft the technical part of the accessibility statement and the shop's lawyer finalises it. Regression checks then run monthly within maintenance. This is an illustration, not a client story.

BFSG website requirements checklist to keep after launch

Compliance is not a one-off state. Every new banner, plugin and product upload can break it again, so keep a short routine that someone owns.

• Before publishing: headings in order, links that make sense out of context, alt text on new images.
• Before installing an app or plugin: test its widget by keyboard and with a screen reader on staging.
• After theme or platform updates: rerun the key journey tests from the audit file.
• Every quarter: review the accessibility statement and update known issues and dates.
• Every month: read the barrier reports that come in through your feedback route and log fixes.
• Once a year: repeat a sampled audit, especially if the checkout or app changed.

We run these checks for clients on maintenance plans from US$120/mo. If you are unsure whether a new idea, such as an AI chatbot on the shop, will create barriers, read our note on the GDPR compliant AI chatbot build, which covers accessible chat widgets too.