Digital accessibility means that websites and digital products can be used easily and without obstacles, whatever limitation or disability a person has. Since June 28, 2025, Germany’s Accessibility Strengthening Act (BFSG) has required private companies in the B2C sector to meet these standards. Violations can lead to fines of up to 100,000 euros, sales bans or product recalls.
Key Takeaways
- Since June 28, 2025, private companies in Germany have also had to meet accessibility standards, and violations can bring fines of up to 100,000 euros, sales bans and product recalls.
- Accessibility standards such as the WCAG are written as test criteria for testers, not as instructions for designers and developers, which makes them needlessly hard to apply in daily work.
- Checking and fixing accessibility only after a website is finished costs far more, because late corrections often mean rebuilding it from scratch.
- Accessibility isn’t a job for developers alone: keyboard navigation first needs a budget decision from the product owner, then a navigation structure from the UX designer, and only then the implementation by the developer.
- Some of the most common requirements are also quick to implement: sufficient color contrast, keyboard control, alternative text for images and captions for videos.
What the BFSG Requires of Companies Since 2025
Under the BFSG, many private companies in Germany have had to meet accessibility standards since June 28, 2025. BFSG stands for Barrierefreiheitsstärkungsgesetz, the Accessibility Strengthening Act. Before that date, such rules didn’t apply to the private sector in Germany, which is why many companies ignored the topic for a long time.
Failing to comply is not a minor risk. Companies face fines of up to 100,000 euros, sales bans and recalls of products and services.
The law mainly covers electronic commerce, meaning anything where money changes hands and consumers are involved. The focus is on B2C, not B2B. That includes not only websites but also e-books, ticket machines, parking meters and the software that runs such devices.
What Digital Accessibility Means in Practice
Digital accessibility means that a website or digital product has to be easy and straightforward to use, no matter what limitation or disability someone has. That is the basic principle.
A typical barrier is very small text on a web page. People with impaired vision can’t read it well, so the page is no longer accessible. Weak color contrast or content that only works with a mouse has the same effect.
The most common requirements include:
- operation by keyboard and screen reader, so that blind people can navigate too
- color contrast high enough for people with color vision deficiency or low vision
- text large enough to read
- captions and alternative text for everything that isn’t text, such as videos and images
- the option to pause videos
There are exceptions for content that can’t have a text alternative. Those exceptions have to be declared explicitly, though, so that a screen reader knows how to handle the content.
Why WCAG Success Criteria Leave Designers and Developers on Their Own
The relevant standards are written as test criteria, and that is exactly the problem for everyone who has to implement accessibility. Success criteria and test criteria help testers with accessibility testing. They don’t tell designers and developers which tasks they need to do.
The most important are the WCAG criteria, plus the European standard EN 301549 and an ISO standard that is not legally binding in Germany but is in the UK. Together they add up to hundreds of criteria spread over hundreds of pages.
UX and UI designers need a way to build accessibility into their designs from the start. The criteria aren’t made for that. They describe a target state to test against, not the steps to get there.
Developers often end up as the only ones held responsible, and they feel powerless. They sit at the end of the process and depend on everything that came before. If accessibility was neglected at the start, the developer usually can’t save it at the end.
Turning Test Criteria into Tasks for Specific Roles
Franziska Kroneck and Andrea Nutsi turn the perspective around. From the test and success criteria, they derive concrete tasks, real to-dos for designers, developers and product owners. They aren’t after a new process but after work steps that fit into the existing development workflow.
A single success criterion can break down into several tasks for different roles. Keyboard operation is a good example. A website must be fully usable with the keyboard, and that results in three tasks that build on each other:
| Role | Task |
|---|---|
| Product owner | Provide budget and time, including time to learn the topic |
| UX designer | Define the navigation and tab order |
| Developer | Implement the defined tab order in the code |
All three tasks come from one criterion. Only by splitting it up does it become clear who has to do what, and when.
Fewer Tasks Than Criteria, Because the Standards Overlap
Hundreds of criteria turn into surprisingly few tasks. Right now there are 29, and the expectation is that the number will stay somewhere between 30 and 40 and hardly go beyond 50. That is not a monster workload.
The reason is overlap. A WCAG guideline and a related one from the European standard often add up to a single task for the designer. Instead of working through each criterion one by one, the task-based approach groups together what belongs together.
First tests with UX designers went well. They finally had a to-do list and knew what was expected of them and how it fits into their daily work. Trials with developers are still to come.
The Effort per Task Varies Widely
How much work a task takes depends on the context, but it can be roughly estimated. The biggest tasks take about two weeks, others are done in one to three days.
Writing alternative text for images is one of the quick ones. The real learning effort lies in understanding which images need alternative text and what information belongs in it. That is doable in one to three days.
It gets expensive when real user research comes first. If you want to interview five to ten people with different disabilities to work out what they need, you have to recruit, prepare and analyze. Two to three weeks is more realistic for that.
Where Accessibility Clashes with Corporate Identity and Predefined Components
Not every requirement is in the hands of the team building the software. Color contrast is the clearest example. A pale pastel color from the corporate design may simply never reach the required contrast.
Designers struggle with two worries here. One is the fear that strict standards will hurt the look and feel of their work. The other is predefined components and brand guidelines that aren’t accessible to begin with.
When a designer or developer is handed a predefined component, often all they can do is point out that it isn’t accessible. They have no power to change it. At that point, the company’s own standards have to be adjusted.
AI Helps with Language but Doesn’t Replace a Proven Tool
Large language models are useful for plain and easy-to-understand language. Complicated texts, for example on government websites, can be rewritten into a version without jargon and English loanwords. Understandable language is a separate accessibility criterion, meant for people who have trouble concentrating.
With automatically generated alternative text, the results are mixed. An AI generator that analyzes an image and writes alt text sometimes delivers something useful and sometimes doesn’t. You can’t rely on it. A proven tool that reliably takes care of implementing accessibility is nowhere in sight so far.
The Later Accessibility Comes, the More It Costs
Planning accessibility from the start saves money in the end. If you finish a website first and then have it tested, you risk a long list of defects and expensive rework.
Often a finished application can’t simply be made accessible after the fact. It has to be rebuilt. The pattern is familiar from other non-functional topics.
“The later I integrate accessibility, the more expensive it gets. If I plan for it from the start, I save myself a lot of money in the end.”
(Franziska Kroneck)
Anyone who has tested performance at the very end and found that the architecture wasn’t designed for it knows the problem. The same goes for security. Accessibility belongs with these topics that need to be considered early, because late fixes are expensive and sometimes impossible. For developers, that means one more requirement to take into account early on.
Frequently Asked Questions
Which companies are affected by the Accessibility Strengthening Act?
Since June 28, 2025, the Accessibility Strengthening Act (BFSG) has also required private companies to comply, particularly in electronic business transactions with end customers. The focus is on B2C, not B2B. This applies not only to websites, but also to e-books, ticket and parking machines, and the software that controls such devices. Until then, the regulations in Germany did not apply to the private sector.
What are the potential consequences if a website does not meet the requirements?
Possible penalties include fines of up to 100,000 euros, sales bans, and the recall of products and services. This is not a marginal risk; it directly impacts sales. Many companies are not yet aware of this issue because such requirements simply did not apply to the private sector in Germany before.
What are the most common reasons why typical websites fail to meet accessibility standards?
Very small text, insufficient color contrast, and content that can only be navigated using a mouse. People with visual impairments cannot navigate these sites. Among the most common requirements are therefore keyboard and screen reader accessibility, sufficient contrast, readable text sizes, captions and alternative text, as well as the ability to pause videos.
Is accessibility the developer’s responsibility?
No. A single criterion often breaks down into tasks for multiple roles. When it comes to keyboard navigation, the product owner must first allocate the budget and time, including time for training. Then the UX designer defines the navigation and tab order, and only after that does the developer implement them in the code. Developers are at the end of the process and can hardly make up for early oversights.
How many specific tasks result from the hundreds of testing criteria?
Significantly fewer than the number of criteria might suggest: The approach described results in 29 tasks, with the estimate that the total will remain between 30 and 40 and rarely exceed 50. This is due to overlaps. A WCAG guideline and a related requirement from the European standard EN 301549 often combine to form a single task for the designer.
How much time does a single accessibility task take?
The time required varies greatly. The most time-consuming tasks take about two weeks, while many others can be completed in one to three days. Alternative text for graphics is among the quicker tasks; the learning curve lies in determining which images actually require text. User research involving five to ten interviews, on the other hand, tends to take two to three weeks.
What should you do if the corporate design or predefined components aren’t accessible?
In that case, the solution doesn’t lie with the team building the software. A pale pastel color from the corporate design might not even meet the required contrast ratios. When a designer or developer is given a predefined component, they’re often left with nothing more than a note stating that it isn’t accessible. In such cases, the standards within the company itself must be changed.
Can AI handle the implementation of accessibility?
Only to a limited extent. Large language models can be usefully applied to produce simple and understandable language, for example to rephrase complicated government documents without technical terms or English words. Automatically generated alternative text, on the other hand, sometimes yields useful results and sometimes useless ones. An established tool that offers high reliability in implementing accessibility is not yet in sight.
