An accessible website: what the BFSG demands of companies — and of whom

Since 28 June 2025 the Barrierefreiheitsstärkungsgesetz — the BFSG, Germany's accessibility strengthening act — has been in force. Since then two opposing misconceptions have been circulating in many companies: “that certainly doesn't affect us” — and “now every website has to be accessible immediately, or fines loom”. Neither is true in that form. A classification of who actually has to act, what the law concretely demands and why accessibility pays off beyond any obligation.

For transparency: this piece appears as an advertisement from the environment of a web agency (in German). It is not legal advice — in case of doubt, the question of whether one's own offering falls under the law belongs in the hands of a lawyer. What a text like this can achieve: making the logic of the law comprehensible and showing where the practical work begins.

First the origin. The BFSG implements a European directive, the European Accessibility Act. The aim is that people with disabilities can use the products and services of everyday digital life on equal terms — from the cash machine through the e-book to the online shop. For websites the decisive point is: what is covered is above all electronically provided services for consumers, first and foremost electronic commerce.

Translated, that means: anyone who initiates or concludes contracts with consumers via their website — runs a shop, has appointments or tickets booked, sells services online — falls with those functions in principle under the law. A purely informational website without such functions, for instance the classic digital business card of a trades business, is by contrast as a rule not directly covered. Nor are purely business-to-business relationships.

The second important boundary: micro-enterprises that provide services are exempt — meaning companies with fewer than ten employees and at most two million euros of annual turnover or annual balance sheet total. A small online shop below these thresholds therefore does not necessarily have to retrofit. But caution with self-classification: the demarcations are less clear-cut in the individual case than they sound, and anyone who grows will at some point also grow into the obligation.

Two further points belong in the picture, so that self-assessment does not turn out too easy. First, the law knows transitional arrangements for certain existing cases — what they extend to in detail and what they do not is a question of the concrete case, on which nobody should rely in blanket terms. Second, the law demands from affected providers not only accessibility itself but also information about how their own service meets the requirements. How both are to be shaped in detail belongs in expert advice; what matters first is the knowledge that these obligations exist at all — anyone who knows them can plan for them instead of running after them.

What does the law demand in substance? In essence it refers to recognised technical standards — in Europe the EN 301 549 standard, which for its part builds on the internationally established Web Content Accessibility Guidelines. Their logic can be summed up in four principles: content must be perceivable, operable, understandable and robust. Behind the abstract words stand very concrete, testable requirements.

Perceivable means, for example: sufficient contrast between text and background, texts that can be enlarged without the layout breaking, and alternative texts for images so that screen-reading software can describe what is to be seen. Anyone who has ever tried to read pale grey type on a white ground in sunlight will sense it: these requirements benefit by no means only people with a recognised disability.

Operable means above all: the entire website has to work without a mouse. Many people with motor or visual impairments navigate by keyboard — for that it must be visible which element currently has the focus, menus must not react exclusively to the mouse pointer, and forms must contain no dead ends. Understandable concerns language and structure: clear labels, comprehensible error messages, consistent navigation. Robust, finally, means clean, standards-compliant code with which assistive technologies can work reliably.

In everyday life one meets the violations in always the same places. The menu saved as an image PDF, out of which no screen-reading software can get a single letter. The video without subtitles. The contact form whose fields carry no labels, so that it stays unclear where the name and where the message belong. The carousel on the home page that jumps onwards before anyone could take in the text. The elegant shade of grey that looked good on the designer's screen and disappears in daylight. None of it is ill will — they are habits that nobody has ever questioned. Precisely for that reason they can also be stopped, as soon as somebody looks.

How seriously is this policed? Responsibility lies with the market surveillance authorities of the federal states; they can oblige providers to make improvements and impose fines. A comprehensive wave of inspections is not to be expected in the short term — in many places the structures for it are themselves only just coming into being. Betting on that would nevertheless be short-sighted: complaints from affected people and associations can set proceedings in motion, and anyone who only retrofits under pressure almost always pays more than with planned implementation.

