European Accessibility Act and Mobile Apps

The European Accessibility Act (EAA) is an EU directive that, as of 28 June 2025, directly affects mobile apps in areas like banking, e-commerce, transport, and e-books. If you're keeping your app on the European market or planning to, in this article you'll find the law's scope, which apps can fall under the exemption, and step by step what you need to do technically on iOS/Android.

💡 Pro Tip: Before starting compliance work, walk through your existing app end-to-end with a real screen reader (VoiceOver or TalkBack) — even a screen that looks like it has "enough contrast" on paper can surface different problems in real use.

Table of Contents

• Scope of the Law and the 28 June 2025 Date
• Apps That May Fall Outside the Scope
• Technical Equivalents: WCAG Criteria on Mobile
• The iOS Side: Accessibility Approach
• The Android Side: TalkBack and Technical Equivalents
• Automated Audit + Manual Test Protocol
• Compliance File and Evidence Retention
• FAQ
• Does the European Accessibility Act cover mobile apps?
• When is the compliance date?
• What do I need to do technically for compliance?
• Am I exempt if my app is developed by a small team?
• Is compliance only needed on the App Store/Play Store, or also on the web version?
• Update (September 2026)
• Conclusion
• Sources

Scope of the Law and the 28 June 2025 Date

The European Accessibility Act aims, in the European Commission's own words, to "improve the functioning of the internal market for accessible products and services by removing barriers created by divergent rules in Member States." The law was adopted in 2019, Member States were required to transpose the directive into national law by June 2022, and the actual compliance date was set as 28 June 2025.

The Commission's scope list explicitly includes computers and operating systems, smartphones, ATM/ticketing/check-in machines, TV equipment, telephony services, banking services, e-books, and e-commerce. The directive's definition of e-commerce service (Art. 3(30)) describes these services as being provided "at a distance, through websites and mobile device-based services, by electronic means"; Art. 2(4), when listing exemptions, directly uses the phrase "the content of websites and mobile applications." In other words, what matters is not the type of device but which service the app provides — banking, e-commerce, and e-book apps in particular fall directly within this definition.

The Commission monitors whether the directive is transposed and applied fully and correctly, and has set up an expert group of national administrations, market surveillance authorities, disability civil society organizations, accessibility experts, and industry representatives to strengthen cooperation. This means the law isn't a commitment left on paper — it's actively followed.

It's worth clarifying why this matters for a Turkey-based developer or agency: if you offer your app to EU users too through the App Store or Play Store, and it provides an in-scope service like banking, e-commerce, or e-books, asking a legal advisor early whether the EAA applies can end up cheaper than redesigning the product from scratch later.

Apps That May Fall Outside the Scope

Not every mobile app is subject to this obligation. Article 4(5) exempts micro-enterprises — defined in Article 3(23) as having fewer than 10 employees and an annual turnover or balance sheet not exceeding EUR 2 million — from the service obligations.

The point to note here is that the exemption is about the size of the business, not the type of app. A white-label banking app built by a small team but owned by a large company can't benefit — what matters is the employee count and turnover of the business providing the service.

The exemption also only applies to micro-enterprises providing a "service"; different rules may apply on the "product" side. If you're not sure which category your situation falls into, the safest route is to clarify this assessment with a legal advisor.

Technical Equivalents: WCAG Criteria on Mobile

The accessibility level the EAA targets speaks the same language as WCAG (Web Content Accessibility Guidelines), the most widely accepted benchmark worldwide: in the World Wide Web Consortium's (W3C) own words, "Level AA covers all of the Level A and AA requirements." Many organizations target Level AA. In the mobile world, this isn't a single CSS rule or HTML attribute — it comes to life through platform-specific equivalents like screen reader support, touch target size, contrast ratio, and focus order.

