Accessibilité application mobile : le guide complet pour une app inclusive

On ne va pas se mentir : l'accessibilité, c'est souvent le parent pauvre des projets d'application mobile. On y pense à la fin, quand tout est déjà développé. Ou pire, on n'y pense pas du tout.

Et pourtant. Selon l'Organisation Mondiale de la Santé, plus de 1,3 milliard de personnes vivent avec une forme de handicap dans le monde, soit 16% de la population mondiale. En France, 12 millions de personnes sont en situation de handicap. Ça représente près de 20% de la population. Une étude AllAccessible (2025) révèle que 26% des adultes américains ont un handicap, représentant un pouvoir d'achat de 13 000 milliards de dollars. Ajoutez à ça les seniors qui ont du mal à lire les petits textes, les daltoniens qui ne distinguent pas certaines couleurs, les personnes avec un bras dans le plâtre qui utilisent leur téléphone d'une seule main... L'accessibilité concerne bien plus de monde qu'on ne l'imagine.

Chez Eurus, on a longtemps fait comme tout le monde : l'accessibilité venait en dernier. Jusqu'au jour où un client nous a demandé pourquoi son app ne fonctionnait pas avec VoiceOver. On n'avait tout simplement pas testé. Leçon apprise.

Pourquoi l'accessibilité n'est pas une option

L'argument éthique (et le plus important)

Développer une application, c'est créer un outil. Et un outil doit être utilisable par le plus grand nombre. Point. Si votre app bancaire n'est pas accessible aux personnes malvoyantes, vous les excluez de facto de services essentiels. Selon une étude Accessibly (2024), 15% des personnes handicapées déclarent ne "jamais" aller en ligne, contre seulement 5% des personnes sans handicap — un écart qui s'explique en partie par l'inaccessibilité des interfaces.

En 3 ans chez Eurus, j'ai vu des projets échouer non pas à cause du code, mais parce que personne n'avait vraiment compris le besoin métier. L'accessibilité, c'est exactement ça : comprendre que vos utilisateurs ne sont pas tous identiques à vous.

L'argument légal

Depuis 2019, la directive européenne sur l'accessibilité numérique impose aux entreprises de rendre leurs services digitaux accessibles. En France, la loi pour une République numérique de 2016 et le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) fixent le cadre. Les sanctions peuvent aller jusqu'à 20 000€ par service non conforme.

Et ce n'est que le début. Le European Accessibility Act, entré en vigueur en 2025, étend ces obligations à pratiquement tous les services numériques destinés aux consommateurs.

L'argument business

Là, ça devient intéressant. Une app accessible, c'est :

Une app mieux référencée. Google et Apple valorisent les applications accessibles dans leurs algorithmes de classement. Les bonnes pratiques d'accessibilité (textes alternatifs, structure sémantique) améliorent aussi le SEO de votre page store.

Une app avec une meilleure UX globale. Paradoxalement, concevoir pour les cas extrêmes améliore l'expérience pour tout le monde. Des boutons plus grands, des contrastes plus forts, des parcours plus simples — tout le monde en profite.

Une app avec un marché plus large. 20% de la population concernée par le handicap, ça représente un pouvoir d'achat considérable. Selon Statista, le nombre d'utilisateurs mobiles dans le monde atteindra 7,49 milliards en 2025. Ignorer l'accessibilité, c'est potentiellement exclure plus d'un milliard d'entre eux. Sans parler des seniors, segment en croissance constante.

Les bases : comprendre le WCAG

Le Web Content Accessibility Guidelines (WCAG) est LA référence internationale en matière d'accessibilité numérique. Développé par le W3C, il s'applique aussi aux applications mobiles.

Le WCAG repose sur quatre principes fondamentaux, qu'on appelle POUR : Perceptible, Opérable, Understandable (Compréhensible), Robuste.

Perceptible

L'information doit être présentée de façon à ce que l'utilisateur puisse la percevoir. Concrètement, ça signifie que tout contenu non-textuel doit avoir une alternative textuelle. Une image ? Elle a besoin d'une description. Une vidéo ? Elle nécessite des sous-titres.

Sur DrMilou, notre application vétérinaire, on affiche beaucoup d'icônes pour les différents types d'animaux. Au début, c'était juste des images. Problème : un utilisateur de VoiceOver entendait "image" sans aucune information utile. On a dû reprendre toutes les icônes pour ajouter des labels accessibles. "Chat", "Chien", "NAC"... Simple, mais indispensable.

Opérable

