---
title: "The BFSG in Practice: What Germany’s Accessibility Act Means for Websites and Apps"
url: "https://www.insideuxdesign.com/en/blog/bfsg-in-practice-german-accessibility-act-websites-apps"
language: "en"
description: "What Germany’s Accessibility Strengthening Act (BFSG) means for websites and apps: scope, WCAG requirements, deadlines, fines, and a checklist for teams."
published: "2026-10-12T09:00:00+02:00"
updated: "2026-10-14T09:50:33+02:00"
---

# The BFSG in Practice: What Germany’s Accessibility Act Means for Websites and Apps

Since June 2025, Germany’s BFSG also applies to online stores, banking apps, and booking platforms. Who is affected, what’s technically required, and how your team can get started.

Since June 28, 2025, accessibility is no longer optional for many digital products in Germany. That's the day the Barrierefreiheitsstärkungsgesetz, or BFSG for short, took effect. The name translates roughly to "Accessibility Strengthening Act," and it is Germany's implementation of the European Accessibility Act, EU Directive 2019/882. It no longer applies just to public authorities but to regular businesses: online stores, banks, transportation companies, telecom providers, and e-book providers.

More than a year later, the situation in many teams is still confusing. Some are working through a long list of issues from an audit. Others hope they aren't affected, or they installed an overlay plugin and checked the box.

This article sorts things out from a product perspective: who falls under the law, what's technically required, which exemptions and deadlines exist, how enforcement works – and how your team can get to an accessible product, including the required information, in a structured way. One thing up front: this is a professional overview, not legal advice.

## What the BFSG is actually about

The core is in Section 3: products and services must be accessible, meaning that people with disabilities can find, access, and use them "in the generally customary manner, without particular difficulty, and in principle without outside help." That's the same idea behind [accessibility](https://www.insideuxdesign.com/en/glossar/accessibility) in UX design – only now it's legally binding.

The specific requirements are set out in the accompanying ordinance, the BFSGV. For websites and apps, the key wording there is surprisingly brief: they must be designed to be "perceivable, operable, understandable, and robust in a consistent and appropriate manner." If you've worked with the Web Content Accessibility Guidelines, you'll recognize the four principles right away. What counts is the service as a whole: an accessible product catalog doesn't help much if the checkout can't be operated with a keyboard.

## Who is affected?

The BFSG distinguishes between products and services. For teams building websites and apps, services are what matters most. According to Section 1(3), the law covers the following services provided to consumers after June 28, 2025:

- **Telecommunications services**, such as mobile and internet providers
- **Elements of passenger transport services** by air, bus, rail, and water: websites, apps, electronic tickets, travel information including real-time updates, and interactive self-service terminals. For urban, suburban, and regional transport, only the rules on interactive self-service terminals apply.
- **Consumer banking services**, such as consumer credit, payment services, payment accounts, and e-money
- **E-books** and dedicated software
- **E-commerce services**

The last item has the widest reach. It covers digital services offered through websites and apps and provided at a consumer's individual request with a view to concluding a consumer contract. That includes classic online stores, but depending on how they're set up, also booking portals, ticket sales, or subscription sign-ups inside an app.

What's not covered matters just as much. The Bundesfachstelle Barrierefreiheit, Germany's Federal Accessibility Agency, takes the view that pure B2B offerings shouldn't be affected, and neither should pure showcase websites that only inform or advertise without a contract being concluded online. In practice, though, the lines are blurry: a "B2B store" where any private individual can register without verification is hard to pass off as business-only. When in doubt, get a legal assessment.

On the product side, the law lists computers, smartphones, and tablets along with their operating systems, payment terminals, ATMs, ticket and check-in machines, and e-book readers, among others. Here, obligations apply to manufacturers, importers, and distributors, all the way to CE marking.

## The micro-enterprise exemption

Does this apply to small companies too? That depends on what you offer. Section 3(3) exempts micro-enterprises that offer or provide services from the accessibility requirements. Under Section 2 No. 17, a micro-enterprise is a company 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.

So an online store for handmade ceramics with four employees and 600,000 euros in turnover falls under the exemption. A store with eight employees, 3 million euros in turnover, and a 2.5 million euro balance sheet does not, because it exceeds both financial thresholds. A startup with twelve people isn't a micro-enterprise regardless of turnover.

Keep two points in mind. The exemption only applies to services; a micro-enterprise that manufactures or sells products covered by the law still has obligations for those products, albeit with some relief. And growth changes the picture: once the company crosses the thresholds, the requirements apply. If you're growing, factor accessibility into every redesign instead of paying for an expensive retrofit later. Micro-enterprises can also get free advice from the Federal Accessibility Agency.

