Accessible websites: What the BFSG 2025 requires

The BFSG has been in force since 28 June 2025, and breaches can cost up to 100,000 euros. Does this affect your website? For many B2C providers, the answer is yes. This guide explains your obligations and how to comply.

Please note: This article provides an overview of the legal situation and is not a substitute for legal advice. If in doubt, consult a solicitor about your specific circumstances.

What the BFSG requires of websites

Since 28 June 2025, the Accessibility Enhancement Act has required many B2C websites and online shops to comply with accessibility standards; specifically, this has been in force since 29 June 2025, in accordance with the technical standard EN 301 549, which refers to the internationally recognised WCAG 2.1 Level AA guidelines.

The BFSG transposes the European Accessibility Act into German law, thereby establishing, for the first time, a binding obligation – enforceable by fines – regarding digital accessibility for private companies, and not just for public bodies, as had previously been the case. You can find the full text of the Act at bfsg-gesetz.de, a clear overview is provided by the Federal Government Accessibility Portal.

The European origin of the regulation is no coincidence. The European Accessibility Act was adopted as early as 2019, and Member States were granted a period of several years to transpose it into national law. Germany has utilised this period through the BFSG, whilst other EU countries have enacted comparable national laws, some of which have already come into force. Anyone operating outside Germany should therefore assume that similar requirements now apply, or will soon come into force, across much of the EU, even though the exact details may vary slightly from country to country.

For businesses, this means that a website must no longer be designed to be accessible simply for the sake of customer convenience, but in many cases because it is a legal requirement. This changes the way accessibility is prioritised internally, shifting from a nice-to-have feature to an integral part of every website project.

This shift is also noteworthy because accessibility was long regarded as a purely niche issue for public administrations. Local and central government websites have been required to meet the relevant standards for some time, whilst private companies have largely had free rein. The BFSG puts an end to this dichotomy for large parts of the business sector, thereby extending an obligation – one that many companies were previously only familiar with in the context of public administration – directly to their own online shops or customer platforms.

To many decision-makers, this initially feels like yet another compliance issue that has to be dealt with grudgingly. But it is worth taking a closer look: Accessible websites benefit not only people with disabilities, but also older users, people with temporary limitations – for example, following an operation – and, ultimately, anyone using a website under poor conditions, such as in bright sunlight on a smartphone screen or with an unstable internet connection. Accessibility is therefore less of a niche requirement and more of a quality improvement that benefits virtually the entire user base.

Who is affected and who is exempt

Micro-enterprises with fewer than 10 employees and an annual turnover of no more than 2 million euros are exempt from this obligation in respect of services; however, most other businesses dealing with consumers are not. The exemption applies specifically to very small businesses, not to small and medium-sized enterprises.

This particularly affects online shops, banking services, e-books, websites for passenger transport and many other digital services directly aimed at consumers. Purely B2B websites with no consumer-facing business tend to be less likely to fall under these strict requirements, but should keep an eye on developments as the interpretation is becoming increasingly strict in practice. Anyone unsure whether their own business model is affected can find an initial assessment at the Federal Agency for Accessibility.

It is also important to note that the exemption for micro-enterprises does not automatically apply to all products. It relates to specific services as defined by the Act. Existing websites that undergo a fundamental overhaul after the cut-off date will generally be subject to the new requirements, even if the business itself might fall below the exemption threshold, provided that the website constitutes a product rather than a purely service-based offering. In case of doubt, it is worth seeking legal advice on your specific circumstances.

Another point that is often overlooked in practice is that, even if a company itself is not directly obliged to do so, many larger clients and platforms now require their service providers and suppliers to provide accessible digital services. Accessibility is therefore increasingly becoming a competitive factor even in areas where it is not yet a legal requirement.

The question of scope also warrants closer examination. The obligation applies not only to traditional websites but, in many cases, also extends to mobile applications, customer accounts and digital ordering processes, provided these are accessible to consumers. So, anyone who only checks their own website but overlooks the associated app or the checkout process of an external payment provider may not be covering the entire relevant customer journey.

The four principles of WCAG 2.1 AA explained

Perceptible, operable, understandable and robust: these are the four fundamental principles on which every accessible website is based. Each principle covers a distinct aspect of the user experience.

‘Perceivable’ means that content is accessible to different senses, for example through alternative text for images or sufficient colour contrast for people with visual impairments. ‘Operable’ means that every function can be used without a mouse, for example entirely via the keyboard. ‘Understandable’ means that the language and structure are clear, without unnecessarily complicated phrasing or confusing navigation. ‘Robust’ means that content works reliably with a range of technologies, such as screen readers or other assistive technologies.

The technical basis for these four principles is provided by EN 301 549, which, according to Federal Agency for Accessibility on Norms and Standards in its ninth section, it refers directly to WCAG Levels A and AA. The WCAG guidelines were originally developed by the World Wide Web Consortium, or W3C for short, which has been continuously refining them for many years through its Web Accessibility Initiative.

When it comes to practical work, it is worth treating the four principles not as abstract theory, but by assigning one or two specific questions to each principle. For perceptibility, one might ask whether every image has a meaningful alternative text and whether colour is ever the only way to convey information. For operability, one might ask whether it is possible to navigate the entire page using only the Tab key. For comprehensibility, one might ask whether error messages in forms explain specifically what needs to be done, rather than simply reporting ‘invalid input’. For robustness, one might ask whether the page can be read aloud effectively at all using a current screen reader.

