How to make your app EAA -compliant before June 2025? – Conversation with Daniel Majewski
In June 2025, the European Accessibility Act (EAA) comes into force — a regulation that changes the rules of the game for digital product design. Sounds serious? It is. But don’t worry — we’ve got a conversation that breaks it all down.
In the latest episode of Around the Product Development, we talk with Daniel Majewski from Exerizon about:
✔️ Who the EAA really applies to,
✔️ how to prepare step-by-step (without the panic),
✔️ how to avoid the trap of “false compliance,”
✔️ why accessibility is not just a legal must-have — it’s a competitive edge.
Whether you’re a startup or building for banking, e-commerce, or public services — this episode is worth reading or listening to. Straight to the point. No fluff. Just what you need.

Table of contents
What’s Today’s Episode About?
Oskar (Host): Welcome to Around the Product Development, our weekly series where we deep-dive into the world of digital product creation — all in just 25 minutes. We explore every stage, from ideation to conversion and monetization, providing actionable insights and practical knowledge.
Today, we’re tackling a critical and, I believe, very time-sensitive topic: how to make your app EAA compliant. This must be done before June 2025, which is just around the corner.
With the European Accessibility Act — EAA for short — fast approaching, many companies are at risk of legal consequences, fines, and reputational damage.
But becoming compliant doesn’t have to derail your workflow or product roadmap. Joining us today is Daniel Majewski, co-founder and Head of Management Consulting at Exerizon, who’ll walk us through a practical, no-fluff guide to making your digital products accessible. Whether you’re in software, e-commerce, banking, or public services, this episode is packed with tips you can implement today to stay ahead of the curve.
Oskar: Hello Daniel.
Daniel (Guest): Hello, hello!
Oskar: How are you today?
Daniel: Pretty good, and thanks for having me. We’ve got a really interesting subject today, and I’m sure it’ll be action-packed.
Oskar: Oh, definitely!
Why Accessibility Matters in Digital Products
Oskar: Before we dive in, I’d love to start with why accessibility truly matters in digital product development. I believe more than 100 million people — that’s 1 in 4 adults in the EU — live with some form of disability. For them, accessible digital products are not a luxury, but a necessity. And with the European Accessibility Act coming into effect this June, accessibility becomes a legal obligation for many industries. But compliance aside, accessibility should be a core part of building inclusive, user-centered products. Because good design is accessible design.
What Is the European Accessibility Act (EAA)?
Oskar: Let’s start with the basics. What exactly is the European Accessibility Act, and why should product teams start taking it seriously now?
Daniel: Great question. I think many people in digital product teams have always had accessibility somewhere in mind, but — let’s be honest — it’s often been an afterthought. You create a product, you work through the roadmap, and then at the very end you ask the designer or frontend dev to “make it accessible.”
What the EU is trying to do through the EAA is to harmonize and align this process across all member states and industries. The idea is: if you launch a product or service in Europe, you shouldn’t have to deal with 27 different regulations — just one standard approach.
This regulation isn’t just about the end user. It’s also about making accessibility a clear, built-in part of the product creation process for designers, developers, and product managers. And, as you rightly said, the deadlines are approaching fast:
- June 2025: All new digital products and services must be compliant.
- By 2030: All existing products and services also need to be adjusted.
So whether you’re launching something after summer or updating an app with new features — you should be thinking about compliance already.
Who Is Covered by the EAA?
Oskar: You touched on a couple of industries there. Are all of them legally required to comply with the EAA by June, or are there some exclusions?
Daniel: Let’s start with who is covered. If you operate in:
- Consumer electronics
- Telecommunications
- Financial services
- Transport (air, bus, rail — all of it)
- E-commerce
- Publishing
- Emergency services
- Energy sector
…then you are covered by the EAA. And here’s the rule of thumb: if your product or service is customer-facing (B2C), it needs to be accessible.
It’s not just about web or mobile, either. If you’re sending emails with PDFs — both the email and the PDF must be accessible. Even physical devices like payment terminals and ATMs fall under this regulation.
There are some exemptions — for example, micro-enterprises (under 10 employees and less than €2M in turnover) may be exempt, depending on the country. But even then, it’s complex. And frankly, most startups don’t plan to stay small forever — so it’s smarter to design with compliance in mind from the beginning.
Designing for Accessibility from Day One
Oskar: Right — so it’s a good idea to think ahead and design for accessibility from day one.
Daniel: Absolutely. There’s a shift happening in how designers and product owners think. It’s no longer about “let’s build for our core users and fix accessibility later.” It’s about designing for all from the start.
And the benefits go beyond legal compliance. Inclusive design improves usability for everyone, and that includes use cases like voice control, screen readers, or AI assistants — all of which need to be compliant too.
How to Assess If You’re Covered
Oskar: How should product teams assess their current platforms? What are the steps they can take today without cutting features or compromising quality?
Daniel: Here’s a step-by-step approach:
1. Confirm if you’re covered
If you’re selling anything online, chances are you’re already partially covered. Don’t assume you’re exempt.
2. Audit your products
That includes existing platforms and what’s currently in development. Determine which deadlines apply — some features might count as “new,” and others as updates to existing products.
You’ll want to use both automated tools (for quick scans) and manual reviews (because many things are subjective).
3. Build a roadmap
Once you know your gaps, create a roadmap for updates. Coordinate with your IT teams and architects to plan frontend updates and technical debt management.
4. Implement and test
Make changes — and then validate them. Even if you think you’re compliant, test again. Accessibility isn’t always black and white.
Working with Experts — When and Why?
Oskar: Or… you can hire an expert. You and Boldare offer “Accessibility as a Service,” right?
Daniel: Exactly. This service covers everything: from auditing and planning, to hands-on support, validation, and creating compliance documentation. It also ensures your internal team doesn’t lose capacity during this process.
We’ve seen how tricky it can be. Tiny details can change whether you’re covered or not. So partnering with experts can save you from a false sense of compliance — or worse, legal risk.
Also, accessibility isn’t a one-off thing. It’s an ongoing mindset, and the regulation even requires that your employees are trained on how to handle accessibility properly.
Startups vs Enterprises — Different Challenges
Oskar: How do the challenges differ between startups and large enterprises?
Daniel: Great question. For large organizations, it’s often hard to even map all the customer touchpoints. You might have hundreds of systems — CRM, marketing automation, complaint handling — all of which must comply.
In startups, the challenge is different: fewer systems, but limited resources and expertise. In both cases, working with experts can help — whether it’s building capacity or just saving time.
Common Accessibility Mistakes to Avoid
Oskar: Last question before we wrap up. What are the most common mistakes that might seem okay but actually lead to compliance issues?
Daniel: The biggest one? Omnichannel journeys.
You might design a great experience for mobile — using native APIs or gestures — and assume it works the same way on web. But it doesn’t. Just because one channel is accessible doesn’t mean the whole journey is.
Always test across all relevant channels
Oskar: Got it. That was a very informative episode. Daniel, thank you so much for joining us. To our listeners — if you’re still hesitating to join the Agile Product Builders community, now’s the time! Be part of these conversations and grow with us. Our next episode is coming soon — stay tuned and have a great day. Bye!
Share this article: