Accessibilité des applications mobiles : comment rendre votre app plus accessible

Un aperçu ou un score de contraste ne suffit pas à prouver qu’une app est accessible. En revanche, il est possible d’éliminer un nombre surprenant d’obstacles avant même le début des tests formels.

L’accessibilité mobile va bien au-delà du contraste des couleurs. Typographie, espacements, navigation, zones tactiles, libellés, animations, médias et comportement avec les technologies d’assistance déterminent aussi si une personne peut aller au bout d’une action.

Les WCAG ont été rédigées pour les contenus web. Le document WCAG2Mobile du W3C explique comment appliquer les critères de niveau A et AA des WCAG 2.2 aux applications mobiles natives, web et hybrides. Il s’agit de recommandations informatives, et non d’une norme mobile distincte ; elles ne suffisent pas à elles seules pour établir qu’une app est accessible.

Cette checklist distingue ce qui peut être configuré de manière centralisée de ce qui doit encore être vérifié dans le produit publié :

Rien ne semblait manifestement cassé dans ce premier écran. C’est justement tout l’intérêt de l’exercice : les problèmes d’accessibilité ne sont pas toujours spectaculaires. Ils se cachent souvent dans des choix graphiques pourtant élégants.

Nous avons appliqué un texte clair sur un fond clair, réduit le corps du texte à 10 px, supprimé les marges globales et conservé des libellés de navigation génériques comme « Vidéos » et « Podcasts ». Le résultat restait apaisant dans une présentation. Sur un téléphone, la hiérarchie s’effondrait : les textes secondaires s’effaçaient, les cartes frôlaient les bords de l’écran et la navigation inférieure devenait beaucoup plus difficile à parcourir.

La leçon n’est pas qu’il faut bannir les couleurs pastel ou tout afficher en grand. Les choix de marque ont simplement besoin de reposer sur un système lisible.

Nous avons commencé dans Mon app > Style de l'app > Couleurs en attribuant les couleurs par rôle. Le fond chaud a été conservé. C’est l’écart entre chaque premier plan et son arrière-plan qui a changé :

Les WCAG 2.2 fixent un ratio de contraste minimal de 4,5:1 pour le texte courant et de 3:1 pour le texte de grande taille au niveau AA. Nous avons volontairement laissé davantage de marge aux textes essentiels : une paire qui passe sur le papier peut rester difficile à lire avec une police fine, une petite taille ou un écran très lumineux en extérieur.

GoodBarber permet de partir d’un thème intégré, de générer une palette ou de la créer vous-même. L’essentiel n’est pas le nombre de nuances, mais leur réutilisation. Les textes du header et du corps, les séparateurs, les boutons et les états de navigation peuvent recevoir des rôles cohérents dans toutes les sections. La documentation Style de l’app explique comment ces choix globaux se propagent.

Une palette lisible constitue un bon point de départ, pas un certificat d’accessibilité. Vérifiez chaque paire réelle de premier plan et d’arrière-plan, y compris les états sélectionnés, les superpositions, les images et les personnalisations propres à certaines sections.

Le contraste a rendu les mots visibles. La taille et les espacements les ont rendus confortables à lire.

Nous avons sélectionné le thème de polices Formateca, qui associe Work Sans pour les titres à Manrope pour le corps du texte. Nous avons ensuite utilisé le curseur typographique global pour reconstruire la hiérarchie : le corps du texte est passé de 10 px à 16 px, le titre principal a atteint 30 px et le contenu principal a retrouvé des marges de 16 px.

L’échelle typographique globale de GoodBarber ajuste proportionnellement huit niveaux de texte. Cela facilite le maintien d’une hiérarchie cohérente d’un écran à l’autre, sans garantir à lui seul un résultat accessible. Vérifiez les tailles obtenues, les retours à la ligne et l’interlignage dans l’app générée.

Les WCAG n’imposent pas de taille minimale universelle pour le corps du texte. La valeur de 16 px est celle que nous avons retenue pour cette interface, pas un seuil de conformité. Un texte plus grand a aussi besoin de davantage d’espace ; sinon, les cartes se resserrent et les libellés se coupent maladroitement.