Step by step towards an accessible website

Accessibility is achieved through sufficient colour contrast, full keyboard accessibility, meaningful alternative text, a clear content structure and regular testing with real users. These five building blocks can be implemented step by step, regardless of the size of the organisation.

With regard to colour contrast, a ratio of at least 4.5:1 between the text and background colours is considered a rough guideline for standard body text. As regards keyboard accessibility, every interactive area – from menus to form fields – should be accessible without a mouse and clearly identifiable when in focus. When it comes to alternative text, it is not simply the presence of text that counts, but its quality; alternative text should describe what is relevant to the image’s function, rather than merely repeating the file name.

A good example of how this works in practice is Zendesk’s well-designed contact form.

Every field there is clearly labelled, not just with placeholder text that disappears when the form is filled in, and the colour contrast between the text and the background is high enough to ensure it remains easily legible even for people with impaired vision. It is precisely these two criteria – visible labelling and sufficient contrast – that are specific WCAG requirements which can be directly applied to any form. Accessibility is not a one-off project, but must remain an integral part of every website’s ongoing development; otherwise, it will deteriorate with every new feature added. A one-off audit is therefore not sufficient.

It makes sense to firmly embed accessibility criteria within your own development process, for example as a standard checkpoint before every launch of new pages or features. Anyone who already carries out regular UX audits should include accessibility as a separate area of assessment within these audits, rather than treating it as a separate issue. In this way, it remains part of ongoing quality assurance rather than a project that is forgotten once it is completed.

Clarity is also important from an organisational perspective: it should be just as clear who is responsible for accessibility within the company as it is for data protection or security. Experience shows that, without clearly defined responsibilities, the issue quickly falls off the list of priorities as soon as the initial pressure to implement it eases, even though the legal obligation remains in place.

One final practical point concerns new content and campaigns. Marketing teams, in particular, frequently produce new landing pages or campaign pages independently, often outside the regular development process, for example using quick landing page builders. If accessibility is only embedded within the core development team but not within these faster content workflows, this creates blind spots precisely in those areas – which, in the event of a serious incident, would still fall under the scope of the BFSG. A short, easy-to-understand checklist for everyone who publishes content helps to mitigate this risk without having to route every single piece of content through the development team.

Ultimately, such a system pays off for two reasons. It protects against fines by reliably fulfilling the legal obligation, whilst at the same time improving the actual usability of one’s own website for everyone, not just for the target group that the law was originally intended to protect.

When it comes to practical implementation, we help companies to Making websites accessible and at the same time to design accessible user experiences. We also demonstrate how accessibility can be specifically integrated into an existing testing process in the article on this topic, how accessibility can be assessed in a UX audit.

Every implementation must be concluded with a test that goes beyond automated tools. Automated testing tools reliably identify some issues, such as missing alternative text or insufficient contrast. Other issues, such as a confusing tab order or unclear error messages in forms, can only be reliably identified through proper testing using a keyboard or a screen reader.

The structural organisation of a page’s content also deserves special attention. Headings should reflect a logical hierarchy – from a single H1 per page to clearly subordinate H2 and H3 headings – rather than being chosen solely for visual effect. For screen reader users, this hierarchy is often the only way to gain a quick overview of a page’s structure, much as sighted users skim a page with their eyes. If this clear structure is missing, a page that is otherwise good in terms of content becomes effectively unusable for part of the target audience.

One practical issue that is often underestimated concerns forms, as they are particularly likely to cause users to abandon the process when accessibility is lacking. Mandatory fields should be identified as such not only by colour but also by text, and error messages should appear directly next to the relevant field, rather than being grouped together at the top of the page. Anyone who tests a form using only a mouse will, as a rule, overlook precisely those problems that, for keyboard or screen reader users, make the difference between a usable and a unusable form.

How to ensure long-term accessibility

Accessibility is not a one-off project; it must remain an integral part of every stage of a website’s development, otherwise it will deteriorate with every new feature added. A one-off audit is therefore not sufficient.

It makes sense to firmly embed accessibility criteria within your own development process, for example as a standard checkpoint before every launch of new pages or features. Anyone who already carries out regular UX audits should include accessibility as a separate area of assessment within those audits, rather than treating it as a standalone issue. This ensures it remains part of ongoing quality assurance rather than a project that is forgotten once it is completed.

Clarity is also important from an organisational perspective: it should be just as clear who is responsible for accessibility within the organisation as it is for data protection or security. Experience shows that, without clearly designated responsibility, the issue quickly slips off the list of priorities as soon as the initial pressure to implement it eases, even though the legal obligation remains in force.

One final practical point concerns new content and campaigns. Marketing teams, in particular, frequently produce new landing pages or campaign pages independently, often outside the regular development process, for example using quick landing page builders. If accessibility is only embedded within the core development team but not within these faster content workflows, this creates blind spots precisely in those areas, which would still fall under the scope of the BFSG in the event of a serious incident. A short, easy-to-understand checklist for everyone who publishes content helps to mitigate this risk without having to route every single piece of content through the development team.

Ultimately, such a system pays off for two reasons. It protects against fines by reliably fulfilling the legal obligation, whilst at the same time improving the actual usability of one’s own website for everyone, not just the target group that the law was originally intended to protect.

When it comes to practical implementation, we help companies to Making websites accessible and at the same time to design accessible user experiences. We also demonstrate how accessibility can be specifically integrated into an existing testing process in the article on this subject, how accessibility can be assessed in a UX audit.