Application mobile : quelle accessibilité, quel référentiel ?

L’essentielUne application mobile publique doit être accessible depuis le 23 juin 2021. La méthode du RGAA ne couvre pas les applications natives : la DINUM renvoie directement à la norme européenne EN 301 549, dont le chapitre 11 traite des logiciels. Une boutique qui vend par son application relève, elle, de l’European Accessibility Act et de la même norme.

Le RGAA s’applique-t-il à une application mobile ?

L’obligation, oui. La méthode de test, non. Il faut distinguer les deux.

• L’obligation. L’article 47 de la loi de 2005 vise les applications mobiles des organismes publics. Le RGAA les définit comme tout logiciel d’application conçu pour être utilisé sur des appareils mobiles, comme les smartphones et les tablettes, hors système d’exploitation ou matériel.
• La méthode. Son introduction le dit en toutes lettres : la méthode technique du RGAA 4.1 ne couvre pas les applications mobiles natives, les progiciels et le mobilier urbain numérique. Pour ces services, il faut vérifier directement la norme EN 301 549.

Un site consulté sur un téléphone reste un site web. Il relève de la méthode du RGAA. Son environnement de test prévoit d’ailleurs deux combinaisons mobiles : TalkBack avec Chrome sur Android, et VoiceOver avec Safari sur iOS. Pour un site public mobile, tester les deux est « fortement conseillé ».

Que demande la norme EN 301 549 pour une application ?

Elle fixe des exigences par type de produit. Pour une application native, la DINUM cite cinq parties de la norme : exigences génériques (5), communication vocale bidirectionnelle (6), capacités vidéo (7), matériels (8) et logiciels (11).

Le chapitre 11 est le cœur du sujet. Dans la version V3.2.1 de 2021, il vise expressément les applications mobiles. Il suit les quatre principes des WCAG : perceptible, utilisable, compréhensible, robuste. Il ajoute trois sections propres aux logiciels :

• l’interopérabilité avec les technologies d’assistance (11.5), comme un lecteur d’écran ;
• la documentation des fonctions d’accessibilité (11.6) ;
• le respect des préférences de l’utilisateur (11.7), comme la taille du texte choisie dans les réglages.

L’annexe A de la norme contient un tableau dédié aux applications mobiles. Il rassemble les exigences liées à la directive (UE) 2016/2102 sur les sites et applications du secteur public.

Site web et application native : ce qui change

Sujet	Site web, même sur mobile	Application native
Méthode de vérification	RGAA 4.1.2, 106 critères	Norme EN 301 549, notamment le chapitre 11
Tests avec lecteur d’écran	Combinaisons de l’environnement de test du RGAA	VoiceOver sur iPhone, TalkBack sur Android, sur un appareil réel
Déclaration d’accessibilité	Sur le site, avec la mention en page d’accueil	Sur le site de l’organisme ou avec les informations de téléchargement
État de conformité	Dans la déclaration et la mention	Précisé au sein de l’application

Depuis quand une application publique doit-elle être accessible ?

Depuis le 23 juin 2021 pour les organismes publics et les délégataires de service public. Pour les entreprises au-delà de 250 millions d’euros de chiffre d’affaires en France, la date est le 1er juillet 2021. Ces dates figurent à l’article 10 du décret n° 2019-768. Le détail des régimes est dans notre article sur l’obligation d’accessibilité numérique.

Les documents suivent l’application. Le RGAA prévoit que la déclaration d’accessibilité d’une application est disponible sur le site de l’organisme qui l’a développée, ou avec les informations proposées lors du téléchargement. L’état de conformité est précisé au sein de l’application elle-même.

Le modèle de déclaration prévoit ce cas. Pour un site, l’état de conformité se mesure avec le RGAA. Pour les autres services, la déclaration indique le protocole de test utilisé. Les rubriques du modèle sont détaillées dans la déclaration d’accessibilité, rubrique par rubrique.

L’application d’une boutique est-elle concernée par l’EAA ?

Oui. La directive (UE) 2019/882 définit le commerce électronique comme un service fourni à distance, par un site internet ou une application mobile, en vue de conclure un contrat de consommation. Une application qui permet d’acheter entre donc dans le champ, depuis le 28 juin 2025.

• Pas de délai jusqu’en 2030. La DGCCRF précise qu’un site internet ou une application mobile n’est pas un « produit » au sens de ce délai transitoire.
• La même dispense. Une entreprise de moins de dix personnes, dont le chiffre d’affaires annuel ou le total de bilan n’excède pas deux millions d’euros, est dispensée. Les deux conditions se cumulent.
• La même norme. Le code de la consommation présume conformes les services qui respectent les normes harmonisées. En pratique, c’est l’EN 301 549.
• La même information. Le prestataire explique comment son service satisfait aux exigences d’accessibilité, dans ses conditions générales ou un document équivalent.

