European Accessibility Act : ce que ça change pour une application mobile

Le European Accessibility Act (directive (UE) 2019/882) exige, depuis le 28 juin 2025, que certains services fournis aux consommateurs soient accessibles aux personnes handicapées, et le texte vise explicitement les applications mobiles qui servent à fournir ces services. Concrètement, une app de commerce en ligne, de banque, de billetterie de transport ou de lecture numérique doit pouvoir être utilisée avec un lecteur d'écran, avec un texte agrandi ou avec un clavier externe. La plupart des corrections sont techniques et à la portée d'une équipe mobile, à condition de les organiser.

Cet article fait le point à la date d'octobre 2026 : ce que dit le texte, puis surtout ce qui rend une app accessible en pratique, avec des exemples React Native et Capacitor.

Que dit le European Accessibility Act ?

Le European Accessibility Act est la directive (UE) 2019/882, qui harmonise des exigences d'accessibilité pour une liste de produits et de services vendus dans l'Union européenne. Selon l'article 31 de la directive (UE) 2019/882 sur EUR-Lex, les États membres devaient la transposer au plus tard le 28 juin 2022 et appliquer ces règles à partir du 28 juin 2025.

Les services visés

L'article 2, paragraphe 2, de la directive (UE) 2019/882 liste les services concernés lorsqu'ils sont fournis aux consommateurs après le 28 juin 2025 :

Les applications mobiles sont citées en toutes lettres pour le transport (« services intégrés sur appareils mobiles, y compris les applications mobiles ») et dans la définition des services de commerce électronique, qui inclut les services fournis « via des sites internet, des services intégrés sur des appareils mobiles » (article 3, point 30). Pour les transports urbains, suburbains et régionaux, seuls les terminaux en libre-service interactifs sont visés.

L'article 2, paragraphe 4, exclut par ailleurs certains contenus des sites et applications, par exemple les médias temporels préenregistrés publiés avant le 28 juin 2025, ou les contenus de tiers qui ne sont ni financés, ni développés, ni contrôlés par l'opérateur.

L'exemption des microentreprises

Les microentreprises qui proposent des services sont exonérées des exigences d'accessibilité applicables aux services (article 4, paragraphe 5). Une microentreprise est, au sens de la directive, une entreprise qui emploie moins de dix personnes et dont le chiffre d'affaires annuel ou le total du bilan annuel n'excède pas 2 millions d'euros (article 3, point 23).

Les mesures transitoires

L'article 32 de la directive (UE) 2019/882 prévoit une période transitoire s'achevant le 28 juin 2030 : les prestataires peuvent continuer à fournir leurs services avec des produits qu'ils utilisaient légalement avant cette date pour des services similaires. Les contrats de services conclus avant le 28 juin 2025 peuvent courir sans modification jusqu'à leur expiration, dans la limite de cinq ans à compter de cette date. Cette période ne constitue pas un report général pour les applications.

Information des utilisateurs

Les prestataires de services doivent aussi établir des informations sur la manière dont le service répond aux exigences d'accessibilité et les mettre à disposition du public, par exemple dans leurs conditions générales (article 13 et annexe V).

Quelle norme technique suivre pour l'accessibilité d'une application mobile ?

Pour une application mobile, le référentiel technique couramment utilisé en Europe est la norme EN 301 549, car le European Accessibility Act fixe des exigences fonctionnelles sans dicter de code. L'annexe I de la directive demande de rendre le service perceptible, utilisable, compréhensible et robuste, et l'article 15 présume conformes les services qui respectent des normes harmonisées publiées au Journal officiel de l'UE.

La norme EN 301 549 est la norme européenne qui définit des exigences d'accessibilité pour les produits et services numériques. Sa version 3.2.1 reprend les critères WCAG 2.1 de niveau AA pour le web, et contient un chapitre dédié aux logiciels, applications mobiles comprises. Le W3C WAI recense les politiques européennes qui s'y rapportent. Les normes évoluent : vérifiez la version de référence en vigueur au moment de votre audit.

Comment rendre une application mobile accessible, concrètement ?

Une application mobile accessible est utilisable avec un lecteur d'écran, avec un texte agrandi, au clavier externe, avec des contrastes suffisants et des formulaires explicites. Les critères WCAG 2.1 cités ci-dessous proviennent de la référence rapide WCAG 2.1 du W3C, et les exemples React Native de la documentation Accessibility de React Native.

Lecteurs d'écran : VoiceOver et TalkBack

Un lecteur d'écran est un logiciel qui lit à voix haute les éléments de l'interface : VoiceOver sur iOS, TalkBack sur Android. Chaque élément interactif doit donc avoir un nom compréhensible, un rôle et un état. Une icône « cœur » sans libellé sera annoncée « bouton » ou pas du tout. En React Native :

<Pressable
  onPress={toggleFavorite}
  accessibilityRole="button"
  accessibilityLabel="Ajouter aux favoris"
  accessibilityHint="Enregistre ce produit dans votre liste"
  accessibilityState={{ selected: isFavorite }}
>
  <HeartIcon />
</Pressable>

<Text accessibilityRole="header">Votre panier</Text>

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

La propriété accessible regroupe des éléments en un seul bloc lu d'une traite. Les images purement décoratives doivent être masquées (accessibilityElementsHidden sur iOS, importantForAccessibility="no-hide-descendants" sur Android, ou aria-hidden). React Native accepte aussi les props role et aria-label, plus proches du web.