The two major mobile platforms (iOS and Android) have their own accessibility APIs, and both adapt the same principles behind WCAG — perceivable, operable, understandable, robust — to their own component model. For a broader look at the WCAG criteria themselves, see Mobile Accessibility: WCAG Guide. The next two sections cover these equivalents platform by platform.

The iOS Side: Accessibility Approach

Apple's accessibility ecosystem is built around VoiceOver (screen reader), Dynamic Type (adapting to the system-wide text size the user has set), and visual requirements like contrast/touch target — concepts that are publicly and long documented by Apple and accepted as standard in the iOS developer ecosystem. For the code-level detail of VoiceOver labeling and Dynamic Type integration, check out iOS Accessibility: The Complete Guide from VoiceOver to Dynamic Type on the site — it covers VoiceOver labeling, Dynamic Type integration, and contrast/touch target topics end-to-end with code examples.

In practice, watch for three patterns: every interactive component reads meaningfully via VoiceOver, the interface scales without breaking as system text size increases, and visual elements (especially buttons/icons) have sufficient contrast and touch area. When auditing these, check Apple's current developer documentation; for specific thresholds or API names, the primary reference should always be Apple's own docs.

1// Basic VoiceOver labeling pattern — SwiftUI
2// Adds a meaningful accessibility label to a visual icon button.
3Button(action: addToCart) {
4    Image(systemName: "cart.badge.plus")
5}
6.accessibilityLabel("Sepete ekle")
7.accessibilityHint("Ürünü sepetine ekler")

On iOS, the error I generally run into is this: leaving a visual icon on its own without any accessibility label, so the VoiceOver user can't tell what it does. Another common mistake is adding the label correctly but never testing Dynamic Type: when the user increases the system text size, text gets truncated or the button's touch area overflows.

The most practical fix is, at least once during development, selecting the largest text size in the device's accessibility settings and walking through the app's critical screens — this can surface visual breakage far faster than a code review.

The Android Side: TalkBack and Technical Equivalents

Google's official Android documentation says every UI element should include a description explaining its purpose: "For every UI element in your app, add a description that explains the purpose of the element. In most cases you write this description in the contentDescription attribute." These should describe the purpose and outcome of the interaction, not the visual detail — for a submit button, "Submit" is enough; "Submit button" is redundant (Android's own example is exactly "Submit", not "Submit button").

For touch targets, Android's recommendation is clear: the focusable area of every interactive element should be at least 48dp x 48dp, with "bigger is even better." In Jetpack Compose, Text components don't need an extra contentDescription — TalkBack reads the text automatically. If a purely decorative element is part of another component (e.g., an Icon), pass null as contentDescription to avoid redundant labeling.

Using Role semantics (e.g., Role.Button, Role.Switch) to tell the screen reader an element's type ensures TalkBack announces it correctly.

These rules are most often violated in small UI pieces added later: a new icon button from a design update, a temporary A/B test banner, or a third-party SDK's own component. Since none of these were considered under "accessibility" when first written, contentDescription or Role semantics usually gets skipped. That's why you need to audit not just at major releases but whenever a new interactive component is added — the next section shows how to make this a continuous gate.

1// Jetpack Compose — meaningful contentDescription + Role semantics
2Icon(
3    imageVector = Icons.Filled.ShoppingCart,
4    contentDescription = "Sepete ekle", // not "Sepete ekle butonu"
5    modifier = Modifier
6        .size(48.dp) // Android recommendation: a minimum component size of 48dp x 48dp
7        .clickable(onClickLabel = "Sepete ekle", role = Role.Button) { addToCart() }
8)

Automated Audit + Manual Test Protocol

Neither automated tools nor manual testing alone is enough — you need to set up both together. On the Android side, Google's own recommendation is: check color contrast with an online contrast checker or the Accessibility Scanner app; test your code to make sure contentDescription is being conveyed as expected — Android Lint and Compose testing tools can automatically catch common issues here.

In practice, a three-layer protocol works:

