European Accessibility Act: what it means for a mobile app

Since June 28, 2025, the European Accessibility Act (Directive (EU) 2019/882) has required certain services provided to consumers to be accessible to people with disabilities, and the text explicitly covers the mobile apps used to provide those services. In practice, an e-commerce, banking, transport ticketing or e-reading app must be usable with a screen reader, with enlarged text or with an external keyboard. Most of the fixes are technical and within reach of a mobile team, as long as the work is organized.

This article reflects the situation as of October 2026: what the text says, and above all what makes an app accessible in practice, with React Native and Capacitor examples.

What does the European Accessibility Act say?

The European Accessibility Act is Directive (EU) 2019/882, which harmonizes accessibility requirements for a list of products and services sold in the European Union. Under Article 31 of Directive (EU) 2019/882 on EUR-Lex, Member States had to transpose it by June 28, 2022 at the latest and apply its rules from June 28, 2025.

Covered services

Article 2(2) of Directive (EU) 2019/882 lists the services covered when they are provided to consumers after June 28, 2025:

Mobile apps are named explicitly for transport ("mobile device-based services including mobile applications") and in the definition of e-commerce services, which covers services provided "through websites and mobile device-based services" (Article 3(30)). For urban, suburban and regional transport, only interactive self-service terminals are covered.

Article 2(4) also excludes certain website and app content, for example pre-recorded time-based media published before June 28, 2025, or third-party content that is neither funded, developed nor controlled by the operator.

The microenterprise exemption

Microenterprises providing services are exempt from the accessibility requirements applicable to services (Article 4(5)). Under the directive, a microenterprise is a company that employs fewer than ten people and whose annual turnover or annual balance sheet total does not exceed €2 million (Article 3(23)).

Transitional measures

Article 32 of Directive (EU) 2019/882 provides for a transitional period ending on June 28, 2030: service providers may continue to provide their services using products they were lawfully using before that date to provide similar services. Service contracts agreed before June 28, 2025 may continue unaltered until they expire, but for no longer than five years from that date. This period is not a general postponement for apps.

Informing users

Service providers must also prepare information on how the service meets the accessibility requirements and make it available to the public, for example in their general terms and conditions (Article 13 and Annex V).

Which technical standard should a mobile app follow for accessibility?

For a mobile app, the technical reference commonly used in Europe is the EN 301 549 standard, because the European Accessibility Act sets functional requirements without dictating code. Annex I of the directive requires the service to be perceivable, operable, understandable and robust, and Article 15 presumes conformity for services that meet harmonized standards published in the Official Journal of the EU.

EN 301 549 is the European standard that defines accessibility requirements for digital products and services. Its version 3.2.1 incorporates the WCAG 2.1 Level AA criteria for the web, and includes a chapter dedicated to software, mobile apps included. The W3C WAI lists the related European policies. Standards evolve: check which reference version is in force at the time of your audit.

How do you make a mobile app accessible in practice?

An accessible mobile app can be used with a screen reader, with enlarged text and with an external keyboard, and has sufficient contrast and explicit forms. The WCAG 2.1 criteria cited below come from the W3C WCAG 2.1 quick reference, and the React Native examples from the React Native Accessibility documentation.

Screen readers: VoiceOver and TalkBack

A screen reader is software that reads interface elements aloud: VoiceOver on iOS, TalkBack on Android. Every interactive element therefore needs an understandable name, a role and a state. A "heart" icon without a label will be announced as "button" or not at all. In React Native:

<Pressable
  onPress={toggleFavorite}
  accessibilityRole="button"
  accessibilityLabel="Add to favorites"
  accessibilityHint="Saves this product to your list"
  accessibilityState={{ selected: isFavorite }}
>
  <HeartIcon />
</Pressable>

<Text accessibilityRole="header">Your cart</Text>

<View accessible accessibilityLabel={`${product.name}, ${product.price} euros`}>
  <Text>{product.name}</Text>
  <Text>{product.price} €</Text>
</View>

The accessible property groups elements into a single block read in one go. Purely decorative images should be hidden (accessibilityElementsHidden on iOS, importantForAccessibility="no-hide-descendants" on Android, or aria-hidden). React Native also accepts the role and aria-label props, which are closer to the web.

In a Capacitor app, the interface is HTML: semantic HTML does most of the work, and ARIA fills the gaps when needed.

