---
title: "Accessibility Is Now a Market-Access Rule: The European Accessibility Act for Android Teams"
description: "The EAA has covered EU banking, e-commerce, transport and e-book apps since June 2025, and its standard now points to WCAG 2.2. What Android teams must ship."
url: https://android-x.com/blog/european-accessibility-act-android-apps
author: "Rocky Elsalaymeh"
publisher: "Strategia-X (ANDROID-ARCHITECT)"
published: 2026-09-15
updated: 2026-10-11
category: "Accessibility"
reading_time: "10 min read"
---

# Accessibility Is Now a Market-Access Rule: The European Accessibility Act for Android Teams

> The EAA has covered EU banking, e-commerce, transport and e-book apps since June 2025, and its standard now points to WCAG 2.2. What Android teams must ship.

By Rocky Elsalaymeh. Published 2026-09-15, updated 2026-10-11. Canonical page: https://android-x.com/blog/european-accessibility-act-android-apps

## The Backlog Item That Became a Legal Requirement

In most Android teams, accessibility lives in the backlog as a quality aspiration: a TalkBack pass before a big release, a contrast fix when a designer complains. For any app that sells to consumers in the European Union, that framing expired on 28 June 2025.

[Directive (EU) 2019/882](https://eur-lex.europa.eu/eli/dir/2019/882/oj), the European Accessibility Act, "applies to the following services provided to consumers after 28 June 2025," and the list reads like the top of the Play Store: electronic communications, passenger transport services (explicitly including "mobile device-based services including mobile applications"), consumer banking, e-books and dedicated software, and e-commerce. Its definition of e-commerce names apps outright: "services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract." And Annex I requires those services to be made accessible "by making them perceivable, operable, understandable and robust", the four principles of WCAG, written into EU law.

The audience is not a niche. The [World Health Organization](https://www.who.int/news-room/fact-sheets/detail/disability-and-health) estimates that "1.3 billion people experience significant disability. This represents 16% of the world's population, or 1 in 6 of us." The [European Commission](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/persons-disabilities-eu_en) puts the EU figure at "around 87 million people." An inaccessible app is not failing an edge case; it is failing a population the WHO counts at one person in six.

*This article explains engineering implications, not legal advice. Obligations depend on each Member State's transposition and on your service; confirm scope with counsel.*

## Are you in scope?

The directive is precise about who it covers, and so should your scoping conversation be.

| Question | What the directive says | Engineering consequence |
|---|---|---|
| Is it a consumer service in a listed sector? | Banking, e-commerce, e-books, passenger transport, electronic communications (Article 2(2)) | If yes, the app is part of the service |
| Are you a microenterprise? | Fewer than 10 persons and annual turnover or balance sheet not exceeding EUR 2 million; service providers of that size "shall be exempt" | Exempt from the service requirements, not from good practice |
| Were contracts signed before 28 June 2025? | They "may continue without alteration until they expire, but no longer than five years from that date" | A deadline for legacy contracts, not a pass for new releases |
| Are you relying on older products? | A transitional period "ending on 28 June 2030" for products lawfully used before that date | Plan the migration now; 2030 is a hard stop |

Two details are routinely missed. First, the microenterprise exemption is narrow: a ten-person startup with a banking licence is out of it. Second, compliance includes disclosure. Under Article 13, "service providers shall prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements." That is a document your product team has to be able to write, which means an engineering team has to be able to evidence it.

## What "Accessible" Means, and Why the Answer Just Changed

The directive sets outcomes. The working definition comes from the harmonised European standard, EN 301 549, and this month it moved. On 7 September 2026, [AccessibleEU](https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en), the Commission's accessibility resource centre, announced that "a new version of the European accessibility standard, EN 301 549 v4.1.1, was published in September 2026. The biggest change is that it adopts WCAG 2.2 as the accessibility benchmark for websites, software and digital documents, replacing WCAG 2.1."

The legal status is transitional: "Until the European Commission formally cites EN 301 549 v4.1.1 in the Official Journal of the European Union, the current reference remains EN 301 549 v3.2.1 (2021), which is based on WCAG 2.1 Level AA." Engineering should not wait for the citation. [V4.1.1](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf) is the first version "prepared under the Commission's standardisation request C(2022) 6456 final ... to provide one voluntary means of conforming to the essential requirements of Directive (EU) 2019/882", in other words the first version written *for* the EAA. Building to 2.1 today means rebuilding to 2.2 later.

One clause settles a long-running argument for hybrid apps: "When parts of non-web software, such as mobile apps, are implemented with web views, these web views are embedded in the app and thus do not meet the definition of a web page." Web views are assessed under clause 11, as software. Your WebView checkout is part of the app, not a web page with its own rules.

The [new WCAG 2.2 criteria](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/) at levels A and AA that land hardest on mobile:

| Criterion | Level | What it means in an Android app |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky bars and sheets must not hide the focused element |
| 2.5.7 Dragging Movements | AA | Every drag (reorder, slider, swipe-to-dismiss) needs a single-pointer alternative |
| 2.5.8 Target Size (Minimum) | AA | Targets at least [24 by 24 CSS pixels](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html), with spacing exceptions |
| 3.2.6 Consistent Help | A | Help and contact entry points in a consistent place |
| 3.3.7 Redundant Entry | A | Do not make users re-type what they already entered in the flow |
| 3.3.8 Accessible Authentication (Minimum) | AA | No cognitive-test logins; allow paste and password managers |

## Enforcement Is National, and Some of It Is Criminal

The directive leaves penalties to Member States but constrains them: "The penalties provided for shall be effective, proportionate and dissuasive," and they must take into account "the extent of the non-compliance, including its seriousness, and the number of units of non-complying products or services concerned, as well as the number of persons affected." That last clause matters for apps: a defect shipped to every user is, by construction, the widest possible non-compliance.

Two transpositions show the range:

| Member State | Instrument | Maximum exposure for a non-compliant service |
|---|---|---|
| Germany | [BFSG § 37](https://www.gesetze-im-internet.de/bfsg/__37.html) | Administrative fine up to EUR 100,000 for offering or providing a non-compliant service |
| Ireland | [S.I. No. 636/2023](https://www.irishstatutebook.ie/eli/2023/si/636/made/en/print) | On conviction on indictment, a fine up to EUR 60,000, imprisonment up to 18 months, or both |

The German text reads "mit einer Geldbuße bis zu hunderttausend Euro" for the service offence; the Irish regulation makes providing a non-compliant service a criminal offence. Neither number is the real cost. The real cost is the release you cannot ship into a market until the remediation is done.

## The Android Checklist, in Compose

Most of the work is not exotic. It is the fundamentals, applied everywhere, with the WCAG 2.2 additions on top:

- **Name every control, and silence decoration.** Compose's [semantics guide](https://developer.android.com/develop/ui/compose/accessibility/semantics) is explicit that an icon's `contentDescription` "conveys in text what the meaning of the icon is." Set it to `null` for decorative images: that tells the framework the element "does not have associated actions or state."
- **Size targets generously.** WCAG 2.2 sets a 24-pixel floor; Google's [Compose guidance](https://developer.android.com/develop/ui/compose/accessibility/api-defaults) says to "set the minimum size to 48dp to correctly follow the Material Design accessibility guidelines." Material components already do; custom clickable `Box`es are where targets shrink.
- **Give every drag a tap.** Reorderable lists, swipe-to-delete and custom sliders need a visible single-pointer alternative (2.5.7) and, for screen reader users, custom accessibility actions.
- **Group what belongs together.** A product card read as six separate focus stops is technically labelled and practically unusable; merge descendants and expose actions.
- **Mark structure.** Section titles as headings, so TalkBack users can jump between them.
- **Let authentication be pasted.** Support password managers and passkeys; never block paste on credential fields (3.3.8).

Each item on that list is worked through in code in [Jetpack Compose accessibility](https://android-x.com/blog/jetpack-compose-accessibility).

```kotlin
@Composable
fun ProductCard(product: Product, onAddToCart: () -> Unit, onFavourite: () -> Unit) {
    Card(
        Modifier.semantics(mergeDescendants = true) {
            // One focus stop for the card, with its secondary action exposed to TalkBack.
            customActions = listOf(
                CustomAccessibilityAction("Add to favourites") { onFavourite(); true }
            )
        }
    ) {
        Image(painterResource(product.imageRes), contentDescription = null) // decorative: the title names it
        Text(product.name, Modifier.semantics { heading() })
        Text(product.priceLabel)
        IconButton(onClick = onAddToCart) {                             // 48dp target by default
            Icon(Icons.Filled.Add, contentDescription = "Add ${product.name} to cart")
        }
    }
}

// 2.5.7 Dragging Movements: reordering must not require a drag.
@Composable
fun ReorderableRow(item: Item, index: Int, onMove: (from: Int, to: Int) -> Unit) {
    Row(
        Modifier.semantics {
            customActions = listOf(
                CustomAccessibilityAction("Move up") { onMove(index, index - 1); true },
                CustomAccessibilityAction("Move down") { onMove(index, index + 1); true },
            )
        }
    ) {
        Text(item.title, Modifier.weight(1f))
        IconButton(onClick = { onMove(index, index - 1) }) {            // visible single-pointer path
            Icon(Icons.Filled.KeyboardArrowUp, contentDescription = "Move ${item.title} up")
        }
    }
}
```

## Make Accessibility a Build Gate, Not an Audit

Annual audits find the same defects every year because nothing stops them from coming back. The fix is to make the common failures fail the build.

Since Compose 1.8.0, UI tests can run the Accessibility Test Framework automatically. The [testing guide](https://developer.android.com/develop/ui/compose/accessibility/testing) describes the setup: "add the ui-test-junit4-accessibility dependency, call enableAccessibilityChecks() in the AndroidComposeTestRule, and trigger an action or tryPerformAccessibilityChecks." Once enabled, any action such as `performClick` runs the checks as well, so existing UI tests become accessibility tests for free. View-based screens get the same from [Espresso](https://developer.android.com/training/testing/espresso/accessibility-checking): "You can enable and configure accessibility testing using the AccessibilityChecks class," and "by default, the checks run when you perform any view action defined in ViewActions."

Automation catches missing labels, small targets and low contrast. It does not catch a confusing focus order or a flow that is technically labelled and practically impossible. For that, keep two manual habits: a TalkBack walkthrough of every changed flow before release, and an [Accessibility Scanner](https://developer.android.com/guide/topics/ui/accessibility/testing) pass, which "uses the Accessibility Test Framework and provides specific suggestions after looking at content labels, clickable items, contrast, and more."

Then close the loop the directive asks for. Keep the test results, the walkthrough notes and the known-issues list together, because Article 13's duty to "explain how the services meet the applicable accessibility requirements" is much easier to discharge with evidence than with good intentions.

Where these checks sit among the other layers of a UI suite is covered in [Compose testing strategies](https://android-x.com/blog/compose-testing-strategies).

```kotlin
@get:Rule
val composeTestRule = createAndroidComposeRule<ComponentActivity>()

@Before
fun enableChecks() {
    composeTestRule.enableAccessibilityChecks()   // needs ui-test-junit4-accessibility, Compose 1.8.0+
}

@Test
fun checkout_isAccessible() {
    composeTestRule.setContent { CheckoutScreen(cart = sampleCart) }

    // Explicit check of the whole tree...
    composeTestRule.onRoot().tryPerformAccessibilityChecks()

    // ...and every action from here on is checked too.
    composeTestRule.onNodeWithText("Pay now").performClick()
}
```

## Key takeaways

- Since 28 June 2025 the EAA has covered consumer banking, e-commerce, e-books, passenger transport and electronic communications services, explicitly including their mobile apps.
- Only microenterprises providing services (fewer than 10 persons, EUR 2 million or less turnover or balance sheet) are exempt; legacy contracts run at most five years and products used before the date only until 28 June 2030.
- EN 301 549 v4.1.1, published September 2026, moves the benchmark to WCAG 2.2; v3.2.1 (WCAG 2.1 AA) remains the cited reference until v4.1.1 is cited in the Official Journal.
- Web views inside an app are assessed as software under clause 11, not as web pages.
- Penalties are national: up to EUR 100,000 in Germany, and a criminal offence with fines up to EUR 60,000 and up to 18 months in Ireland.
- Turn on enableAccessibilityChecks() in Compose tests and AccessibilityChecks in Espresso so common failures break the build.

## Frequently asked questions

### Does the European Accessibility Act apply to Android apps?

Yes, for in-scope consumer services. The directive names mobile device-based services, including mobile applications, for passenger transport, and its e-commerce definition covers services concluded through mobile apps. Consumer banking, e-books and electronic communications are also in scope. If your app sells to consumers in the European Union, assume it applies and then check the exemptions.

### Which WCAG version does the EAA require?

The directive sets outcomes, and the harmonised standard is EN 301 549. Version 3.2.1, based on WCAG 2.1 Level AA, remains the legal reference until the Commission cites version 4.1.1 in the Official Journal. Version 4.1.1 was published in September 2026 and adopts WCAG 2.2, so that is the level to build to now.

### Can Compose tests check accessibility automatically?

Yes, from Compose 1.8.0. Add the ui-test-junit4-accessibility dependency and call enableAccessibilityChecks() on the AndroidComposeTestRule. After that, any action in an existing UI test, such as performClick, also runs the Accessibility Test Framework checks. Automation finds missing labels, small targets and low contrast. It does not replace a manual pass with a screen reader.

## Related articles

- [Accessibility in Jetpack Compose: Building Apps Everyone Can Use](https://android-x.com/blog/jetpack-compose-accessibility.md)
- [Jetpack Compose Testing: Strategies for Bulletproof UI](https://android-x.com/blog/compose-testing-strategies.md)
- [Building a Design System with Jetpack Compose](https://android-x.com/blog/jetpack-compose-design-system.md)