• Static analysis: Android Lint / Compose testing (Android) — run automatically on every PR in CI.
• Automated device scan: scan real screens with Accessibility Scanner (Android) and list contrast/label gaps.
• Manual walkthrough: with VoiceOver/TalkBack on, complete the app's critical flows (sign-up, payment, add to cart) start to finish using only screen reader and keyboard/switch control — the "logical" issues automated tools can't catch (wrong reading order, meaningless labels) show up here.

Think of these three layers as a complementary loop, not a sequence: static analysis warns you during development, automated scanning gives a final pre-release check, and manual testing surfaces UX issues neither of the others can see. Skip any layer and barriers remain for real users even if your compliance file says "tested."

1# Android — to run the Lint audit as a CI gate
2# Android Lint and Compose testing can automatically catch
3# common accessibility issues like missing contentDescription
4./gradlew lint

Compliance File and Evidence Retention

If you're under the EAA obligation, saying "we made it accessible" isn't enough — you need to prove it. National market surveillance authorities can get involved under the Commission's monitoring model, so a compliance file with audit/test results, which fix was made in which version, and remaining known limitations strengthens your position in any inquiry.

In practice, this file should include:

• Test date and scope: which screens, which OS version, which screen reader it was tested with.
• Findings and fix records: which version closed each finding (with a commit/PR reference).
• Automated scan outputs: raw reports from tools like Accessibility Scanner, Lint — archived with a version tag.
• Known limitations and roadmap: issues not yet resolved and the planned resolution date.

A common mistake is treating this file like a one-time "delivery document" — closed once the audit is done and never reopened. Its real value is in being updated with every new version. Adding a line saying "this was tested, this was found, this was fixed in this version" whenever you add a screen, redesign a flow, or integrate a third-party SDK keeps your team from forgetting accessibility and lets you answer in minutes instead of hours of digging when an audit request comes in.

If you're a small team, it's enough to keep this file in your existing project management system (a wiki page, a CHANGELOG section) instead of a separate tool — what matters isn't the format, it's the continuity.

FAQ

Does the European Accessibility Act cover mobile apps?

Yes. In the European Commission's official scope list, smartphones appear as a separate item, and services like banking, e-commerce, and e-books are explicitly listed; mobile apps that provide these services fall within the scope of the law.

When is the compliance date?

The law's actual compliance date is 28 June 2025. Member States were required to transpose the directive into national law earlier, by June 2022; 28 June 2025 is the date by which companies must actually make the new products and services they bring to market accessible.

What do I need to do technically for compliance?

It varies by platform: on Android, add a meaningful contentDescription, a touch target of at least 48dp x 48dp, and Role semantics to every interactive element; on iOS, follow VoiceOver labeling and Dynamic Type support from the VoiceOver guide on the site.

On both, run automated scanning (Lint, Accessibility Scanner) together with manual screen reader testing, and keep the results in a compliance file.

Am I exempt if my app is developed by a small team?

The exemption relates to the size of the business providing the service, not the team developing the app. Under the micro-enterprise definition in Article 3(23) of the directive, if you have fewer than 10 employees and a turnover/balance sheet not exceeding EUR 2 million, you may qualify for the service exemption in Article 4(5) — but the safest route is to confirm this assessment for your specific situation with a legal advisor.

Is compliance only needed on the App Store/Play Store, or also on the web version?

The EAA's scope doesn't make a platform-specific distinction; if the service itself (banking, e-commerce, e-books, etc.) is in scope, the accessibility expectation applies to every channel through which that service is accessed (mobile app, web). This article focuses on the mobile app side; for the technical equivalents on the web side, you need to look at WCAG itself.

Update (September 2026)

This article was written on 16 April 2025, i.e., before the EAA's 28 June 2025 compliance date. Since then the law has actually taken effect, and concrete developments have occurred on the audit/standards side:

