The EAA already applies to your iOS app: what to decide before it's too late

Accessibility in your iOS app stopped being a UX matter: since June 2025 it's a legal obligation with penalties attached. And just like with GDPR, the companies that arrive late pay more than the ones that get ahead of it.

If you own the digital product of a company with an iOS app in production, knowing how to make your iOS app EAA-compliant is no longer optional — and the urgency is probably greater than your team has flagged. This guide explains, without unnecessary jargon, what the European Accessibility Act really demands, what risk you take on by doing nothing, and how to tackle it without stalling your roadmap.

I've spent 25+ years in software and 11 in native iOS. As a Senior iOS Architect I've passed quality and security audits in banking and insurance (some I can name, like Santander and AXA; others I can't, under NDA), and I worked on accessibility for Juegos ONCE (Spain's national organisation for the blind), where accessibility isn't a box to tick — it's the product's reason to exist. I'm writing this from that experience to help you make decisions, not to write code.

What the EAA is, and why it affects you

The European Accessibility Act — Directive (EU) 2019/882 — is the first European law requiring digital products and services to be accessible to people with disabilities. It's not a recommendation or a voluntary badge: it's binding legislation, applicable across the EU and in force since June 2025. Each member state has transposed it into its own national law, with its own enforcement body and its own penalties — so the obligation is the same everywhere, but the legal text you answer to depends on the country where you operate.

The part that matters to you: mobile apps are squarely in scope when they support a service the directive covers. In practice, if your app fits one of these categories, it's on the hook:

• Consumer banking and financial services.
• E-commerce (any app that lets people buy online).
• Passenger transport (ticketing, travel info, check-in).
• Electronic communications and messaging services.
• Audiovisual media and access to e-books.

In other words: almost any revenue-generating B2C app. If yours is a purely internal tool the fit is different, but don't assume you're out of scope. There's a microenterprise exemption, but read it carefully: it only applies to companies that provide services — not to those manufacturing or distributing products — and the bar is low (fewer than 10 people and an annual turnover or balance sheet not exceeding €2 million). Above that threshold you're not a microenterprise under the law, so the exemption doesn't cover you and the EAA applies anyway. When in doubt, confirm it with legal counsel in your jurisdiction before relaxing.

In business terms, the takeaway is simple: accessibility has gone from a "user experience" matter to a legal compliance requirement, on the same footing as data protection. And the GDPR parallel isn't rhetorical: the same pattern of companies that waited until the last minute and ended up remediating in a hurry, with bad press, is going to repeat here.

Deadlines and penalties: the clock is already running

The EAA has generally applied since June 2025, and the key dates come from the directive itself, so they're the same across every member state.

Two dates belong on your calendar:

• New services and products: must be compliant from launch. If you're shipping a new app or a major redesign, accessibility is now a launch requirement, not a fast follow.
• Services already on the market: have a transition period until 28 June 2030. It sounds far off, but it's deceptive: in an app with years of history, making it accessible isn't a one-sprint job. It's months of work spread screen by screen.

On the consequences of non-compliance, this is where the country you operate in matters: the directive leaves the sanctions regime to each member state, so the fines and how they're graded vary by jurisdiction — but they're real, and for serious breaches they reach six- and seven-figure amounts. In Spain, for instance, the EAA was transposed by Law 11/2023, which doesn't set its own fine schedule but routes accessibility breaches to the national disability-rights regime, where severe cases reach penalties of up to €1 million. Check the specific figures for the country where your app operates.

But let's be honest: for a business that lives off its app, the fine is rarely the most expensive part. The real cost is elsewhere:

• Remediation under pressure. A complaint or a non-compliance ruling forces you to fix it in a hurry, pulling the team off the roadmap, instead of planning it sensibly.
• Reputational damage. Being seen as a company that excludes people with disabilities is a headline no brand wants.
• Lost market. Around 87 million people in the EU have some form of disability (European Commission, Strategy for the Rights of Persons with Disabilities 2021–2030). An inaccessible app is, quite literally, customers who can't buy from you.

My recommendation, as someone who's been on the other side of many audits: treat it as debt with a legal due date. The sooner you know where you stand, the cheaper and more orderly it gets.

What "accessible" means in an iOS app (in plain terms)

When people talk about EAA compliance on iOS, the concrete technical reference is the European standard EN 301 549, which for mobile apps builds on the international WCAG 2.1 guidelines (level AA). You don't need to know them in detail; you do need to understand that iOS ships almost everything required out of the box, but your team has to switch it on and implement it well. It doesn't happen on its own.

In practice, 90% of the problems I find when auditing an app fall into four areas. Here they are, translated into what they mean for your product:

1. Screen reading (VoiceOver). This is the screen reader a blind person uses to operate the app: they hear what's on screen. If buttons and icons aren't properly labelled, that person hears "button, button, button" with no idea what any of them does. It's the most common failure and the one that makes the app outright unusable for that user.

2. Resizable text (Dynamic Type). Many users navigate with enlarged text, and it isn't a preference: the standard the EAA enforces (WCAG 2.1, criterion 1.4.4) requires text to scale up to 200% without losing content or functionality. On iOS the bar is even higher — the largest accessibility size (AX5) reaches 310%. If your design uses fixed font sizes, at those sizes text gets clipped or the layout breaks, and you lock out a huge user base: not just people with low vision, but older users too. A detail that often slips through: if your brand uses a custom typeface, scaling isn't automatic — the team has to map it to the system's text styles so it grows the same way. It's one of the first places teams cut corners under pressure, and one of the easiest ways to fail an audit.