Pour une app Capacitor, l'interface est du HTML : le HTML sémantique fait l'essentiel du travail, et ARIA complète quand c'est nécessaire.

<button type="button" aria-label="Ajouter aux favoris" aria-pressed="false">
  <svg aria-hidden="true">...</svg>
</button>

<h1>Votre panier</h1>

<div role="status" aria-live="polite">Article ajouté au panier</div>

Un div cliquable n'est ni annoncé comme un bouton, ni atteignable au clavier : préférez toujours button et a.

Tailles de texte dynamiques

Les utilisateurs agrandissent le texte dans les réglages du système. Le critère 1.4.4 des WCAG 2.1 demande que le texte reste lisible jusqu'à 200 % sans perte de contenu. En React Native, ne désactivez pas allowFontScaling sur les textes courants, évitez les hauteurs fixes sur les conteneurs de texte et testez avec la plus grande taille. Côté Capacitor, utilisez des unités relatives (rem) plutôt que des pixels figés.

Contrastes

Les WCAG 2.1 exigent un ratio minimal de 4,5:1 pour le texte courant et de 3:1 pour le grand texte (critère 1.4.3), et de 3:1 pour les composants d'interface et icônes porteuses de sens (critère 1.4.11). Les textes gris clair sur fond blanc et les boutons désactivés illisibles sont les défauts les plus fréquents. Ne transmettez jamais une information par la seule couleur : un champ en erreur doit aussi afficher un message.

Zones tactiles

WCAG 2.1 AA ne fixe pas de taille minimale de cible, mais Apple recommande au moins 44 x 44 points et Android 48 x 48 dp. En React Native, hitSlop agrandit la zone tactile d'une petite icône sans changer son apparence.

Navigation au clavier externe

Toutes les fonctions doivent être utilisables au clavier (critère 2.1.1), avec un focus visible (critère 2.4.7). Sur mobile, cela concerne les claviers Bluetooth et les dispositifs de contrôle de sélection (Switch Control, Accès via contacteur). Vérifiez l'ordre de parcours, l'absence de piège dans les fenêtres modales et la possibilité de les fermer.

Formulaires et messages d'erreur

Chaque champ doit avoir un libellé visible et annoncé (critère 3.3.2), et chaque erreur doit être décrite en texte (critère 3.3.1). Un placeholder n'est pas un libellé. Annoncez les erreurs et confirmations importantes : AccessibilityInfo.announceForAccessibility("Paiement refusé, vérifiez la date d'expiration") en React Native, selon la documentation AccessibilityInfo, ou une zone aria-live en web.

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

Animations et mouvements

Les animations automatiques de plus de cinq secondes doivent pouvoir être mises en pause (critère 2.2.2). Respectez aussi le réglage « Réduire les animations » : AccessibilityInfo.isReduceMotionEnabled() en React Native, la media query prefers-reduced-motion en web.

Vidéos et contenus audio

Les vidéos préenregistrées doivent être sous-titrées (critère 1.2.2). Les contenus vidéo de vos écrans d'accueil, tutoriels ou fiches produits sont concernés au premier chef.

Comment tester l'accessibilité d'une application mobile en 30 minutes ?

Un premier test d'accessibilité d'une application mobile se fait en 30 minutes avec un iPhone, un Android et les réglages d'accessibilité intégrés aux deux systèmes. Choisissez votre parcours principal (inscription, achat, réservation).

1. Activez VoiceOver (iOS) puis TalkBack (Android) et faites le parcours sans regarder l'écran : chaque bouton est-il annoncé avec un nom clair ?
2. Passez la taille de texte au maximum : du texte est-il tronqué ou masqué ?
3. Activez le mode sombre et le contraste renforcé : tout reste-t-il lisible ?
4. Connectez un clavier Bluetooth et parcourez l'écran avec Tab : le focus est-il visible et logique ?
5. Soumettez un formulaire vide : les erreurs sont-elles décrites en texte et annoncées ?
6. Activez « Réduire les animations » : les animations décoratives s'arrêtent-elles ?
7. Lancez Accessibility Inspector (Xcode) et Accessibility Scanner (Android) sur trois écrans clés.

Ces tests ne remplacent pas un audit complet, mais révèlent en général les problèmes majeurs.

Comment organiser la mise en accessibilité d'une application mobile ?

La mise en accessibilité d'une application mobile s'organise en quatre étapes : audit, priorisation, corrections dans les composants partagés, puis intégration dans le processus de développement.

1. Audit : évaluer les parcours critiques sur les deux plateformes par rapport au référentiel retenu, avec une liste de défauts reproductibles.
2. Priorisation : traiter d'abord ce qui bloque un parcours (paiement impossible au lecteur d'écran), puis ce qui le gêne.
3. Corrections : beaucoup se font au niveau des composants partagés (bouton, champ, carte produit), ce qui corrige des dizaines d'écrans d'un coup.
4. Intégration continue : ajouter des critères d'accessibilité à la définition de « terminé », tester chaque nouvelle fonctionnalité avec VoiceOver et TalkBack, et mettre à jour les informations publiées sur l'accessibilité du service.

Pour aller plus loin sur les référentiels et ressources publiques en France, le site accessibilite.numerique.gouv.fr de la DINUM centralise la documentation.

Faire auditer l'accessibilité de votre application mobile

L'audit accessibilité application mobile de GUIGUI Tech teste votre app sur iPhone et Android et livre un plan de corrections priorisé et chiffré, pour 1 500€ HT en 5 jours ouvrés. Il s'agit d'un audit technique, qui ne constitue pas un avis juridique.