<button type="button" aria-label="Add to favorites" aria-pressed="false">
  <svg aria-hidden="true">...</svg>
</button>

<h1>Your cart</h1>

<div role="status" aria-live="polite">Item added to cart</div>

A clickable div is neither announced as a button nor reachable by keyboard: always prefer button and a.

Dynamic text sizes

Users enlarge text in the system settings. WCAG 2.1 criterion 1.4.4 requires text to remain readable up to 200% without loss of content. In React Native, don't disable allowFontScaling on body text, avoid fixed heights on text containers and test with the largest size. On the Capacitor side, use relative units (rem) rather than fixed pixels.

Contrast

WCAG 2.1 requires a minimum ratio of 4.5:1 for body text and 3:1 for large text (criterion 1.4.3), and 3:1 for interface components and meaningful icons (criterion 1.4.11). Light gray text on a white background and unreadable disabled buttons are the most common defects. Never convey information through color alone: a field in error must also display a message.

Touch targets

WCAG 2.1 AA does not set a minimum target size, but Apple recommends at least 44 x 44 points and Android 48 x 48 dp. In React Native, hitSlop enlarges the touch area of a small icon without changing its appearance.

External keyboard navigation

Every function must be operable by keyboard (criterion 2.1.1), with a visible focus (criterion 2.4.7). On mobile, this covers Bluetooth keyboards and switch access devices (Switch Control on iOS, Switch Access on Android). Check the focus order, make sure modal windows do not trap focus and that they can be closed.

Forms and error messages

Every field must have a visible, announced label (criterion 3.3.2), and every error must be described in text (criterion 3.3.1). A placeholder is not a label. Announce important errors and confirmations: AccessibilityInfo.announceForAccessibility("Payment declined, check the expiration date") in React Native, according to the AccessibilityInfo documentation, or an aria-live region on the web.

<Text nativeID="emailLabel">Email address</Text>
<TextInput
  accessibilityLabel="Email address"
  accessibilityLabelledBy="emailLabel"
  autoComplete="email"
  keyboardType="email-address"
/>
{error && <Text accessibilityLiveRegion="polite">{error}</Text>}

Animation and motion

Automatic animations lasting more than five seconds must be pausable (criterion 2.2.2). Also respect the "Reduce Motion" setting: AccessibilityInfo.isReduceMotionEnabled() in React Native, the prefers-reduced-motion media query on the web.

Video and audio content

Pre-recorded videos must have captions (criterion 1.2.2). Videos on your home screens, tutorials and product pages are the first concern.

How do you test a mobile app's accessibility in 30 minutes?

A first accessibility test of a mobile app takes 30 minutes with an iPhone, an Android device and the accessibility settings built into both systems. Pick your main user flow (sign-up, purchase, booking).

1. Turn on VoiceOver (iOS), then TalkBack (Android), and go through the flow without looking at the screen: is every button announced with a clear name?
2. Set the text size to the maximum: is any text truncated or hidden?
3. Turn on dark mode and increased contrast: does everything remain readable?
4. Connect a Bluetooth keyboard and move through the screen with Tab: is the focus visible and logical?
5. Submit an empty form: are the errors described in text and announced?
6. Turn on "Reduce Motion": do decorative animations stop?
7. Run Accessibility Inspector (Xcode) and Accessibility Scanner (Android) on three key screens.

These tests do not replace a full audit, but they usually reveal the major issues.

How do you organize the accessibility work on a mobile app?

Making a mobile app accessible comes down to four steps: audit, prioritization, fixes in the shared components, then integration into the development process.

1. Audit: assess the critical flows on both platforms against the chosen reference standard, with a list of reproducible defects.
2. Prioritization: first fix what blocks a flow (payment impossible with a screen reader), then what hinders it.
3. Fixes: many are made at the level of shared components (button, field, product card), which fixes dozens of screens at once.
4. Continuous integration: add accessibility criteria to the definition of "done", test every new feature with VoiceOver and TalkBack, and keep the published information about the service's accessibility up to date.

For more on public standards and resources in France, the French government's accessibilite.numerique.gouv.fr site (DINUM) centralizes the documentation.

Get your mobile app's accessibility audited

GUIGUI Tech's mobile app accessibility audit tests your app on iPhone and Android and delivers a prioritized, costed remediation plan, for €1,500 excl. VAT in 5 business days. It is a technical audit and does not constitute legal advice.