Enfin, testez l’app avec la taille de texte choisie par l’utilisateur. Apple recommande de prendre en charge l’agrandissement du texte et Dynamic Type, tandis que les contenus web doivent rester utilisables lorsque le texte est redimensionné. Un aperçu équilibré dans l’éditeur n’est que le premier état à contrôler.

Dans cette comparaison avant-après, la TabBar d’origine indiquait « Videos », « Podcasts » et « Navigation ». Ces libellés décrivaient des formats ou le mécanisme de l’interface, pas clairement ce qu’un membre de l’app de yoga pouvait faire ensuite.

Nous les avons renommés Classes, Audio et More. La structure n’a pas changé, mais la décision est devenue plus simple : suivre un cours, choisir une séance audio ou ouvrir les autres sections.

Les recommandations d’accessibilité d’Android préconisent des libellés utiles et descriptifs pour les éléments interactifs, car des services comme TalkBack peuvent annoncer leur nom d’accessibilité. Modifier le titre visible améliore la navigation visuelle ; il reste nécessaire de vérifier ce que le composant généré expose réellement à VoiceOver et TalkBack.

Gardez des libellés courts, uniques et orientés vers l’action. Associez les icônes à du texte lorsque l’espace le permet. Un test simple consiste à imaginer les icônes masquées : les mots indiqueraient-ils encore clairement où mène chaque appui ?

L’accessibilité échoue lorsqu’un contenu est visible mais qu’un contrôle est difficile à toucher, ou lorsqu’un média essentiel exclut un canal sensoriel.

Commencez par les zones tactiles. Android recommande une zone focalisable d’au moins 48 × 48 dp pour les éléments interactifs. Pour la PWA, le critère Taille de la cible (minimum) des WCAG 2.2 fixe un minimum de 24 × 24 pixels CSS au niveau AA, sous réserve des exceptions prévues. L’icône visible peut être plus petite que sa zone active, mais les cibles voisines doivent rester distinctes.

Examinez ensuite la manière dont le sens est communiqué. Les erreurs, la progression et la disponibilité doivent reposer sur des indices que les utilisateurs peuvent percevoir. Les images informatives ont besoin d’alternatives textuelles utiles, les vidéos porteuses de sens de sous-titres, et les contenus uniquement audio d’une transcription ou d’un équivalent. Ce sont des décisions éditoriales : un design d’app cohérent ne peut pas les automatiser à votre place.

GoodBarber centralise la hiérarchie, les couleurs et la forme des boutons dans Style de l’app. Utilisez ces réglages pour réduire les incohérences, puis vérifiez la taille des cibles, le focus, les libellés et les états dans les versions iOS, Android et PWA générées.

Lotus Yoga utilisait à la fois un retour haptique et une animation d’ouverture. Dans Mon app > Style de l'app, nous avons désactivé l’effet d’ouverture décoratif tout en conservant le retour haptique dans les apps natives. GoodBarber propose aussi des effets de défilement au même endroit ; les options de design supplémentaires de Style de l’app expliquent où se trouvent ces réglages.

Ce choix n’est pas une prescription universelle en matière d’accessibilité. Le mouvement peut expliquer un changement d’état, et un retour haptique confirmer une action sans ajouter de surcharge visuelle. La vraie question est de savoir si l’effet transmet une information utile. Dans le cas contraire, un réglage plus calme est plus facile à justifier.

Ne considérez pas qu’une modification dans l’éditeur prouve la prise en charge de la réduction des animations. Contrôlez l’app publiée avec les préférences de mouvement de l’appareil activées et vérifiez que les actions complètes restent compréhensibles sans l’effet.

Cette version finale est plus facile à lire et à parcourir sans perdre le caractère apaisant de la marque. Surtout, les améliorations sont systémiques : une palette, une échelle typographique et un système d’espacement uniques peuvent améliorer de nombreux écrans à la fois.