L'interface doit être utilisable. Ça semble évident, mais ça implique plusieurs choses. Toutes les fonctionnalités doivent être accessibles au clavier (ou aux gestes d'accessibilité sur mobile). L'utilisateur doit avoir assez de temps pour lire et interagir. Les contenus ne doivent pas provoquer de crises (pas de flashs répétés). Et la navigation doit être cohérente.

Compréhensible

Le contenu et l'interface doivent être compréhensibles. Le texte doit être lisible. Les pages doivent se comporter de façon prévisible. L'utilisateur doit être aidé pour éviter et corriger les erreurs.

Un exemple concret : sur un formulaire d'inscription, au lieu d'afficher un simple message d'erreur "Champ invalide", expliquez ce qui ne va pas et comment corriger. "Le mot de passe doit contenir au moins 8 caractères, dont une majuscule et un chiffre."

Robuste

Le contenu doit être suffisamment robuste pour être interprété par une grande variété d'agents utilisateurs, y compris les technologies d'assistance. En pratique, ça veut dire utiliser les composants natifs quand c'est possible et respecter les standards de la plateforme.

VoiceOver et TalkBack : vos meilleurs alliés pour tester

VoiceOver (iOS) et TalkBack (Android) sont les lecteurs d'écran intégrés aux systèmes d'exploitation mobile. Si votre app fonctionne bien avec ces outils, vous êtes sur la bonne voie.

Activer VoiceOver sur iOS

Allez dans Réglages > Accessibilité > VoiceOver. Je vous conseille d'abord d'ajouter un raccourci d'accessibilité (triple clic sur le bouton latéral) pour l'activer/désactiver facilement.

Les gestes de base à connaître. Balayez vers la droite pour passer à l'élément suivant. Balayez vers la gauche pour revenir en arrière. Double-tapez pour activer l'élément sélectionné. Balayez vers le haut ou le bas avec deux doigts pour faire défiler.

Activer TalkBack sur Android

Allez dans Paramètres > Accessibilité > TalkBack. Là aussi, configurez un raccourci (généralement maintenir les deux boutons de volume).

La navigation est similaire à VoiceOver. Balayage pour naviguer, double-tap pour activer. Les gestes spécifiques peuvent varier selon les versions d'Android.

Ce que vous allez découvrir

La première fois qu'on teste une app avec VoiceOver, c'est souvent un choc. Vous allez entendre des choses comme "bouton", "image", "bouton bouton bouton"... sans aucune indication de ce que ces éléments font réellement.

Sur une app qu'on a auditée pour un client, le lecteur d'écran lisait littéralement "btn_submit_form_v2" parce que personne n'avait pensé à ajouter un label accessible. L'utilisateur malvoyant n'avait aucune idée de ce que faisait ce bouton.

Les erreurs les plus courantes (et comment les éviter)

Une analyse AudioEye (2024) révèle que la page web moyenne contient 37 éléments uniques (images, liens, boutons) qui ne respectent pas les critères WCAG. Ces erreurs sont souvent les mêmes d'un site à l'autre.

Erreur n°1 : les images sans texte alternatif

C'est la plus fréquente. Chaque image qui transmet une information doit avoir un texte alternatif pertinent. Attention : le texte alternatif doit décrire le contenu ou la fonction de l'image, pas l'image elle-même.

Mauvais exemple : "Photo d'un graphique" Bon exemple : "Évolution du chiffre d'affaires : +15% au T3 2025"

Pour les images purement décoratives, utilisez un texte alternatif vide pour que le lecteur d'écran les ignore.

Erreur n°2 : les contrastes insuffisants

Le ratio de contraste minimum entre le texte et l'arrière-plan doit être de 4.5:1 pour le texte standard et 3:1 pour le texte large (18px et plus en gras, ou 24px et plus). Beaucoup de designs "tendance" avec des gris clairs sur fond blanc ne passent pas ce test.

Utilisez des outils comme Colour Contrast Analyzer ou les fonctions intégrées à Figma pour vérifier vos contrastes.

Erreur n°3 : les zones tactiles trop petites

Apple recommande une taille minimum de 44x44 points pour les zones tactiles. Google recommande 48x48 dp. Pourquoi ? Parce qu'un doigt humain, c'est imprécis. Et pour quelqu'un avec des tremblements ou une motricité réduite, c'est encore plus difficile.

Les cabinets vétérinaires ont des contraintes qu'on n'imaginait pas : connexion internet instable, PC sous Windows XP, urgences qui arrivent pendant qu'on tape une ordonnance. Sur DrMilou, on a dû agrandir significativement tous les boutons d'action critique. Un véto stressé avec un animal qui bouge sur la table n'a pas le temps de viser un bouton de 30 pixels.

Erreur n°4 : la dépendance aux couleurs

