L’accessibilité application mobile a longtemps été traitée comme une bonne intention : un paragraphe en fin de cahier des charges, que personne ne relit et que personne ne budgète. Ce temps est terminé. Depuis le 28 juin 2025, la directive européenne (UE) 2019/882, dite European Accessibility Act, s’applique à une grande partie des produits et services numériques vendus en Europe. Le sujet est passé du registre moral au registre réglementaire, et surtout au registre budgétaire.
Chez Squirrel, nous concevons et maintenons des applications sur mesure depuis 2014. Notre position est tranchée : un audit d’accessibilité commandé trois semaines avant la mise en production arrive trop tard, parce qu’il se contente de lister ce qu’il aurait fallu décider six mois plus tôt. Les vrais gains se jouent dans le design system et dans la revue de maquettes, quand changer une couleur ne coûte presque rien.
Accessibilité application mobile : ce que la loi impose vraiment
Deux corpus se superposent en France, et on les confond souvent : l’un vient d’Europe et vise le marché, l’autre vient du droit français et vise le service public. Les deux peuvent concerner votre application.
L’European Accessibility Act, applicable depuis le 28 juin 2025
La directive 2019/882 fixe des exigences pour une liste de produits (smartphones, liseuses, terminaux de paiement et de libre-service) et de services : communications électroniques, médias audiovisuels, transport de voyageurs, banque aux particuliers, livres numériques et commerce électronique. Ce dernier point touche le plus d’applications, puisque la directive définit le commerce électronique comme des services fournis à distance « via des sites internet et des services intégrés sur appareils mobiles ».
En France, la transposition passe notamment par le décret n° 2023-931 du 9 octobre 2023 et un arrêté du même jour, avec des dispositions inscrites dans le code de la consommation. Le contrôle est réparti entre la DGCCRF pour les produits et, selon les services, l’Arcom, l’Arcep, la Banque de France, l’ACPR et l’AMF. D’après la fiche pratique de la DGCCRF, les manquements relèvent de contraventions de la cinquième classe, avec des amendes pouvant atteindre 7 500 euros et se cumuler par infraction constatée.
Un point mérite d’être clarifié, parce qu’il circule beaucoup de contresens. La directive prévoit des mesures transitoires : les contrats de service conclus avant le 28 juin 2025 peuvent se poursuivre sans modification jusqu’à leur terme, dans la limite de cinq ans, et les terminaux libre-service déjà installés peuvent servir jusqu’à la fin de leur durée de vie économique, dans la limite de vingt ans. Ce n’est pas un sursis général jusqu’en 2030 : une application lancée aujourd’hui est concernée tout de suite.
Le RGAA, la norme EN 301 549 et les WCAG
Le RGAA, référentiel général d’amélioration de l’accessibilité, est l’outil français d’évaluation. La version en vigueur est la 4.1.2, une version 5 étant annoncée pour fin 2026. Son champ vient de l’article 47 de la loi n° 2005-102 du 11 février 2005 : organismes publics, personnes privées chargées d’une mission de service public, et entreprises à partir de 250 millions d’euros de chiffre d’affaires réalisé en France, en moyenne sur les trois derniers exercices. Le texte vise nommément les applications mobiles dans son champ d’application.
La norme de référence est la norme européenne EN 301 549 V2.1.2, et les organismes qui se réfèrent aux normes internationales doivent satisfaire les critères WCAG 2.1 de niveau A et AA. Les trois textes ne se contredisent pas : le RGAA est une méthode de test, EN 301 549 est la norme, les WCAG en sont la colonne vertébrale. L’Arcom peut prononcer une amende allant jusqu’à 50 000 euros en cas de non-respect des exigences d’accessibilité, et jusqu’à 25 000 euros pour les autres obligations, comme la déclaration d’accessibilité.
Qui est exempté, et jusqu’où
Les microentreprises qui fournissent des services sont exemptées des obligations de l’European Accessibility Act. La DGCCRF retient le seuil habituel : moins de dix salariés et un chiffre d’affaires annuel ou un total de bilan n’excédant pas 2 millions d’euros. S’y ajoute la charge disproportionnée, invocable au cas par cas mais qui se documente : le manque de temps ou de connaissances n’est pas recevable. Attention aussi au raisonnement en miroir : l’exemption s’apprécie sur l’entreprise qui fournit le service, pas sur l’agence qui développe.
Rendre une application accessible : les points de contrôle qui comptent
Passons du droit au produit, dans l’ordre où les problèmes apparaissent.
Contraste, taille de texte et réglages système
Le contraste est le premier fautif et le plus facile à corriger tôt. Les WCAG demandent un rapport d’au moins 4,5 pour 1 entre le texte et son fond, 3 pour 1 pour les grands textes. Le gris clair sur blanc, si élégant sur un écran calibré, devient illisible au soleil, ce qui à La Réunion n’est pas un détail théorique. Autre réflexe : ne jamais faire porter une information par la seule couleur, sinon un champ en rouge ne dit rien à qui ne perçoit pas le rouge.
Viennent ensuite les réglages système. iOS propose Dynamic Type, Android une échelle de police réglable, et un utilisateur qui a agrandi le texte de son téléphone s’attend à ce que votre application suive. Une interface aux tailles figées en dur explose dès 150 %. Poussez le curseur système au maximum et regardez ce qui reste lisible.
Lecteurs d’écran : VoiceOver, TalkBack et les libellés
Un lecteur d’écran restitue à voix haute ce que l’interface expose. VoiceOver sur iOS, TalkBack sur Android. Le bât blesse sur les composants purement graphiques : une icône de partage sans libellé sera annoncée « bouton », ce qui n’aide personne. La documentation Android recommande de décrire l’intention et le résultat de l’action plutôt que l’apparence du pictogramme.
Trois erreurs reviennent dans presque tous les audits que nous menons : des images décoratives non masquées qui polluent la lecture, un ordre de parcours incohérent avec l’ordre visuel, et des changements d’état non annoncés, typiquement une erreur de formulaire que le lecteur d’écran ne signale pas. Rien de tout cela ne demande une refonte, seulement d’y avoir pensé au moment d’écrire le composant.
Zones tactiles, gestes et contenus temporels
Apple recommande des contrôles d’au moins 44 points sur 44 points pour qu’ils soient atteignables avec précision au doigt, Google une zone d’au moins 48 dp sur 48 dp, et les WCAG 2.2 ont ajouté un critère de niveau AA fixant un minimum de 24 pixels CSS. Une croix de fermeture de 16 pixels échoue à tous ces repères, et pas seulement pour les personnes handicapées : elle échoue pour tout le monde dans un bus.
Il faut aussi prévoir autre chose que le doigt. Clavier Bluetooth, contacteurs, contrôle par commutateur : ces modes supposent un focus toujours visible, et tout geste complexe doit avoir une alternative simple. Restent les contenus temporels : une vidéo porteuse d’information a besoin de sous-titres, et le réglage de réduction des animations doit être respecté.
Concrètement pour nos clients : sur une application de bons plans géolocalisés comme SmiileCard, la carte est le premier écueil : un fond cartographique ne se lit ni au doigt ni à la voix. Notre réflexe est donc de doubler systématiquement la carte d’une liste équivalente, ordonnée par distance, avec les mêmes informations et les mêmes actions. Ce n’est pas une rustine, c’est un meilleur produit : la liste sert aussi à ceux qui sont pressés ou mal connectés. Cet arbitrage se décide en atelier de cadrage, pas en recette.
Accessibilité application mobile : pourquoi le rattrapage coûte cher
Une correction n’a pas le même prix selon le moment où elle est décidée, parce qu’elle ne touche pas les mêmes objets.
| Ce qu’on corrige | Traité dès la conception | Rattrapé après la mise en production |
|---|---|---|
| Contraste des couleurs | Deux valeurs ajustées dans les tokens de la charte | La charte, tous les écrans concernés, puis les captures des stores |
| Zones tactiles | La taille minimale est dans le composant du design system | Écran par écran, avec des régressions de mise en page à chaque fois |
| Libellés pour les lecteurs d’écran | Écrits en même temps que le composant, une seule fois | Ajoutés à la main sur des centaines d’éléments, sans vue d’ensemble |
| Ce qu’on obtient | Un produit accessible et une déclaration défendable | Un rapport d’audit, une liste d’anomalies et une décision à prendre |
L’audit n’est pas inutile, il est mal placé. Il a toute sa valeur en contrôle, pour vérifier et documenter. Il n’en a aucune pour découvrir ce qu’une relecture de maquette aurait attrapé pour rien.
Notre méthode : l’accessibilité dans le design system
Nous plaçons les garde-fous à quatre endroits. D’abord dans les tokens de couleur : les paires texte sur fond sont validées en contraste une fois pour toutes, et un designer qui pioche dedans ne peut plus se tromper. Ensuite dans les composants : un bouton du design system embarque sa zone tactile minimale, son état de focus et son libellé d’accessibilité, si bien que la bonne pratique devient le chemin le plus court. C’est le prolongement de notre travail de design et d’ergonomie applicative.
Le troisième point de contrôle est la revue de maquettes, avec une liste courte : contraste, texte à 200 %, libellés des icônes, alternative aux gestes, ordre de lecture. Cinq minutes par écran, quand corriger ne coûte qu’un déplacement de calque. Le quatrième est la recette, avec des tests manuels VoiceOver et TalkBack sur les parcours critiques : les outils automatiques ne verront jamais qu’un écran devient incompréhensible une fois lu à voix haute. Le tout s’appuie sur notre méthodologie de projet et sur les jalons de la conception d’une application mobile.
Reste le volet éditorial, souvent négligé : déclaration d’accessibilité, mention de l’état de conformité, mécanisme de signalement. Des pages à produire et à tenir à jour, au même titre que vos mentions légales d’application mobile.
Questions fréquentes sur l’accessibilité d’une application mobile
Mon application est-elle concernée par l’obligation d’accessibilité ?
Regardez deux choses. Si votre application permet à un consommateur de conclure un contrat, ou si elle relève de la banque, du transport de voyageurs, des communications électroniques, des médias audiovisuels ou du livre numérique, l’European Accessibility Act s’applique depuis le 28 juin 2025, sauf si vous êtes une microentreprise. Si vous êtes un organisme public, un délégataire de service public ou une entreprise dépassant 250 millions d’euros de chiffre d’affaires en France, ce sont l’article 47 et le RGAA qui s’appliquent.
Le RGAA s’applique-t-il vraiment aux applications mobiles ?
Oui. Le champ d’application publié sur le site officiel du RGAA cite nommément les applications mobiles. Sa méthode de test reste toutefois orientée web : sur une application native, on s’appuie surtout sur EN 301 549 et sur les critères WCAG correspondants.
Combien coûte la mise en accessibilité d’une application mobile ?
Il n’existe pas de tarif unique, et méfiez-vous de ceux qui en annoncent un sans avoir vu le produit. Tout dépend du moment où vous posez la question. Intégrée dès la conception, l’accessibilité se dilue dans le design et le développement. Rattrapée en production, elle devient un chantier à part entière, avec sa reprise de charte et sa recette complète.
Peut-on rendre accessible une application déjà en ligne ?
Oui, mais pas en une seule fois. Nous procédons par priorités : d’abord les parcours qui engagent l’utilisateur (inscription, paiement, contact), ensuite la charte et les composants partagés, enfin le reste des écrans. En traitant le design system en premier, une partie des corrections se propage seule.
Votre application est-elle concernée, et à quel point ? Nous regardons vos écrans et votre situation réglementaire, puis nous vous disons franchement ce qui relève d’une obligation et ce qui peut attendre.
Parler de mon projet Voir nos expertises