La DGCCRF indique qu’une enquête porte depuis janvier 2026 sur les sites et applications de commerce en ligne. Le cadre complet est dans l’European Accessibility Act en français.

Comment se teste une application mobile ?

Sur un vrai téléphone, avec les fonctions d’accessibilité du système. iOS et Android intègrent chacun un lecteur d’écran.

• VoiceOver, sur iPhone. Apple le décrit comme un lecteur d’écran contrôlé par des gestes. Il énonce à voix haute ce qui est affiché. Apple précise dans sa documentation pour les développeurs que VoiceOver n’est pas disponible sur le simulateur : l’application s’installe sur un appareil physique.
• TalkBack, sur Android. Google le présente comme un lecteur d’écran préinstallé sur les appareils Android. Sa documentation pour les développeurs liste les questions à se poser : chaque élément est-il annoncé avec un intitulé qui dit sa fonction ? Peut-on atteindre chaque élément en balayant l’écran ? Peut-on mener les parcours principaux jusqu’au bout ?

Apple et Google recommandent aussi de tester avec d’autres aides du système, comme le contrôle vocal et le contrôle de sélection. Apple ajoute les réglages d’accessibilité, à activer un par un pendant les parcours principaux.

Des outils d’analyse existent, comme Accessibility Inspector chez Apple et Accessibility Scanner chez Google. Google prévient toutefois que l’analyse intégrée à son environnement de développement ne détecte pas les problèmes qui surviennent quand l’application tourne sur l’appareil. Comme pour un site, l’analyse automatique ne remplace pas l’examen par une personne : voir ce qu’un outil automatique voit et ne voit pas.

Le cas d’une application municipale

Une commune qui publie une application, pour signaler un problème de voirie ou suivre l’agenda, est tenue par l’article 47 comme pour son site. Quatre points se vérifient avant et après la mise en ligne.

1. Le marché. Le cahier des charges cite la norme EN 301 549 et demande des tests sur iOS et Android, avec VoiceOver et TalkBack.
2. La déclaration. Elle est publiée sur le site de la commune ou dans la fiche de téléchargement, et l’état de conformité apparaît dans l’application.
3. Le contact. Un usager bloqué doit pouvoir signaler le défaut et obtenir le contenu autrement, comme pour le site.
4. Le schéma pluriannuel. Le RGAA y demande les audits prévus pour l’ensemble des services de communication de l’organisme. L’application en fait partie. Voir le schéma pluriannuel, modèle et contenu.

Le RGAA 5 devrait changer la méthode. DesignGouv annonce des critères techniques et des tests pour les applications mobiles, avec l’intégration des WCAG 2.2. Leur contenu sera connu à la publication, annoncée pour fin 2026 : voir l’article sur le RGAA 5 et ce que changent les WCAG 2.2. En attendant, l’obligation s’applique déjà, avec la norme EN 301 549.

Pour le site de la commune, notre audit suit la méthode du RGAA 4.1.2. L’offre est décrite sur la page Prestations.

Questions fréquentes

Sources

• DINUM, RGAA 4.1.2, introduction de la méthode technique : applications natives hors méthode, parties 5, 6, 7, 8 et 11 de l’EN 301 549, consultée le 27/09/2026.
• DINUM, RGAA, rappel du champ d’application : définition des applications mobiles, consulté le 27/09/2026.
• DINUM, RGAA, déclaration d’accessibilité : publication pour les applications mobiles, consultée le 27/09/2026.
• DINUM, RGAA, environnement de test : combinaisons mobiles, consulté le 27/09/2026.
• ETSI, CEN, CENELEC, page de publication de la norme EN 301 549 V3.2.1 (2021-03), chapitre 11 et annexe A, consultée le 27/09/2026.
• Décret n° 2019-768 du 24 juillet 2019, article 10, Légifrance, consulté le 27/09/2026.
• Apple, activer VoiceOver sur l’iPhone et Performing accessibility testing for your app, consultés le 27/09/2026.
• Google, premiers pas avec Android et TalkBack et Test your app’s accessibility, consultés le 27/09/2026.
• DesignGouv, « Nouvelle version du RGAA », consulté le 27/09/2026.

À lire ensuite : WCAG 2.2 et RGAA : ce qui change pour votre site.