ACCESSIBILITY IN APPS

The Current Situation

The Accessibility Enhancement Act has been in effect since June 28, 2025. It applies, among other things, to online stores, booking platforms, customer portals, and mobile apps in the B2C market. There are exceptions for micro-enterprises, and in some cases transition periods for existing products ‒ if in doubt, a legal review will clarify whether your product is affected.

The law implements the EU standard EN 301 549 (“Accessibility requirements for ICT products and services”) and specifies in detail what accessibility in software must entail.

In this article, we’ll take a closer look at what implementing these regulations entails and how it can be achieved cost-effectively.

Why the Same Work Costs Three Times as Much

The inquiries we receive almost always sound the same: “We’ve received an audit report; here are 10 issues ‒ how much will this cost?”

The individual fixes are minor. What makes it expensive is where they’re located. Accessibility is embedded in the design, in the reusable building blocks, and in the navigation ‒ in other words, in the parts that appear throughout the entire application. If you try to address this after the fact, you end up having to touch everything and then retest it all. If you take it into account from the start, it costs just a few hours during the concept phase and a few design decisions.

On top of that, there’s a second cost driver that’s rarely discussed: retrofitting happens under time pressure, usually with an externally imposed deadline. That’s the most expensive way to change software.

What We Did at EAT-TAXI

With EAT-TAXI, an ordering platform we’re supporting as it enters the market in Hof, we took the opposite approach: first, we conducted an assessment against current standards; then we developed a work plan based on that assessment; and finally, we implemented the changes as part of the normal development process rather than as a special project.

In the process, we learned two things that are relevant to any software project.

A solid foundation saves a lot of manual effort, but it generally can’t cover everything

We rely on the nuxt/a11y component library, which inherently meets a large portion of the technical requirements. What it doesn’t cover: everything related to the app on the device, and additional European requirements such as font enlargement, high-contrast display, and reduced motion. These aspects remain part of the project work ‒ predictable, but still a (small) additional effort. This is how we ensure that your software meets the strict European requirements.

Green checkmarks aren’t proof

 An automatic check runs with every change and prevents setbacks. However, it does not replace testing with actual assistive technologies. For example, a high-contrast display feature looked correct for months but never triggered on the iPhone ‒ technically flawless, but practically ineffective. That is precisely the difference between “implemented” and “compliant.” Apps created with the help of AI and released without the experienced eye of a senior-level developer usually do not fully meet the strict criteria of European accessibility guidelines.

Three Questions for Your Team

1. Do we know where we stand?

   A status assessment takes one to two days. We’re here to help!

2. Is accessibility tested before anything is shipped?

   If not, new issues may arise before existing ones are resolved.

3. Has anyone ever used the application the way people with disabilities do?

   Without this test run, any claim of compliance is merely a guess.

The Side Effect

Accessibility improves usability for everyone. Larger buttons are clicked more reliably even by people without disabilities, clear labels help everyone when they first open a page, and screen-reader functions have long been used by people who are cycling or cooking. For web applications, a clean structure also improves discoverability via search engines. So, even beyond merely meeting legal requirements, it’s worth focusing on this important topic.