SYSONLINE
SDK36 · MIN 24
KOTLIN2.0
UTC07:37:14
UP00:01
MOD · ARTICLE · ACCESSIBILITYS/N · AX-EUROPEPUBLISHED
AccessibilitySep 15, 202610 MIN

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 · Founder & Principal Consultant, Strategia-X

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, 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 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 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? Four Questions

The directive is precise about who it covers, and so should your scoping conversation be.
QuestionWhat the directive saysEngineering 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 datePlan 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, 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 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 at levels A and AA that land hardest on mobile:
CriterionLevelWhat it means in an Android app
2.4.11 Focus Not Obscured (Minimum)AASticky bars and sheets must not hide the focused element
2.5.7 Dragging MovementsAAEvery drag (reorder, slider, swipe-to-dismiss) needs a single-pointer alternative
2.5.8 Target Size (Minimum)AATargets at least 24 by 24 CSS pixels, with spacing exceptions
3.2.6 Consistent HelpAHelp and contact entry points in a consistent place
3.3.7 Redundant EntryADo not make users re-type what they already entered in the flow
3.3.8 Accessible Authentication (Minimum)AANo 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 StateInstrumentMaximum exposure for a non-compliant service
GermanyBFSG § 37Administrative fine up to EUR 100,000 for offering or providing a non-compliant service
IrelandS.I. No. 636/2023On 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 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 says to "set the minimum size to 48dp to correctly follow the Material Design accessibility guidelines." Material components already do; custom clickable Boxes 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).
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 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: "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 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.
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()
}
MOD · TAKEAWAYS6 POINTSSUMMARY

Key Takeaways

  1. 1Since 28 June 2025 the EAA has covered consumer banking, e-commerce, e-books, passenger transport and electronic communications services, explicitly including their mobile apps.
  2. 2Only 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.
  3. 3EN 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.
  4. 4Web views inside an app are assessed as software under clause 11, not as web pages.
  5. 5Penalties 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.
  6. 6Turn on enableAccessibilityChecks() in Compose tests and AccessibilityChecks in Espresso so common failures break the build.
MOD · FAQ3 ENTRIESANSWERED

Frequently Asked

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. Banking, e-books and electronic communications are also in scope.

Which WCAG version does the EAA require?

The directive sets outcomes; the harmonised standard is EN 301 549. v3.2.1 (WCAG 2.1 AA) remains the cited reference until the Commission cites v4.1.1, published September 2026, which adopts WCAG 2.2.

Can Compose tests check accessibility automatically?

Yes, from Compose 1.8.0. Add ui-test-junit4-accessibility, call enableAccessibilityChecks() on the AndroidComposeTestRule, and actions or tryPerformAccessibilityChecks() run the Accessibility Test Framework.

MOD · BUILD · NEXTS/N · AX-CTA-0001READY

Ready to architect your next Android app?

ANDROID-ARCHITECT generates production-ready Kotlin code, architecture blueprints, and CI/CD configurations from plain-language descriptions. Start building for free.

ANDROID-ARCHITECT · CONSOLE
S/N · AX-1A-00001
STRATEGIA-X · ENGINEERED · IN · CALIFORNIA