Probably not, but you can get most of the way there in one quarter. European Accessibility Act apps rules have applied since 28 June 2025. The apps we review usually fail on the same short list: unlabelled buttons, low contrast and layouts that break at large text sizes.
Our view is simple. Treat the Act as a product quality deadline, not a legal box-tick. Waiting to see how enforcement plays out is the expensive option.
What changed, and why it matters now
The European Accessibility Act (Directive 2019/882) was passed in 2019. Each member state then wrote it into national law. Those laws started applying on 28 June 2025.
It covers specific consumer services, and their websites and mobile apps are in scope:
- E-commerce, meaning almost any app that sells to consumers
- Consumer banking services
- E-books and the software used to read them
- Electronic communications services
- Passenger transport by air, bus, rail and water, including e-tickets and travel information
Location does not get you out. If you sell covered services to consumers in the EU, the Act applies to you, wherever your company is registered.
There are two real exemptions. Microenterprises providing services are exempt, meaning fewer than 10 staff and annual turnover or balance sheet of €2 million or less. Some existing contracts and products also get transition periods running as late as 2030. We would not plan your roadmap around that transition, because new releases and new customers are a weak place to argue you are still covered.
Get one practical article a week on building and maintaining apps, written by people who ship them.
What European Accessibility Act apps must actually do
The Act sets outcomes. The harmonised standard, EN 301 549, sets the details. For apps it largely maps to WCAG 2.1 Level AA.
In practice, that means a short list of concrete checks:
- Every control has a name a screen reader can announce. A trash icon must say "Delete address", not "Button".
- Normal text meets a contrast ratio of at least 4.5:1 against its background.
- Text can grow to 200% without content being cut off or overlapping.
- Focus moves in a logical order, and no screen traps the user.
- Swipe and drag actions have a simple tap alternative.
- Video has captions, and colour is never the only signal for an error.
You also need to publish how your service meets the requirements, usually in your terms or an accessibility statement. Both platforms give you the tools. Apple's accessibility documentation covers VoiceOver and Dynamic Type, and Android has equivalent APIs for TalkBack.
Who this helps and who it hurts
It helps users who are blind, have low vision, have motor impairments or are simply older. It also helps every user with a cracked screen, bright sunlight or one free hand. Accessible apps are usually clearer apps.
It helps teams that already build on native components. Standard SwiftUI, Jetpack Compose and well-used React Native components come with much of this built in.
It hurts teams with heavily custom UI. Hand-drawn controls, canvas-rendered screens and design systems built without semantics need real rework. Cross-platform apps can also suffer if nobody added semantic labels to custom widgets.
It also hurts anyone relying on overlay widgets. Those scripts sit on websites, not native apps. Even on the web, they do not fix broken markup underneath.
Our prediction: complaints first, by the end of 2026
Enforcement sits with national market surveillance authorities. Penalties are set by each member state, so they vary widely. Staffing and appetite vary too.
We expect the first public enforcement actions to come from user complaints, not proactive audits. We expect them by the end of 2026. Checkouts and banking logins will be hit first, because that is where blocked users lose money and get angry.
We could be wrong on the timing. We would not bet a product on it, because a complaint can also bring a demand from a big customer or a payment partner.
What to do this quarter
For a mid-sized app with a sane codebase, this is typically two to six weeks of engineering. Heavy custom UI pushes it longer. Here is the order we use:
- Pick five flows. Usually sign-up, login, search, checkout and account settings. These carry your revenue and your risk.
- Test them by hand. Run each flow with VoiceOver on iOS and TalkBack on Android, then again at the largest text size. Expect two to three days.
- Fix blockers first. Anything that stops a user finishing a flow comes before cosmetic contrast tweaks.
- Add checks to your pipeline. Use Xcode's Accessibility Inspector, Android's Accessibility Scanner and Espresso accessibility checks, plus axe-core for web views. Automated tools catch only some issues, so keep manual testing in each release.
- Publish your statement. Say what meets the standard, what does not yet, and how users can reach you.
- Document any burden claim honestly. The Act allows a disproportionate burden exemption, but you must write up the assessment. It is not a blanket opt-out.
When we take over an app, the cheapest moment to fix accessibility is during work you are already doing. Add it to your definition of done for every new screen. That stops the backlog from growing while you clear it.
FAQ
Does the European Accessibility Act apply to US companies?
Yes, if you provide covered services to consumers in the EU. Where your company is based does not matter. Microenterprises providing services are exempt, but most funded startups grow out of that quickly.
Which standard do apps need to meet?
The working benchmark is EN 301 549, which for apps largely follows WCAG 2.1 Level AA. An update aligned with WCAG 2.2 is in progress. Building to WCAG 2.2 AA now costs little extra and saves rework later.
