Accessibilité d’une application mobile : ce que VoiceOver et TalkBack attendent

Un utilisateur aveugle se sert de son iPhone tous les jours : il fait glisser un doigt sur l’écran, VoiceOver lui lit ce qui se trouve dessous, il touche deux fois pour activer. Sur Android, TalkBack fait la même chose. Ces outils sont installés sur chaque téléphone. La seule question est de savoir si votre application leur donne de quoi travailler.

Pour chaque élément touché, le lecteur d’écran annonce trois choses : ce que c’est (un bouton, un lien, une case), comment il s’appelle, et dans quel état il est (coché, désactivé, déplié). Un texte affiché s’annonce tout seul. Le problème vient de tout le reste :

• Les boutons qui ne sont qu’une icône : une poubelle, une flèche, un cœur. Sans libellé, VoiceOver dit « bouton », rien de plus. Il faut leur donner un nom, « Supprimer le rendez-vous », pas « icône poubelle ».
• Les éléments tactiles construits à la main : une carte entière qu’on touche pour ouvrir une fiche doit être annoncée comme un bouton, pas comme cinq textes séparés.
• Les images qui portent une information : un graphique, une photo de produit. Une image décorative, au contraire, doit être ignorée.

En React Native, que j’utilise pour les applications iOS et Android, tout cela passe par quelques propriétés documentées : un libellé (« accessibilityLabel » ou « aria-label »), un rôle (« role »), un état (« accessibilityState »), et le regroupement d’éléments en un seul (« accessible »). Ce n’est pas un chantier à part, c’est une ligne par composant, à condition d’y penser au moment où on l’écrit.

Une grande partie des utilisateurs agrandit le texte de son téléphone dans les réglages, sans avoir de handicap déclaré. Une application qui respecte ce réglage grossit avec lui ; une application qui l’ignore, ou qui casse dès qu’il augmente, est illisible pour eux.

• Laissez le texte suivre le réglage du système. C’est le comportement par défaut de React Native ; le désactiver pour « protéger la maquette » est le défaut le plus courant.
• Concevez des écrans qui s’allongent plutôt que des blocs de hauteur fixe : un texte agrandi doit passer à la ligne, pas être coupé.
• Plafonnez seulement là où c’est indispensable, un titre de barre de navigation par exemple, et jamais sur le texte courant.

Apple recommande des zones tactiles d’au moins 44 × 44 points, Google de 48 × 48. Une petite icône peut rester petite à l’œil : c’est sa zone de toucher qu’on agrandit. Et toute action accessible par un geste (balayer pour supprimer, pincer pour zoomer) doit aussi l’être par un bouton, parce que les gestes changent de sens quand un lecteur d’écran est actif.

Un message de confirmation qui apparaît trois secondes, une erreur de connexion affichée en rouge, un chargement qui se termine : tout ce qui change sans action de l’utilisateur passe inaperçu au lecteur d’écran si l’application ne l’annonce pas. React Native permet de lire un message à voix haute au bon moment ; une erreur doit aussi se dire en mots, pas seulement en couleur.

Un premier diagnostic ne demande aucun outil payant, seulement les téléphones que vous avez déjà :

• Activez VoiceOver (iPhone) ou TalkBack (Android), fermez les yeux ou baissez la luminosité au minimum, et faites le parcours principal de votre application : créer un compte, réaliser l’action centrale, payer.
• Passez la taille du texte au maximum dans les réglages, puis parcourez les mêmes écrans.
• Lancez les outils des plateformes : l’Inspecteur d’accessibilité de Xcode côté iOS, l’application Accessibility Scanner de Google côté Android. Ils relèvent les libellés manquants, les contrastes et les zones tactiles trop petites.

Ce test ne remplace pas un audit, mais il dit en une heure si le parcours principal est utilisable. C’est la question qui compte en premier.

Depuis le 28 juin 2025, la directive européenne sur l’accessibilité couvre aussi les applications mobiles des services grand public qu’elle vise : commerce en ligne, banque, transport de voyageurs. Les mêmes dispenses s’appliquent qu’aux sites, à commencer par celle des entreprises de moins de dix personnes. Le détail est dans l’article sur l’obligation d’accessibilité.

Côté stores, Apple a ajouté en 2025 une rubrique Accessibilité aux fiches de l’App Store : le développeur y déclare, s’il le souhaite, ce que son application prend en charge (VoiceOver, texte agrandi, contraste suffisant, réduction des animations…). La rubrique est facultative. Elle a pourtant un effet simple : une application qui la remplit montre à ses utilisateurs qu’elle s’en est occupée, et celle qui la laisse vide le montre aussi.

Une application mobile n’a pas à inventer l’accessibilité : le téléphone la fournit. Elle a seulement à ne pas la casser.

Quand je conçois une application iOS et Android, ces points font partie de la conception des écrans, pas d’une passe finale. Ils coûtent alors très peu. Sur une application existante, le test d’une heure décrit plus haut dit s’il y a un chantier. Décrivez-moi votre application : je vous réponds sous 48 heures avec ce qu’un premier passage permettrait de vérifier, et une idée de ce qu’il faudrait reprendre.