Audit d’accessibilité d’une app mobile

Auditer une app mobile diffère d’un site web : sans accès au code source ni outils d’analyse poussés, l’évaluation repose surtout sur des tests fonctionnels et des outils beaucoup plus limités.

Auditer mon app Voir notre démarche d’audit
Quel périmètre

Applications natives, hybrides, PWA : ce que nous auditons

Le type d’application détermine les points de contrôle – et les pièges d’accessibilité.

Applications natives (iOS, Android)

Développées avec les composants du système. L’enjeu : exploiter correctement les API d’accessibilité natives (libellés, rôles, ordre de lecture) au lieu de les contourner.

Applications hybrides (React Native, Flutter…)

Un même code pour deux plateformes. Le risque : des composants personnalisés qui « cassent » l’accessibilité si leurs rôles et libellés ne sont pas exposés à VoiceOver et TalkBack.

Applications à webviews / PWA

Des pages web encapsulées dans l’application. Elles cumulent exigences web et mobiles, et sont souvent l’angle mort des audits.

Applications grand public, métiers ou jeux/gaming : nous adaptons le périmètre à votre usage et à vos publics.

Quel référentiel pour votre application mobile ?

Nous auditons vos applications iOS et Android au regard du RAAM et de l’EN 301 549 (voire du RGAA pour les app à webviews), puis vous livrons une feuille de route de mise en conformité priorisée. Au niveau réglementaire, l’obligation d’accessibilité vise également les applications mobiles selon :

Comprendre vos obligations
Quel échantillon

Comment nous construisons l’échantillon de votre application ?

Une application ne s’audite pas « page par page » : on raisonne en écrans et en parcours. Nous sélectionnons :

  • Les écrans clésaccueil, connexion/inscription, réglages (dont les réglages d’accessibilité), et au moins un écran par gabarit récurrent.
  • Les parcours critiquesles enchaînements réels (s’inscrire, effectuer un achat, réaliser une opération), testés de bout en bout.
  • Les étatschargements, erreurs, messages, notifications : ce que l’utilisateur rencontre vraiment.

Chaque écran est testé sous les deux lecteurs d’écran mobiles - VoiceOver sur iOS, TalkBack sur Android - car les comportements diffèrent d’une plateforme à l’autre.

Votre application résiste-t-elle à VoiceOver ?

Nos experts testent vos parcours clés sur de vrais appareils, sous VoiceOver et TalkBack, pour révéler les blocages que les outils automatiques ne détectent pas.

Faire auditer mon application
Quel test

Ce que nous testons, concrètement

Sur chaque écran de l’échantillon, nos experts testent au doigt, au lecteur d’écran et au clavier externe. Les points décisifs sur mobile :

6 éléments, sans lien.

  • Lecteurs d'écran (VoiceOver, TalkBack)

    Libellé, rôle et ordre de lecture corrects.

  • Gestes tactiles

    Une alternative simple à tout geste complexe.

  • Orientation

    Portrait et paysage, sans orientation imposée.

  • Taille du texte

    Respect des réglages système (Dynamic Type, mise à l'échelle Android).

  • Contrastes

    Ratios suffisants ; information jamais portée par la seule couleur.

  • Focus et clavier externe

    Navigation au clavier Bluetooth et au switch control.
Quelles non-conformités

Les non-conformités d’accessibilité les plus fréquentes sur app mobile

Certaines erreurs reviennent sur la plupart des applications que nous auditons :

  • Boutons-icônes sans libellé une icône « cœur » ou « panier » sans alternative textuelle. Impact : VoiceOver et TalkBack annoncent « bouton » sans dire lequel.
  • Contraste insuffisant des textes et composants texte ou éléments d'interface (icônes, bordures de champs, boutons) sous le ratio minimal. Impact : contenu et commandes illisibles pour les personnes malvoyantes ou en forte luminosité.
  • Ordre de lecture incohérent le lecteur d’écran parcourt l’écran dans le désordre. Impact : contenu incompréhensible.
  • Texte non redimensionnable police qui ignore la taille système. Impact : illisible pour une personne malvoyante.

À la clé : un rapport écran par écran, un score de conformité visualisé sur IpedisConnect, des recommandations correctives illustrées et votre déclaration d’accessibilité. Le détail de nos livrables et de notre méthodologie figure sur la page Audit d’accessibilité numérique.

 Un audit n’est qu’un point de départ : nous vous accompagnons ensuite dans la remédiation et le pilotage de votre mise en conformité, pour faire de l’accessibilité un levier de performance durable.

faq

Questions fréquentes

Tout d’abord les référentiels sont différents : un site web relève du RGAA 4.1 (en attendant la version 5) et d’un échantillon de pages ; une application mobile mobilise le RAAM / l’EN 301 549 et un échantillon d’écrans, avec des tests dédiés (gestes, cibles tactiles, VoiceOver/TalkBack). De plus, alors que l’audit d’un site web permet d’inspecter le code source et de s’appuyer sur de nombreux outils d’analyse, l’audit d’une application mobile repose principalement sur des tests fonctionnels, sans accès au code source et avec des outils beaucoup plus limités. Découvrez notre audit de site web.

Oui. Les deux systèmes ont des lecteurs d’écran et des comportements d’accessibilité différents ( VoiceOver contre TalkBack) : une version conforme n’implique pas l’autre.

La méthode reste la même, mais les applications hybrides (React Native, Flutter) exposent des risques spécifiques sur les composants personnalisés, que nous testons en priorité.

Le RGAA a valeur légale en France mais reste centré sur le web. Pour une application, nous auditons avec le RAAM, aligné sur l’EN 301 549. À la sortie du RGAA 5 (fin 2026), nos audits intégreront ses critères dédiés aux applications natives.

Oui. Les tests sont menés sur appareils réels iOS et Android, lecteurs d’écran activés : les émulateurs ne restituent pas fidèlement les technologies d’assistance.

Chaque utilisateur doit aller au bout

Connexion, paiement, souscription : assurez-vous que chacun, avec ou sans technologie d'assistance, puisse terminer vos parcours mobiles en toute autonomie.

Demander mon devis