Ne transmettez jamais une information uniquement par la couleur. Les daltoniens (8% des hommes, quand même) ne pourront pas la percevoir. Si un champ en erreur devient rouge, ajoutez aussi une icône ou un texte explicatif.

Sur Youdy, notre app sociale, on avait un système de pastilles colorées pour indiquer le statut des utilisateurs : vert pour en ligne, rouge pour absent. On a dû ajouter des icônes distinctes parce que c'était inutilisable pour les utilisateurs daltoniens.

Erreur n°5 : les animations non contrôlables

Certaines personnes sont sensibles aux mouvements à l'écran. D'autres utilisent des options système pour réduire les animations. Votre app doit respecter le paramètre "Réduire les animations" du système et offrir un moyen de désactiver les animations automatiques.

Erreur n°6 : l'ordre de focus incohérent

Quand un utilisateur navigue avec VoiceOver ou TalkBack, l'ordre de lecture doit être logique. Si votre header se lit après votre contenu principal, c'est un problème. Sur iOS, utilisez accessibilityElements pour définir explicitement l'ordre. Sur Android, utilisez importantForAccessibility et accessibilityTraversalBefore/After.

Implémenter l'accessibilité : guide technique

Sur iOS (Swift/SwiftUI)

SwiftUI intègre beaucoup de fonctionnalités d'accessibilité par défaut, mais vous devez quand même intervenir.

Pour ajouter un label accessible à un bouton image, utilisez le modifier .accessibilityLabel("Description de l'action"). Pour grouper des éléments qui doivent être lus ensemble, utilisez .accessibilityElement(children: .combine). Pour indiquer qu'un élément est un en-tête, utilisez .accessibilityAddTraits(.isHeader).

En UIKit, les propriétés clés sont accessibilityLabel, accessibilityHint, accessibilityTraits et isAccessibilityElement.

Sur Android (Kotlin/Jetpack Compose)

En Jetpack Compose, utilisez les modifiers de sémantique. Modifier.semantics { contentDescription = "Description" } pour décrire un élément. Modifier.semantics { heading() } pour marquer un titre. Modifier.clearAndSetSemantics { } pour remplacer complètement la sémantique d'un composant.

En XML classique, utilisez android:contentDescription pour les descriptions, android:importantForAccessibility pour contrôler si un élément est annoncé, et android:labelFor pour associer un label à un champ de saisie.

Sur Flutter

Flutter utilise le widget Semantics pour ajouter des informations d'accessibilité. La plupart des widgets Material ont déjà une bonne sémantique par défaut, mais vous devrez souvent l'enrichir.

Avec Getaway, notre app voyage en Flutter, on a choisi le cross-platform pour économiser du temps de développement. Mais ça veut dire qu'on doit tester l'accessibilité sur les deux plateformes, parce que le comportement peut varier. Un Semantics bien configuré sur Android peut se comporter différemment sur iOS.

Sur React Native

React Native fournit les props accessible, accessibilityLabel, accessibilityHint, accessibilityRole et accessibilityState. Utilisez-les systématiquement sur tous vos composants interactifs.

Checklist de conformité WCAG niveau AA

Voici les points essentiels à vérifier pour atteindre le niveau AA, qui est le minimum légal requis.

Perceptible. Toutes les images informatives ont un texte alternatif. Les vidéos ont des sous-titres. Le ratio de contraste est d'au moins 4.5:1 pour le texte standard. Le contenu reste compréhensible quand le texte est agrandi à 200%. L'orientation n'est pas bloquée (portrait ou paysage).

Opérable. Toutes les fonctionnalités sont accessibles au lecteur d'écran. Les zones tactiles font au moins 44x44 points. Aucun piège de focus (l'utilisateur peut toujours naviguer ailleurs). Les délais sont suffisants ou désactivables. Pas de flashs répétés.

Compréhensible. La langue de l'app est identifiée. Les erreurs de saisie sont clairement expliquées. Les labels de champs sont visibles et associés. Le comportement est prévisible et cohérent.

Robuste. Les composants standards de la plateforme sont utilisés quand c'est possible. Le nom, le rôle et la valeur des composants personnalisés sont exposés aux technologies d'assistance.

Tester l'accessibilité : les outils indispensables

Outils automatisés

Les outils automatisés détectent environ 30% des problèmes d'accessibilité. C'est un bon point de départ, mais ça ne suffit pas.

Sur iOS, utilisez l'Accessibility Inspector intégré à Xcode. Il analyse votre interface et signale les problèmes évidents.

Sur Android, utilisez le Scanner d'accessibilité (une app Google) ou les tests automatisés avec Espresso et Accessibility Test Framework.

Tests manuels