L’aperçu montre les couleurs, la hiérarchie, les espacements, les libellés et les états visibles. Il ne peut pas déterminer si chaque annonce du lecteur d’écran est utile, si le focus se déplace logiquement ou si un parcours complet reste utilisable avec une méthode de saisie alternative.

Avant la publication :

• Parcourez les flux iOS essentiels avec VoiceOver et les flux Android avec TalkBack, sans regarder l’écran.
• Augmentez la taille de texte du système et recherchez les coupures, superpositions, contrôles masqués et contenus perdus.
• Vérifiez que boutons, liens, formulaires et menus possèdent des noms, rôles, états et un ordre de focus clairs.
• Testez la PWA avec la navigation au clavier, le zoom du navigateur et plusieurs tailles de fenêtre.

Les outils automatisés détectent des problèmes utiles. Ils ne comprennent pas si un libellé a du sens, si une consigne est cognitivement claire ou si une action complète devient frustrante. Les tests manuels — idéalement avec des personnes en situation de handicap — restent indispensables.

L’avantage d’un design system tient à son effet de levier. GoodBarber construit les écrans à partir de fondations partagées et de composants réutilisables. Couleurs, typographie, espacements, formes et navigation deviennent des règles reprises dans toute l’app, plutôt que des décorations isolées. Vous pouvez découvrir le Design System GoodBarber pour comprendre comment ces couches s’articulent.

Cet effet de levier établit aussi une répartition claire des responsabilités :

Le Design System de GoodBarber élimine une partie du travail répétitif lié à l’accessibilité en appliquant des règles partagées de typographie, de couleur, d’espacement et de composants dans toute l’app. Vous devez toujours valider l’interface et les contenus obtenus sur chaque plateforme.

Les WCAG s’appliquent-elles aux applications mobiles natives ?

Les WCAG ont été rédigées pour les contenus web, mais leurs principes et critères de réussite sont largement utilisés dans les travaux d’accessibilité mobile. Le projet de recommandations WCAG2Mobile du W3C explique comment appliquer les critères de niveau A et AA des WCAG 2.2 aux applications mobiles natives, web et hybrides. Ces recommandations sont informatives : elles ne constituent ni une norme mobile distincte ni une garantie de conformité juridique.

Un app builder peut-il rendre une app automatiquement accessible ?

Non. Des composants réutilisables, des réglages par défaut lisibles et des règles de design globales peuvent créer une meilleure base, mais l’accessibilité dépend aussi de la configuration, des contenus, des fonctionnalités tierces et des parcours complets. L’app générée doit encore être testée.

Que faut-il tester en premier dans une application mobile existante ?

Commencez par les parcours que les utilisateurs ne peuvent pas éviter : ouvrir l’app, naviguer, se connecter, trouver un contenu et accomplir l’action principale. Testez-les avec un lecteur d’écran, du texte agrandi et une réduction des animations, puis vérifiez les zones tactiles, les erreurs de formulaire et les alternatives aux médias.

Quel est le contraste minimal du texte dans une application mobile ?

Le niveau AA des WCAG 2.2 fixe un ratio minimal de 4,5:1 pour le texte courant et de 3:1 pour le texte de grande taille. Ces seuils sont aussi couramment utilisés pour évaluer les interfaces mobiles à l’aide des recommandations WCAG2Mobile. Considérez-les comme un plancher, pas comme un objectif de design.

Où modifier ces réglages dans GoodBarber ?

Ouvrez Mon app > Style de l'app pour gérer les couleurs globales, les polices, les marges, les boutons, les animations et le retour haptique. Les libellés et les mises en page de navigation se configurent dans la structure de l’app. Prévisualisez le résultat pendant votre travail, puis testez les versions iOS, Android et PWA générées avant la publication.

Une app accessible ne correspond pas à un style visuel particulier. Elle résulte d’une série de décisions qui permettent à davantage de personnes de percevoir les contenus, comprendre l’interface et accomplir leurs actions. Créez votre app avec GoodBarber, construisez cette base une seule fois, puis améliorez-la avec les retours de vrais utilisateurs.