Accessibility - preparing for 2025

Digital accessibility means that websites and digital products are easy and uncomplicated to use, regardless of limitations or disabilities. From July 28, 2025, the German Accessibility Reinforcement Act (BFSG) will oblige private companies to comply with these standards in the B2C sector. Violations can result in fines of up to 100,000 euros, sales bans or product recalls.

Key Takeaways

• From July 28, 2025, private companies in Germany will have to comply with accessibility standards for the first time, with fines of up to 100,000 euros as well as sales bans and product recalls in the event of violations.
• Accessibility standards such as the WCAG are formulated as test criteria for testers, not as instructions for designers and developers, which makes their implementation unnecessarily difficult in everyday life.
• Those who only check and improve accessibility after a website has been completed pay significantly more because corrections often require a complete rebuild.
• Accessibility is not purely a developer task: keyboard navigation, for example, first requires a budget decision from the product owner, then a navigation structure from the UX designer and only then implementation by the developer.
• The most common requirements that can be implemented quickly include sufficient color contrasts, keyboard control, alternative texts for graphics and subtitles for videos.

What the BFSG will require of companies from 2025

From June 28, 2025, many private companies in Germany will also have to comply with accessibility standards for the first time. The basis for this is the Barrier-Free Strengthening Act, or BFSG for short. Until then, such requirements did not apply to the private sector in Germany, which is why many companies do not yet have the issue on their radar.

The consequences of non-compliance are not a marginal risk. There is the threat of fines of up to 100,000 euros, sales bans and the recall of products and services.

E-commerce is particularly affected, i.e. everything where money flows and end customers are involved. The focus is on B2C, not B2B. This includes not only websites, but also e-books, ticket machines, parking machines and the software that controls such devices.

What accessibility means in concrete terms

Accessibility means that a website or digital product must be easy and uncomplicated to use, regardless of a person’s impairment or disability. That is the basic principle.

A typical barrier is very small text on a website. People with visual impairments cannot read it well, which means the page is no longer accessible. Similarly, color contrasts that are too weak or content that can only be operated with a mouse.

The most common requirements include several specific points:

• Operability via keyboard and screen reader so that blind people can also navigate
• sufficiently high color contrasts for people with color vision deficiency or visual impairment
• a text size that is large enough to read
• Subtitles and alternative texts for everything that is not text, i.e. videos and graphics
• the ability to pause videos

There are exceptions for content that cannot be given a textual alternative. However, these must be declared separately so that a screen reader knows how to handle them.

Why test criteria let developers and designers down

The relevant standards are formulated as test criteria, and this is precisely the problem for everyone who has to implement accessibility. Success and test criteria help testers. But they don’t tell designers and developers what tasks they have to do.

The WCAG criteria are particularly relevant, as are the European standard EN 301549 and an ISO standard, which 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 incorporate accessibility into their designs from the outset. The criteria are not designed for this. They describe a target state for testing, not the steps for implementation.

Developers are often the only ones responsible and feel unable to act. They sit at the end of the process and are dependent on the previous steps. If accessibility was neglected at the beginning, the developer usually can’t pull it out at the end.

How test criteria become tasks for specific roles

Franziska Kroneck and Andrea Nutsi’s approach reverses the perspective: they derive specific tasks from the test and success criteria, i.e. real to-dos for designers, developers and product owners. The goal is not a new process, but work steps that can be integrated into the existing development process.

A single success criterion can be broken down into several tasks for different roles. The example of keyboard operation illustrates this well. A website must be fully operable using the keyboard, and this results in three tasks that build on each other:

These three tasks are contained in a single criterion. Only the breakdown makes it clear who has to do what and when.

Fewer tasks than criteria because specifications overlap

Hundreds of criteria become surprisingly few tasks. There are currently 29, and the estimate is that it will remain in the range of 30 to 40 and hardly rise above 50. That’s not a killer number.

The reason is the overlap. A guideline from the WCAG and a related one from the European standard often add up to a single task for the designer. Instead of working through each criterion individually, the task approach bundles together what belongs together in terms of content.

Initial tests with UX designers were positive. They finally had a to-do list and knew what was expected of them and how it could be transferred to their day-to-day work. Testing with developers is still pending.

The effort per task varies greatly

How much work a task requires depends on the context, but can be roughly estimated. The most time-consuming tasks take around two weeks, others are completed in one to three days.

Formulating alternative texts for graphics is one of the quick tasks. The actual learning effort lies in understanding which images require an alternative text and what information content should be included. This can be done in one to three days.

It becomes more time-consuming when real user research is required at the beginning. If you want to interview five to ten people with different limitations in order to derive their needs, you have to recruit, prepare and evaluate. Two to three weeks are realistic for this.

Where accessibility comes up against corporate identity and predefined components

Not every requirement is in the hands of the team that builds the software. Color contrasts are the clearest example of this. A pale pastel color in the corporate design may not even achieve the required contrasts.

Designers struggle with two concerns here. One is the fear that strict standards in the design area will diminish aesthetics. The other is predefined components and CI specifications that are not barrier-free.

If a designer or developer receives a predefined component, they often only have the option of informing the user that it is not accessible. They do not have the influence to change this. At this point, the standards in the company itself must be adapted.

AI helps with language, but does not replace an established tool

Large language models can be used effectively for simple and comprehensible language. Complicated texts, for example on government websites, can be converted into a version that does without technical terms and English words. Comprehensible language is a separate accessibility criterion, intended for people with concentration difficulties.

With automatically generated alternative texts, the result is mixed. An AI generator that analyzes an image and formulates an alternative text sometimes delivers useful, sometimes useless results. You cannot rely on it. An established tool that reliably implements accessibility is not yet in sight.

The later accessibility comes, the more expensive it becomes

Planning for accessibility right 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 cannot simply be made accessible afterwards. It then has to be redesigned. The pattern is familiar from other non-functional topics.

The later I integrate accessibility, the more expensive it becomes. If I plan for it right from the start, I end up saving a lot of money. Franziska Kroneck

If you only test performance at the end and realize that the architecture is not designed for it, you know the problem. The same applies to security. Accessibility is one of those things that need to be considered early on, because late corrections are expensive and sometimes impossible. For developers, this means another requirement that they need to consider early on.