3. Contrast and colour. That elegant brand gray usually lacks enough contrast to read comfortably. And if the app communicates something through colour alone (the field "turns red" on error), a colour-blind person won't notice. It has to be reinforced with text or icons.

4. Order and focus. The app has to "make sense" when navigated by voice: elements read in a logical order, and when an error or alert appears, the user is made aware of it. When this fails, the experience is chaos even if every element is correctly labelled.

The business conclusion: none of these four areas is a big standalone project. They're dozens of small adjustments spread across the whole app. That's good (nothing needs rewriting) and bad at the same time (you have to touch many screens with judgment). That's why order matters: first know where you stand, then prioritise.

What you should demand from an accessibility audit

If you're going to commission this work — in-house or with a specialist — here's what a serious iOS accessibility audit must deliver. Use it as a quality bar:

• A prioritised inventory, not a raw list of 400 issues. What's blocking compliance, what's important, what's minor.
• Effort estimates per block, so you can fit it into your planning.
• Coverage of the four areas above, screen by screen across critical flows (login, purchase, payment, sign-up).
• Real manual testing with VoiceOver, not just an automated report. Tools catch the obvious; what actually breaks the experience (labels that exist but make no sense when heard) only a human tester finds.
• A safety net so it doesn't regress. This is key and almost nobody says it: accessibility isn't a project you finish, it's a state you maintain. Every new screen can reintroduce failures. The right move is to leave automated checks built into your team's development process, so an inaccessible change is caught before it reaches production.

If all you get is a PDF full of issues and nobody mentions maintenance, you're missing half the work.

The mistakes that cost the most

These are the ones I run into most in production, even in apps built by very good teams. I'll frame them as risk, not code:

1. Unlabelled icons. The "share", "more options", "favourite" buttons that say nothing to a screen reader. The number-one mass failure.
2. Text baked into images. It can't be read aloud or enlarged. It usually comes from banners and promos that design hands over as an image.
3. Focus lost after an action. The user submits a form, an error appears, and by voice they never learn something went wrong. You lose conversion and compliance at once.
4. Contrast failing by design decision. The issue here isn't technical, it's process: contrast must be validated before the style guide is locked, not after.
5. Half-accessible embedded web content. If your app embeds web pages, their accessibility counts toward the EAA too — and it's usually the biggest, most-forgotten hole.

The common thread: almost none of these is a "severe" failure on its own. What's severe is the accumulation. An app with hundreds of these small failures is, legally, a non-compliant app.

How to tackle it without stalling your roadmap

The objection I always hear from the product side is fair: "I can't stop feature development for this." You don't have to. Here's how I frame it when I embed into a team:

1. Audit first. Know exactly where you stand. Without this, any estimate is a guess.
2. Prioritise by business flows. Start where your money and your greatest legal exposure are: login, purchase, payment. The rest can wait.
3. Fix in parallel. A senior iOS architect embedded in your team can work through accessibility while your team keeps shipping features. It's not one or the other.
4. Automate to avoid relapse. Leave the checks in place so the app doesn't break again with every future release.

Done this way, accessibility stops being a blocker and becomes a controlled workstream, with a known date and cost.

Frequently asked questions

Does the EAA apply to iOS mobile apps?

Yes. The European Accessibility Act applies to mobile apps when they support a service the directive covers: consumer banking and financial services, e-commerce, passenger transport, electronic communications and audiovisual media. In practice, almost any revenue-generating B2C app is in scope.

Since when is the EAA in force?

It has generally applied across the EU since June 2025. New services and products must be compliant from launch; services already on the market have a transition period until 28 June 2030. Each member state transposes the directive into its own law and sets its own penalties.

What does it mean for an iOS app to be EAA-accessible?

The technical reference is the standard EN 301 549, which for mobile apps builds on WCAG 2.1 level AA. In practice, most issues fall into four areas: VoiceOver labelling, Dynamic Type support (resizable text), contrast and colour use, and reading order and focus management.

Is there an exemption for small companies?

There is a microenterprise exemption, but it is restrictive: it only applies to companies that provide services (not those manufacturing or distributing products) and below a low threshold. When in doubt, confirm it with legal counsel in your jurisdiction before assuming you are out of scope.

Need to know whether your app meets the EAA?

Making a years-old app accessible isn't flipping a switch: it's auditing screen by screen, prioritising by legal and business impact, fixing without stalling your roadmap, and leaving the safety net in place so it doesn't relapse. That's exactly the work I've done in banking, insurance, and at Juegos ONCE, with millions of users behind them.

If you have an iOS app in production and don't know how far you are from compliance, the first step is to measure it. At AtalayaSoft we run an iOS accessibility audit focused on the EAA: we review your app against the standard (EN 301 549 / WCAG 2.1 AA), hand you a prioritised, actionable report — with estimated effort, ready for your planning — and, if you need it, embed into your team to implement the fixes.

Request your iOS Accessibility Audit for the EAA →

---

Related services

• iOS Accessibility (EAA) — accessibility audit and implementation to meet the EAA.
• Vibe Code Audit iOS — a clear picture of the real state of your iOS codebase, accessibility included.
• Senior iOS Engineer — embedding a senior iOS architect into your team (staff augmentation).