L’accessibilité des applications mobiles selon l’European Accessibility Act (EAA) signifie que les applications utilisées pour fournir les services couverts par ce texte, comme l’achat en ligne, les services bancaires aux particuliers, les livres numériques et le transport de voyageurs, doivent être utilisables par les personnes handicapées, y compris celles qui s’appuient sur un lecteur d’écran, un texte agrandi, la commande vocale ou un contacteur. Depuis le 28 juin 2025, ces exigences s’appliquent dans toute l’UE, et la référence pratique pour les respecter est la norme harmonisée qui s’appuie sur les Web Content Accessibility Guidelines. Ce guide explique quelles applications sont concernées, ce que les exigences signifient en design et en code, par où commencer et comment mesurer les progrès.
Dernière mise à jour : 9 novembre 2026.
Qu’est-ce que l’European Accessibility Act ?
L’European Accessibility Act est une directive européenne qui fixe des exigences d’accessibilité communes pour une liste de produits et de services vendus aux consommateurs. Son texte officiel est la directive (UE) 2019/882, et ses règles s’appliquent depuis le 28 juin 2025. Chaque État membre l’a transposée dans son droit national ; en Allemagne, par exemple, elle prend la forme du Barrierefreiheitsstärkungsgesetz (BFSG).
L’objectif est simple : les personnes handicapées et les personnes âgées doivent pouvoir acheter et utiliser les mêmes services numériques du quotidien que tout le monde, et les entreprises doivent respecter un seul ensemble de règles dans tout le marché unique plutôt qu’un ensemble différent dans chaque pays.
Chez Odduel, agence créative et technologique à Barcelone et São Paulo, l’accessibilité fait partie de la façon dont nous planifions, concevons et développons les applications dans notre service de développement d’applications, et non d’un test ajouté à la fin.
En bref : l’European Accessibility Act couvre les applications qui fournissent des services entrant dans son champ, comme l’e-commerce, les services bancaires aux particuliers, les livres numériques et le transport de voyageurs. Ces applications doivent être perceptibles, utilisables, compréhensibles et robustes pour les personnes handicapées. Commencez par un audit au regard de la norme harmonisée, corrigez d’abord les parcours les plus utilisés, intégrez l’accessibilité au design et au code, et publiez les informations d’accessibilité requises.
L’EAA s’applique-t-il aux applications ?
Oui. La directive couvre les services fournis aux consommateurs dans plusieurs secteurs, et elle inclut explicitement les services fournis via des appareils mobiles, y compris les applications mobiles. Si votre application est le moyen par lequel vos clients accèdent à un service couvert, elle entre dans le champ.
Les services couverts comprennent :
- Services de commerce électronique : les applications par lesquelles les consommateurs achètent des produits ou des services en ligne.
- Services bancaires aux consommateurs : applications bancaires et de paiement destinées aux particuliers.
- Les livres numériques et les logiciels de lecture dédiés.
- Les services de communications électroniques, comme les services d’appel et de messagerie.
- Les services donnant accès à des médias audiovisuels, comme les plateformes de streaming.
- Certains éléments des services de transport aérien, par autobus, ferroviaire et par voie de navigation, y compris les applications, la billetterie et l’information voyageurs en temps réel.
La directive couvre aussi certains produits, comme les smartphones, les ordinateurs, les terminaux de paiement et les automates de billetterie, mais les obligations d’un développeur ou d’un propriétaire d’application découlent surtout des services ci-dessus.
Quelles applications sont généralement hors du champ ?
Les applications qui ne fournissent pas de service couvert aux consommateurs sont en général hors du champ, comme les outils purement internes ou les applications qui ne donnent que des informations sur une entreprise. Les microentreprises qui fournissent des services, au sens de la directive, sont exemptées des exigences relatives aux services. Les applications du secteur public relèvent d’un autre texte, la directive sur l’accessibilité des sites web. Les questions de champ peuvent être subtiles : faites confirmer votre situation par un conseiller juridique sur votre marché principal.
Existe-t-il des périodes de transition ?
La directive prévoit certaines transitions. Les prestataires peuvent continuer à fournir leurs services avec des produits qu’ils utilisaient légalement avant le 28 juin 2025 jusqu’au 28 juin 2030, et les contrats de service conclus avant cette date peuvent se poursuivre jusqu’à leur échéance, dans une limite de cinq ans. Ces périodes ne couvrent ni les nouvelles applications ni les nouvelles versions : tout ce que vous concevez ou lancez maintenant doit respecter les exigences.
Que recouvre concrètement l’accessibilité d’une application selon l’EAA ?
La directive décrit les exigences en termes fonctionnels : l’information doit être perceptible, utilisable, compréhensible et robuste, et le service doit fonctionner avec les technologies d’assistance que les gens utilisent. En pratique, les entreprises y répondent en suivant la norme européenne harmonisée sur l’accessibilité numérique, EN 301 549, qui reprend ses critères pour le web et les logiciels des Web Content Accessibility Guidelines du W3C et les applique aux applications natives comme aux sites web.
Le tableau traduit les quatre principes dans le design et le développement d’une application au quotidien.
| Principe | Ce que cela signifie dans une application | Défauts fréquents |
|---|---|---|
| Perceptible | Alternatives textuelles pour les images et les icônes, contraste suffisant, texte qui suit les réglages du système, sous-titres pour les vidéos | Boutons avec une icône seule et sans libellé ; texte qui ne s’agrandit pas ; texte gris peu contrasté |
| Utilisable | Toutes les fonctions utilisables avec un lecteur d’écran, un contacteur et un clavier externe ; zones tactiles assez grandes ; pas de limite de temps sans contrôle | Gestes personnalisés sans alternative ; zones tactiles minuscules ; carrousels impossibles à mettre en pause |
| Compréhensible | Libellés et instructions clairs, navigation cohérente, messages d’erreur utiles | Erreurs de formulaire signalées seulement en rouge ; libellés vagues comme « Valider » pour chaque action |
| Robuste | Usage correct des fonctions d’accessibilité de la plateforme pour que les technologies d’assistance lisent rôles, noms et états | Composants personnalisés que les lecteurs d’écran annoncent comme « bouton » sans nom |
Qu’est-ce que cela change pour le design ?
Les designers fixent l’essentiel de l’accessibilité d’une application avant qu’une ligne de code existe. Les décisions clés :
- le contraste des couleurs pour le texte, les icônes et les commandes, en mode clair comme en mode sombre ;
- des mises en page qui fonctionnent encore quand le texte est fortement agrandi ;
- des zones tactiles assez grandes pour être atteintes sans erreur ;
- un ordre de focus visible qui suit l’ordre visuel ;
- des libellés et des instructions rédigés simplement ;
- des alternatives aux gestes complexes comme le balayage, le glisser-déposer et le pincement ;
- des états (sélectionné, désactivé, erreur) signalés autrement que par la seule couleur.
Qu’est-ce que cela change pour le développement ?
Les développeurs s’assurent que les fonctions d’accessibilité de la plateforme portent l’intention du design. Sur iOS et Android, cela signifie utiliser autant que possible les composants natifs, donner à chaque commande un nom, un rôle et un état accessibles, prendre en charge la taille de texte dynamique, gérer le focus quand les écrans ou les boîtes de dialogue changent, annoncer les mises à jour importantes et tester avec VoiceOver et TalkBack. Les frameworks multiplateformes prennent aussi en charge l’accessibilité, mais chacun demande du soin avec les composants personnalisés.
Par où une entreprise doit-elle commencer pour rendre son application accessible selon l’European Accessibility Act ?
Un plan structuré évite à la fois la panique et la paralysie. Ces étapes conviennent à la plupart des entreprises.
- Confirmez le champ. Listez les services que fournissent vos applications et confrontez-les aux catégories de la directive avec votre conseiller juridique.
- Auditez l’application actuelle. Testez-la au regard d’EN 301 549 et des WCAG, en combinant contrôles automatisés et tests manuels avec lecteur d’écran, texte agrandi et contacteur.
- Cartographiez les parcours clés. Inscription, connexion, recherche, fiche produit, panier, commande, paiement, compte et support : les chemins que chaque client doit pouvoir terminer.
- Priorisez les corrections. Commencez par les obstacles qui bloquent complètement ces parcours, puis les problèmes qui les rendent très difficiles, puis les points mineurs.
- Corrigez le design system. Corrigez les composants une seule fois (boutons, champs, boîtes de dialogue, navigation) pour que les correctifs se propagent dans toute l’application.
- Changez le processus. Ajoutez des critères d’accessibilité aux maquettes, aux user stories, à la revue de code et aux tests de version pour que les nouvelles fonctionnalités ne réintroduisent pas d’obstacles.
- Publiez les informations d’accessibilité. La directive impose aux prestataires de services d’indiquer comment leur service répond aux exigences d’accessibilité, généralement dans une déclaration d’accessibilité ou dans les conditions générales.
- Proposez un moyen de signalement. Donnez aux utilisateurs une façon claire de signaler les obstacles, et agissez sur ce qu’ils signalent.
Les mêmes principes s’appliquent à votre site web ; notre guide sur l’accessibilité des sites web et l’European Accessibility Act traite le volet web en détail.
Comment mesurer l’accessibilité d’une application ?
La mesure doit combiner la conformité aux normes et l’usage réel.
| Méthode | Ce qu’il montre | Limites |
|---|---|---|
| Analyse automatisée | Libellés manquants, problèmes de contraste, certains défauts de structure | Ne détecte qu’une partie des problèmes |
| Audit manuel par un expert | Conformité à chaque critère de la norme | Dépend de la compétence de l’auditeur et de la couverture |
| Tests avec technologies d’assistance | Les parcours fonctionnent-ils avec VoiceOver, TalkBack, un contacteur, un texte agrandi ? | Demande des testeurs formés |
| Tests avec des utilisateurs handicapés | De vraies personnes accomplissent-elles les tâches avec leur propre équipement ? | Demande de l’organisation et du recrutement |
| Retours et données du support | Les obstacles rencontrés par les utilisateurs après la mise en ligne | Arrive une fois le problème déjà présent |
Indicateurs utiles dans la durée : le nombre de problèmes d’accessibilité ouverts par gravité, la part des parcours clés qui passent les tests manuels sur les deux plateformes et le délai de correction des obstacles signalés.
Que se passe-t-il si une application n’est pas conforme ?
Le contrôle est national. Chaque État membre a désigné des autorités de surveillance du marché qui peuvent contrôler les services, exiger des corrections et appliquer les sanctions prévues par le droit national. Règles et sanctions diffèrent donc d’un pays à l’autre. Au-delà du contrôle, une application inaccessible exclut des clients, génère des demandes au support et peut nuire à l’image d’une marque. Traitez la conformité comme un élément de la qualité du produit plutôt que comme une formalité juridique ponctuelle.
Que demander à un partenaire de développement d’applications sur l’accessibilité ?
Si vous travaillez avec une équipe extérieure, posez ces questions avant de signer :
- Comment intégrez-vous l’accessibilité au design, au développement et aux tests ?
- Au regard de quelle norme testerez-vous, et comment présenterez-vous les résultats ?
- Testez-vous avec VoiceOver et TalkBack sur de vrais appareils ?
- Comment gérez-vous l’accessibilité des composants personnalisés et des frameworks multiplateformes ?
- Nous aiderez-vous à préparer les informations d’accessibilité exigées par la directive ?
Notre guide sur comment choisir une agence de développement d’applications couvre plus largement le processus de sélection.
Questions fréquentes
L’European Accessibility Act s’applique-t-il aux applications mobiles ?
Oui. Le texte couvre les services fournis aux consommateurs dans des secteurs comme l’e-commerce, les services bancaires aux particuliers, les livres numériques, les communications électroniques, l’accès aux médias audiovisuels et le transport de voyageurs, et il inclut explicitement les services fournis via des applications mobiles. Si votre application est le moyen d’accéder à l’un de ces services, elle doit respecter les exigences d’accessibilité.
Quelle norme les applications doivent-elles suivre pour respecter l’EAA ?
Les entreprises suivent généralement EN 301 549, la norme européenne harmonisée sur l’accessibilité numérique. Ses critères pour les contenus web et les logiciels s’appuient sur les Web Content Accessibility Guidelines du W3C et s’appliquent aux applications mobiles natives comme aux sites web. La conformité à la norme harmonisée vaut présomption de conformité aux exigences correspondantes.
Par où une entreprise doit-elle commencer pour rendre son application accessible ?
Vérifiez si votre application fournit un service couvert, puis auditez-la au regard de la norme avec des tests automatisés et manuels, y compris au lecteur d’écran. Priorisez les obstacles sur les parcours clés comme la connexion, la recherche et la commande, corrigez d’abord les composants partagés, intégrez l’accessibilité à votre processus et publiez les informations d’accessibilité requises.
Les petites entreprises sont-elles exemptées de l’EAA ?
Les microentreprises qui fournissent des services, au sens de la directive, sont exemptées de ses exigences relatives aux services. Les autres petites et moyennes entreprises sont concernées si elles fournissent des services entrant dans son champ. Les définitions comptant beaucoup, vérifiez votre situation avec un conseiller juridique dans le pays où vous exercez principalement.
Comment tester l’accessibilité d’une application ?
Combinez analyses automatisées et tests manuels. Utilisez VoiceOver sur iOS et TalkBack sur Android, agrandissez le texte du système, testez avec un clavier externe ou un contacteur, vérifiez le contraste et les libellés, et parcourez chaque parcours clé. Les tests avec des utilisateurs handicapés donnent l’image la plus claire de la capacité réelle des gens à accomplir leurs tâches.
Commencez par vérifier le champ d’application et par auditer les parcours clés de votre application ; ensemble, ils montrent l’ampleur du travail à venir. Si vous avez besoin d’une application conçue et développée pour être accessible dès le premier écran, découvrez notre service de développement d’applications ou contactez-nous pour parler de votre application. Cet article est une information générale, pas un conseil juridique.