• 28 June 2025 — the EAA actually took effect. For services like banking, e-commerce, transport ticketing/information apps, and e-books, accessibility is no longer optional but a legal requirement; in AccessibleEU's own words, this date is described as the start of "a new era for inclusion."
• 14 October 2025 — the 5th European Accessibility Summit now had the topic of the EAA's _enforcement/implementation_ on its agenda — the law is no longer on paper, it's in the actual oversight phase.
• According to an AccessibleEU announcement dated 4 June 2026, the CEN/CENELEC/ETSI public procurement guide was renewed (the document was published in February 2026). Two separate technical reports from 2014 were merged into a single document (CEN-CLC-ETSI/TR 101551:2026), putting EN 301 549 forward as the primary reference.
• 7 September 2026 — the EN 301 549 standard was updated to v4.1.1, and the reference WCAG version moved from 2.1 to 2.2 (6 new criteria added). Important nuance: the legally binding version is still v3.2.1 (2021) — v4.1.1 will only become mandatory once it's cited in the EU Official Journal, but organizations are advised to already prepare according to WCAG 2.2.
• 5 August 2026 — the European Central Bank is designing the digital euro app above and beyond the EAA. Full keyboard navigation, screen reader compatibility, plain language, and reduced motion are among the planned features; this is a concrete example of a large-scale EU mobile app being designed from the ground up with the EAA as a reference.
• An analysis dated 24 September 2026 examines why accessibility complaints remain rare: when users hit a barrier, they abandon the service or switch to a competitor instead of filing a formal complaint. The analysis's own warning is important: "a low complaint count is not proof that a service is accessible."

The common message of these developments is: the EAA is no longer a "future date" — it's an obligation being actively monitored and still being updated on the standards side. When preparing your compliance file, base it on EN 301 549 v3.2.1 / WCAG 2.1 AA, which is still binding, but also add the transition to WCAG 2.2 to your roadmap.

Conclusion

The European Accessibility Act, if you keep your mobile app on the European market, is no longer a theoretical future obligation — it's a compliance requirement that actually started applying on 28 June 2025. Clarifying its scope (type of service + business size), implementing the platform-specific technical equivalents on the Android and iOS sides, and continuously verifying this with an automated + manual test protocol are the three main pillars of this process.

This article focused on the legal/compliance angle; for the technical details of VoiceOver and Dynamic Type implementation on the iOS side, you can check iOS Accessibility: The Complete Guide from VoiceOver to Dynamic Type. When explaining compliance work to your product team, you'll also need user behavior data — at this point, Mobile Retention Metrics: Reading D1, D7, and D30 Correctly will be useful.

If you want to see the effects of the compliance process on the marketing/measurement side, you can check out Mobile Attribution: Choosing an MMP and SKAdNetwork Measurement, and if you want to ship changes in your app with A/B test discipline, Mobile A/B Test Infrastructure: Setup, Statistics, and Pitfalls.

Sources

• European Accessibility Act — European Commission — The law's official scope, purpose, and monitoring mechanism.
• Directive (EU) 2019/882 — EUR-Lex — The official text of Article 2(4) scope exemptions, Article 3(23) micro-enterprise definition, Article 3(30) e-commerce service definition, Article 4(5) exemption, and Article 31 application date.
• WCAG 2 AA Conformance — W3C WAI — The definition of Level AA conformance.
• Make apps more accessible — Android Developers — contentDescription, touch target size, Role semantics, and test protocol.
• New era for inclusion begins as EAA enters into force — AccessibleEU — The actual start of the 28 June 2025 application date.
• European accessibility standard EN 301 549 has been updated — AccessibleEU — EN 301 549 v4.1.1 and the transition to WCAG 2.2.
• Digital euro app to incorporate highest accessibility standards — AccessibleEU — The ECB digital euro app example.
• Make your app more accessible — Accessibility Scanner, Android Developers — The official source that Accessibility Scanner scans for contrast, touch target, and missing labels.