## What's technically required: from the BFSGV to WCAG

The BFSGV phrases its requirements in a technology-neutral way. Harmonized standards provide guidance: if you meet such a standard, you're presumed to meet the legal requirements as far as the standard covers them (Section 4 BFSG). The prerequisite is that the standard's reference has been published in the Official Journal of the EU. The BFSGV also requires you to follow the state of the art and obliges the Federal Accessibility Agency to regularly publish the most important standards.

### EN 301 549 and WCAG 2.1 AA

The central technical reference is the European standard EN 301 549. It describes accessibility requirements for information and communication technology, from websites and apps to terminals. The Federal Accessibility Agency currently names version V3.2.1 as the reference. For websites, Clause 9 of the standard points to [WCAG](https://www.insideuxdesign.com/en/glossar/wcag) 2.1, the W3C's Web Content Accessibility Guidelines. In practice, this means the Level A and AA success criteria of WCAG 2.1 are the bar. For native apps, Clause 11 applies these criteria to software. On top of that come requirements beyond WCAG, for example on interoperability with assistive technologies, documentation, and support.

### What's changing right now

EN 301 549 is being revised for the European Accessibility Act. ETSI published version 4.1.1 in September 2026; according to the Federal Accessibility Agency, the updated version references WCAG 2.2. Keep an eye on whether and when it gets listed in the Official Journal of the EU as a harmonized standard under the European Accessibility Act. The pragmatic approach: if you're building something new today, aim for WCAG 2.2 AA right away. The new criteria – minimum target sizes, focus that isn't hidden by sticky elements, alternatives to drag-and-drop, logins without memory tests – are good UX anyway.

### Industry-specific requirements

The BFSGV adds extra obligations for individual industries. In **e-commerce**, information on the accessibility of the products on offer must be provided where the responsible economic operator, such as the manufacturer, supplies it. Identification, authentication, security, and payment functions must also be perceivable, operable, understandable, and robust.

In **banking**, the same applies to identification, authentication, electronic signatures, and payment services. There's also a language requirement: information on how the banking service works must not exceed level B2 of the Common European Framework of Reference for Languages. So a loan calculator can be technically flawless and still fall short if its explanations are written in convoluted legalese. Suddenly the work of a [UX writer](https://www.insideuxdesign.com/en/blog/what-does-a-ux-writer-do) becomes a compliance issue.

Providers of **passenger transport** must, among other things, provide information on the accessibility of vehicles and infrastructure and offer real-time travel information. **E-books** need a navigable structure, compatibility with assistive technologies, and metadata about their accessibility features.

## The information requirement: more than a mandatory page

Beyond accessibility itself, Section 14 BFSG requires service providers to publish information on how their service meets the requirements. People often call this an "accessibility statement"; the law refers to information under Annex 3. It can be part of the terms and conditions or provided "in another clearly perceivable way," usually as a separate page linked in the footer. Annex 3 lists at least these elements, where applicable:

- a general description of the service in an accessible format
- explanations needed to understand how the service is carried out
- a description of how the service meets the accessibility requirements
- the name of the competent market surveillance authority

The information itself must be accessible and remain available for as long as you offer the service. If it's missing or incomplete, the law calls this "formal non-conformity" – a separate checkpoint, regardless of how good the website is technically.

A common mistake is a marketing text along the lines of "Accessibility is close to our hearts." A sober description is more helpful: Which standards were applied? Which areas were tested, and how? Which limitations are known, and when will they be fixed? How do people reach support?

## Transition periods and exemptions

There's no general grace period for existing websites. The transitional provisions in Section 38 are narrower than many people assume:

- Service providers may continue to use **products** covered by the law, such as hardware, until June 27, 2030, if they were already lawfully using them for the service before June 28, 2025.
- **Contracts** concluded before June 28, 2025, may continue unchanged until they expire, but no later than June 27, 2030.
- **Self-service terminals** that were lawfully in use before the deadline may stay in operation until the end of their economic life, but no longer than 15 years after they were first put into use.

So a mobile contract signed in spring 2025 with a 24-month term may continue unchanged until it ends. For new contracts concluded today through the same provider's website or app, this rule doesn't help.

In addition, Section 1(4) exempts certain content: recorded video and audio as well as office files published before June 28, 2025, online maps under certain conditions, third-party content that you neither fund, develop, nor control, and archived content that isn't updated after the deadline. Writing off a payment widget that you deliberately chose and built into your checkout as "third-party content," however, would be a risky assumption.

There are two further exemptions: requirements don't apply where they would require a fundamental alteration of the essential characteristics of the service (Section 16) or impose a disproportionate burden (Section 17). Neither is an easy way out. You have to carry out the assessment yourself based on defined criteria, document it, keep it for five years, and notify the authority. Service providers must repeat the burden assessment at least every five years and also whenever the service changes. If you've received funding to improve accessibility, you can't rely on Section 17 at all.

## How enforcement works – and what violations can cost

Market surveillance is the responsibility of Germany's federal states. They created a joint authority for it: the Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF), the states' market surveillance body for the accessibility of products and services, a public-law institution based in Magdeburg. It's the authority that should appear in your accessibility information.

The authority investigates when it has reason to believe a service doesn't meet the requirements, and it also runs spot checks without a specific cause. Consumers who can't use a service, or can only use it to a limited extent, because of missing accessibility can request that proceedings be opened. Recognized associations can do the same. A conciliation procedure is also available.

### First fix, then sanctions

If the authority finds deficiencies, it first asks the provider to fix them within a reasonable period. If nothing happens, a second request follows, along with the threat of prohibiting the service. If that doesn't work either, the authority can order the service to be discontinued until conformity is demonstrated.

Section 37 also provides for fines. Anyone who intentionally or negligently offers a service that doesn't meet the requirements, or lacks the required information, risks up to 100,000 euros. Other violations, such as failing to provide information to the authority or providing incorrect information, can cost up to 10,000 euros. These are maximum amounts; the actual amount depends on the circumstances of each case.

### What the review focuses on

Annex 1 of the BFSG is particularly revealing, because it describes how the authority reviews websites and apps. The sample includes the home page, login, sitemap, contact, help and legal pages, the page with the accessibility information, at least one page for each type of service offered including search, and additional randomly selected pages. If a page contains a step in a process, the entire process is reviewed. Forms, dialogs, error messages, and behavior with different assistive technologies are explicitly assessed. So polishing just the home page won't get you far.

## Common pitfalls in audits

When products are tested against WCAG 2.1 AA, the same problems keep coming up – mostly not edge cases, but basics that get lost in day-to-day work.

**Forms without real labels.** Placeholder text is not a label. As soon as someone starts typing, the hint disappears, and a [screen reader](https://www.insideuxdesign.com/en/glossar/screen-reader) might just announce "edit text." Error messages that only outline a field in red without saying what's wrong are just as problematic.

**Keyboard traps and invisible focus.** If cookie banners, modals, or mega menus don't manage focus properly, or the focus outline was removed in CSS, the checkout is unreachable for people who don't use a mouse.

**Third-party components.** Payment forms, chatbots, or appointment booking tools often bring their own barriers. They still show up in the audit because they're part of your process. That's why accessibility belongs in every tender and every vendor contract.

**Contrast and color as the only signal.** Light gray text on white often misses the 4.5:1 contrast ratio that WCAG requires for normal text. And if availability is shown only by a green or red dot, people with color vision deficiencies have a problem.

**Overlays as a shortcut.** Scripts that display an accessibility toolbar don't fix the root causes in the code. Missing labels or keyboard traps remain.

**The forgotten app.** Many teams test the website thoroughly and overlook the native app. Classics include missing support for dynamic text sizes, unlabeled icon buttons for VoiceOver and TalkBack, and touch targets that are too small. PDFs such as invoices or contract documents are often part of the process too, and they're easily forgotten.

## From zero to accessibility information: step by step

How do you get started if your team hasn't dealt much with accessibility so far? The following process follows the logic of the law and the authority's review.

### 1. Clarify whether you're affected

Is your offering aimed at consumers? Is a contract concluded online? Is your company a micro-enterprise? Write down the result, even if it's "not affected."

### 2. Inventory your user journeys

List the core flows the way the authority would review them: sign-up, login, search, product page, cart, checkout, payment, contact, customer account, cancellation. Include all channels as well as all third-party components and documents in these flows.

### 3. Assess the current state

Combine automated tests with manual reviews. Tools quickly find missing alt text or contrast issues but only catch some of the errors. Keyboard tests, screen reader walkthroughs, and a systematic review against the WCAG criteria are essential. The article [Accessibility Testing: Tools and Methods for UX Designers](https://www.insideuxdesign.com/en/blog/accessibility-testing-tools-and-methods-for-ux-designers) shows which tools are worth considering. If possible, add tests with people who use assistive technologies themselves.

### 4. Prioritize issues

An audit can easily produce a hundred findings or more. Prioritize along two questions: does the issue block a core process? And how many pages does it affect? At the top is anything that stops people from concluding or managing a contract: an order button that can't be reached by keyboard, a CAPTCHA without an alternative, a login that only works via drag-and-drop. Next come issues in shared components. That's where you get the most leverage, because fixing the button component once fixes the problem everywhere. Cosmetic issues on rarely visited pages come last.

### 5. Fix and safeguard

Plan fixes in small packages within your regular sprints instead of starting a big side project. Preventing new issues matters just as much: accessibility criteria in the definition of done, automated checks in the CI pipeline, accessibility as a standing item in design reviews.

### 6. Create the Annex 3 information

Now you can write the required information: What is the service, and how does it work? Which standards were applied, how was it tested, and which limitations are known? Which authority is responsible? Add a way to send feedback and link the page where people can find it, for example in the footer next to the legal notice and privacy policy.

### 7. Document and keep it up to date

Section 14 requires you to meet the requirements on an ongoing basis and to take changes to your service, the requirements, and the standards into account. Keep test reports and decisions on record, and review the information with every major change, and at least once a year.

## Three real-world scenarios

### The small online store

A bike accessories store with 15 employees sells to private customers through a standard e-commerce platform. With more than nine employees, it isn't a micro-enterprise and falls under the BFSG. The biggest lever is the theme and plugins: a theme with clean headings, visible focus, and labeled forms saves a lot of work. The usual trouble spots are variant selection, filters, cart pop-ups, and the payment module. If manufacturers supply information on the accessibility of their products, the store must make it available.

### The booking platform

A long-distance bus company sells tickets through its own website and app. Two areas apply here: e-commerce and passenger transport. Besides an accessible booking flow, it needs accessible information on the accessibility of its vehicles and stops, plus real-time updates on delays. Typical problem areas are date pickers that only work with a mouse, seat maps as plain images, reservation timers that can't be extended, and mobile tickets whose QR code view gives screen readers no details about the trip or validity.

### The banking app

A direct bank offers accounts, cards, and loans through an app. Identification and authentication are critical here: video identification, approvals via push notification, biometrics with a fallback, time limits at login. The BFSGV's functional performance criteria point the way: if a service relies on vision, hearing, or voice input, there should be at least one mode of operation that works without vision, without hearing, or without voice input, respectively. Add the B2 language requirement for explanations of features and terms. A good first step: walk through account opening, login, transfers, and card blocking with a screen reader and greatly enlarged system text.

## Starter checklist for product teams

- Check whether you're affected (consumer offering, online contracts, company size) and document the result.
- List core journeys in your website and app, including third-party components and documents.
- Test against WCAG 2.1 AA, automated and manual; for new builds, aim for WCAG 2.2 AA right away.
- Run through core processes with keyboard and screen reader all the way to confirmation.
- Prioritize findings by whether they block core processes and how far they reach; bundle fixes in components.
- Check the BFSGV's industry-specific requirements, such as payment, authentication, or language level.
- Add accessibility to tenders, vendor contracts, and your definition of done.
- Publish the Annex 3 information in an accessible way, including the competent market surveillance authority.
- Set up a feedback channel for accessibility issues and prepare your support team.
- Schedule a fixed date for regular reviews.

## Conclusion

The BFSG turns a UX quality attribute into a legal obligation. For online stores, banks, transportation and telecom companies, the question is no longer whether to become accessible, but how quickly and how thoroughly. Technically, this isn't new territory: if you take WCAG 2.1 AA seriously, make core processes accessible end to end, and communicate transparently about it, you're on the right track.

The most important step is to treat accessibility as a fixed part of your product process rather than a one-off project. That reduces legal risk and makes your product easier to use for everyone – for people with disabilities, for older people, and for anyone standing on a crowded train with their phone in one hand.

*Note: This article provides professional guidance and is not legal advice. The current versions of the BFSG and BFSGV are what count.*

## Sources

- [Barrierefreiheitsstärkungsgesetz (BFSG) on gesetze-im-internet.de (German)](https://www.gesetze-im-internet.de/bfsg/)
- [Ordinance on the BFSG (BFSGV) on gesetze-im-internet.de (German)](https://www.gesetze-im-internet.de/bfsgv/)
- [Federal Accessibility Agency: Standards for the BFSG (German)](https://www.bundesfachstelle-barrierefreiheit.de/DE/Barrierefreiheitsstaerkungsgesetz/Normen-und-Standards/normen-und-standards_node)
- [Market surveillance authority of the German states for accessibility (MLBF, German)](https://www.mlbf-barrierefrei.de/)