Which brings us to the practical part — and to an uncomfortable truth: accessibility is hard to “spray on” afterwards. A contrast problem is quickly remedied, an inaccessible navigation structure is not. The economically best moment for accessibility is therefore a relaunch that is due anyway: anyone who builds structure, design and components according to the four principles from the outset pays a manageable surcharge instead of a large rebuild later.

Anyone commissioning a relaunch should therefore write the subject expressly into the assignment instead of tacitly assuming it. Three questions to the agency are enough for a start: to which standard is the build carried out, and how is compliance checked? Is testing done with a keyboard and screen-reading software — or only with an automatic tool? And are the people who will later maintain the content briefed, so that alternative texts and heading structure do not go to seed after the launch? From the answers one can read off well whether accessibility belongs to the provider's craft or only to its brochure.

In project practice that means: accessibility begins not in the code but in the design. If an agency works in a UX-oriented way, many requirements are part of the craft anyway — contrasts are checked when the colour world is fixed, focus states are designed along with the components, forms are conceived from the outset with labels and comprehensible error texts. That is also how the Osnabrück agency BitBau handles it, from whose project practice the examples in this piece come: not as a bookable extra service, but as part of the normal design process.

How relevant the subject is independently of any question of statute is shown by one of these projects: the website of the Praxis am Salzmarkt, a presence for a medical practice in three languages, created in twelve weeks. A practice naturally reaches many older patients, people with visual impairments, people in stressful situations. Whether the law formally covers such a site is then almost secondary: anyone who does not make consultation hours, contact details and directions accessible to all simply misses the purpose of the site.

The benefit reaches further than the obligation in any case. Millions of people in Germany live with a disability; added to that are all those whose eyesight or fine motor skills decline with age — and the everyday, situational impairments: glaring sunlight on the display, the child in your arms, the broken arm. Accessible sites are simply more usable in all these situations. Visitors who are locked out are, viewed quite soberly, customers who are locked out.

There is also a technical kinship that is often overlooked: much of what accessibility demands is demanded by search engine optimisation as well. Clean heading structure, described images, comprehensible link texts, fast and robust pages — search engines “read” websites much as screen-reading software does: without eyes. Anyone who builds for screen readers as a rule builds better for Google too.

Accessibility does not end with the technology, either. Content, too, can erect barriers: convoluted sentences, jargon without explanation, link texts such as “click here” that mean nothing torn out of context, subheadings that do not reveal what follows. Clear language and clean structure are not a question of style but part of accessibility — and they cost nothing extra in ongoing maintenance once they have become habit. Here lies at the same time the operator's permanent task: the most carefully built accessible website loses its quality if new images are added without alternative texts and new pages without structure.

A word of warning belongs to honest advice as well: so-called overlay tools, which promise via an embedded script to make any website automatically accessible. Such tools can offer individual adjustments, but structural defects — missing labels, illogical sequences, keyboard traps — they do not reliably remedy. Anyone relying on them alone is lulled into a security that will not hold if it comes to an inspection.

How to begin? Realistically in three steps. First, stocktaking: automated testing tools find part of the problems, a manual test — keyboard instead of mouse, screen-reading software, contrast check — the rest. Second, prioritise: first the paths visitors actually take, that is contact, booking, purchase. Third, anchor it permanently: accessibility is not a project with an end date but a quality feature that has to run along with every new page and every new piece of content.

For the very first step one does not even need specialists — the most revealing self-experiment costs ten minutes. Operate your own website exclusively with the keyboard for once: jump from element to element with the tab key, trigger with the enter key, and in doing so follow the path a customer actually takes — home page, offering, contact form, submit. Frequent findings: the visible focus disappears after a few steps, the cookie banner cannot be closed without a mouse, the drop-down menu cannot be opened. Anyone who survives this attempt still has no guarantee of accessibility. But anyone who fails it knows very precisely where the work begins.

That leaves the initial question: do I have to? Perhaps not — as a micro-enterprise, with a purely informational site or in purely business-to-business trade possibly not in fact, whereby the classification in case of doubt belongs to specialists. The better question is a different one: can I afford to lock out some of my visitors — on a subject where legislators, search engines and demographic developments are visibly pointing in the same direction? Anyone planning a relaunch anyway conveniently has the answer to hand.