Les 70% restants nécessitent des tests manuels. Naviguez dans votre app avec VoiceOver ou TalkBack activé. Vérifiez que chaque écran est utilisable sans voir l'écran. Testez tous les parcours critiques.

Notre règle d'or chez Eurus : un MVP en 6 semaines max. Pour l'accessibilité, ça veut dire intégrer les tests dès le sprint 1, pas à la fin. Sinon, la dette s'accumule et devient ingérable.

Tests avec de vrais utilisateurs

Rien ne remplace les tests avec des personnes en situation de handicap. Elles utilisent les technologies d'assistance quotidiennement et repèrent des problèmes qu'un développeur ne verra jamais. Des services comme Access First ou Temesis peuvent vous mettre en relation avec des testeurs.

Intégrer l'accessibilité dans votre process de développement

Dès la conception

L'accessibilité commence dans Figma, pas dans le code. Vos maquettes doivent prévoir les contrastes suffisants, les états de focus visibles, les tailles de zone tactile adéquates. Impliquez votre designer dès le début.

Dans les user stories

Ajoutez des critères d'acceptation liés à l'accessibilité dans chaque story. "En tant qu'utilisateur de VoiceOver, je peux naviguer dans la liste de produits et entendre le nom et le prix de chaque article."

En code review

Incluez l'accessibilité dans vos critères de review. Pas de PR mergée si les labels accessibles manquent ou si les contrastes sont insuffisants.

En CI/CD

Intégrez des tests d'accessibilité automatisés dans votre pipeline. Sur iOS, vous pouvez utiliser les tests d'UI avec des assertions d'accessibilité. Sur Android, Espresso avec AccessibilityChecks.enable() fait le travail.

Le coût de l'accessibilité

Et si on parlait d'argent ? C'est souvent l'argument qu'on nous oppose. "L'accessibilité, ça coûte cher."

En fait, ça dépend. Si vous l'intégrez dès le début du projet, le surcoût est estimé entre 5 et 10% du budget de développement. C'est de la conception en plus, des tests en plus, mais c'est intégré au flux normal.

Si vous devez reprendre une app existante... là, ça peut monter à 25-30% du budget initial, voire plus si l'architecture n'a pas été pensée pour. Sans parler du coût d'opportunité (tout ce que vous ne développez pas pendant ce temps).

Le calcul est simple : intégrez l'accessibilité dès le début.

FAQ sur l'accessibilité mobile

Mon app doit-elle être 100% accessible pour être légale ?

Le niveau minimum requis est le niveau AA du WCAG. Ça ne veut pas dire 100% parfait, mais ça couvre les points essentiels. Le niveau AAA est un idéal à viser mais rarement exigé légalement.

Les apps internes sont-elles concernées ?

Oui, si elles sont utilisées par des employés. Un employé malvoyant a le droit d'utiliser les outils de son entreprise. Le Code du travail impose l'adaptation des postes de travail.

Flutter et React Native sont-ils compatibles avec l'accessibilité ?

Oui, les deux frameworks supportent les technologies d'assistance natives. Mais vous devez quand même configurer correctement les sémantiques. Le support par défaut ne suffit pas.

Combien de temps prend un audit d'accessibilité ?

Pour une app de taille moyenne (20-30 écrans), comptez 3 à 5 jours pour un audit complet avec rapport détaillé et recommandations de correction.

Par où commencer si mon app n'est pas du tout accessible ?

Commencez par les parcours critiques. L'inscription, la connexion, les fonctionnalités principales. Puis élargissez progressivement. Rome ne s'est pas construite en un jour.

Conclusion : l'accessibilité n'est pas une fonctionnalité, c'est une exigence

On pourrait voir l'accessibilité comme une contrainte, une case à cocher pour être conforme. Ce serait passer à côté de l'essentiel.

Concevoir accessible, c'est concevoir pour des humains dans toute leur diversité. C'est reconnaître que l'utilisateur "moyen" n'existe pas. C'est faire preuve d'empathie dans chaque décision de design et de développement.

Les apps les mieux conçues que je connaisse sont aussi les plus accessibles. Ce n'est pas un hasard. La rigueur qu'impose l'accessibilité rejaillit sur l'ensemble de la qualité du produit.

Chez Eurus, on ne livre plus une app sans l'avoir testée avec VoiceOver et TalkBack. C'est devenu un réflexe, comme les tests unitaires ou la code review. Et nos clients nous en remercient, parce que leurs utilisateurs leur en sont reconnaissants.

---

Vous avez un projet d'application et vous voulez le rendre accessible dès le départ ? Discutons-en ensemble. On vous accompagne de la conception au déploiement, avec l'accessibilité comme priorité, pas comme option.