Étiquettes d’accessibilité App Store : comment évaluer une app

Une étiquette engage toute l’expérience

Un écran peut être parfaitement lisible sans que l’app soit réellement accessible. VoiceOver annonce peut-être chaque produit d’un catalogue, puis reste bloqué dans la fenêtre de paiement. Le texte agrandi fonctionne sur l’accueil, mais fait disparaître le bouton de confirmation lors de la récupération du compte. Pour la personne concernée, le parcours s’arrête là. Les neuf écrans réussis ne compensent pas celui qui empêche d’aboutir.

Les Accessibility Nutrition Labels, que les pages françaises d’Apple appellent simplement étiquettes d’accessibilité, cherchent à rendre cette réalité visible avant le téléchargement. Elles ne récompensent pas la présence d’une API ou d’un mode sombre. Elles indiquent qu’une personne peut réaliser toutes les tâches courantes de l’app avec la fonction annoncée.

La fiche App Store vient donc en dernier. Avant de cocher quoi que ce soit, l’équipe doit définir les parcours, tester la version en cours et conserver des preuves. Notre check-list d’accessibilité mobile donne une base générale ; l’audit des étiquettes transforme ensuite cette base en décision de publication, appareil par appareil.

Neuf fonctions, avec des exigences différentes

Les informations apparaissent sur la page produit à partir d’iOS 26 et des versions correspondantes des autres systèmes Apple. L’App Store affiche les données liées au type d’appareil consulté. Certaines étiquettes ne sont pas proposées partout : le texte agrandi n’est pas une étiquette Mac, par exemple, et la commande vocale ne concerne pas Apple TV ou Apple Watch dans ce cadre.

Il n’est ni nécessaire ni souhaitable de tout déclarer. Les audiodescriptions peuvent ne pas s’appliquer à un outil sans vidéo significative. En revanche, une plateforme de formation ne peut pas revendiquer les sous-titres simplement parce que son lecteur sait les afficher : les vidéos nécessaires au parcours doivent effectivement en proposer.

Apple présente d’abord ces informations comme facultatives, tout en annonçant qu’elles seront demandées à terme pour les nouvelles apps et les mises à jour. Dès aujourd’hui, une page peut indiquer qu’aucune prise en charge n’a encore été renseignée. Mieux vaut donc utiliser cette période pour corriger le produit, pas pour repousser le sujet.

Partir des raisons pour lesquelles on ouvre l’app

Dans une app de transport, les tâches courantes peuvent être : définir un départ, choisir une destination, comprendre l’itinéraire, commander, suivre le véhicule, payer et signaler un problème. Pour un service de réservation : trouver une prestation, sélectionner un créneau, saisir ses coordonnées, payer, déplacer le rendez-vous et joindre l’établissement.

Ajoutez les fonctions transversales qui peuvent bloquer n’importe quel produit : premier lancement, consentement, inscription, connexion, récupération d’accès, paramètres, restauration d’achat, suppression de compte et assistance. Une tâche peu fréquente n’est pas forcément secondaire. Quand une personne a perdu son mot de passe, la récupération devient immédiatement essentielle.

La bonne formulation décrit un résultat complet. « Réserver et modifier un rendez-vous » est plus utile que « ouvrir la page calendrier ». Elle oblige le test à traverser les formulaires, les autorisations, les messages, les erreurs et les confirmations. C’est justement dans ces transitions que les défauts se cachent.

En cas de doute, demandez-vous si l’équipe publierait un correctif urgent si cette tâche cessait de fonctionner pour tout le monde. Si oui, elle appartient à la liste. Un lien promotionnel secondaire pourra rester en dehors ; un paiement ou une suppression de compte, non.

*Une étiquette devient crédible lorsque chaque itinéraire important atteint sa destination, pas lorsqu’un seul écran réussit le contrôle.*

Construire une matrice par famille d’appareils

Placez les tâches en lignes et les fonctions pertinentes en colonnes. Dans chaque cellule, notez le résultat, la version, l’appareil, la personne qui a testé et le lien vers une preuve ou une anomalie.

Avec ces résultats, VoiceOver et le texte agrandi ne sont pas encore publiables. La majorité des cases est verte, mais les deux cases rouges empêchent une tâche indispensable. La matrice évite de discuter en pourcentage : elle montre les défauts à corriger, puis les chemins à retester.

Gardez des matrices distinctes pour iPhone et iPad lorsque l’interface ou les fonctions diffèrent. Un panneau latéral, une fenêtre flottante ou un formulaire en deux colonnes créent des risques propres à la tablette. Apple Watch, Apple TV, visionOS et une véritable app Mac demandent la même attention. Pour les cas particuliers, notamment une app iPhone compatible avec les Mac Apple silicon, référez-vous aux règles App Store Connect à jour.

Un outil automatique ne comprend pas l’objectif du parcours

Accessibility Inspector et les audits automatisés trouvent rapidement des libellés absents, une partie des contrastes faibles et certains problèmes de structure. Ils ne savent pas si cinq boutons nommés « Plus » sont impossibles à distinguer, ni si le message d’erreur est annoncé après que le focus est reparti en haut de la page.

Avec VoiceOver, parcourez donc la tâche entière : déplacez le focus, saisissez du texte, déclenchez une erreur, fermez une fenêtre et revenez à l’étape précédente. Le rideau d’écran évite qu’une personne voyante compense inconsciemment un problème. Pour la commande vocale, ne touchez pas l’écran ; les intitulés ambigus et les gestes sans alternative apparaissent immédiatement.

Pour le texte agrandi, testez le seuil attendu par Apple et les tailles supérieures utiles, pas une simple augmentation légère. Ouvrez le clavier, passez en paysage, affichez une erreur longue et inspectez les panneaux bas, les graphiques et les petits appareils. Le vrai échec est souvent un texte qui grandit correctement mais repousse l’action hors d’atteinte.

Enfin, faites participer des personnes qui utilisent ces fonctions au quotidien. Une équipe de développement peut trouver de nombreux défauts techniques ; un utilisateur expérimenté repère plus vite une navigation pénible, un ordre incohérent ou des annonces trop bavardes. Ce contrôle spécialisé complète la recette générale avant publication.

Chaque groupe de fonctions produit ses propres preuves

VoiceOver et la commande vocale utilisent une partie des mêmes données d’accessibilité, mais ne se valident pas ensemble. VoiceOver a besoin de noms, rôles, valeurs, ordre de focus et annonces correctes. La commande vocale exige en plus des mots que la personne peut raisonnablement prononcer. « Ajouter aux favoris » décrit mieux l’action que « cœur ».

Le texte agrandi teste le système de mise en page. Les cartes de hauteur fixe, les polices personnalisées, les graphiques et les panneaux compacts sont souvent les premiers à casser. Il faut permettre le retour à la ligne, le défilement ou un changement de disposition, pas réduire à nouveau la police.

La couleur, le contraste et les mouvements doivent être observés dans leurs différents états : thème clair et sombre, sélection, erreur, désactivation, chargement, carte et graphique. Activez Réduire les animations avant de lancer l’app et surveillez transitions, parallaxes, célébrations et médias en boucle.

Sous-titres et audiodescriptions supposent un processus éditorial. Qui contrôle un nouveau média ? Quelles langues sont couvertes ? Que se passe-t-il avec le direct ou les contenus partenaires ? Une couverture partielle doit être expliquée sur la page d’accessibilité au lieu d’être masquée par une déclaration trop large.

Publier dans App Store Connect sans rompre la chaîne de preuve

Dans l’app concernée, ouvrez App Accessibility, choisissez l’appareil et sélectionnez uniquement les fonctions validées. Enregistrez le brouillon puis publiez les réponses souhaitées. Apple précise que la mise à jour est immédiate, mais qu’elle peut mettre jusqu’à 24 heures à devenir visible pour tout le monde.

Plusieurs rôles disposent des droits nécessaires, notamment Account Holder, Admin, App Manager et Marketing. Cela ne signifie pas que la personne chargée du store doit deviner. Le produit définit les tâches, la qualité maintient la matrice, le design et le développement corrigent, la responsabilité de publication vérifie les preuves et le compte autorisé publie la décision.

Réexaminez les réponses lorsque changent l’authentification, la navigation, le paiement, les médias, le système de composants ou les appareils pris en charge. Une expérimentation distante peut également dégrader un parcours sans nouvelle version binaire ; les variantes majeures méritent le même contrôle.

La page d’accessibilité donne le contexte qui manque à une étiquette

App Store Connect accepte une URL propre à l’app. Elle peut expliquer les réglages internes, les fonctions qui dépassent les neuf étiquettes, les langues de sous-titrage, les limites connues, les versions couvertes et le moyen de contacter l’assistance. Ajoutez une date de révision pour que le lecteur sache à quelle version se fier.

Évitez les grandes déclarations sans information pratique. La personne veut savoir si elle pourra acheter, réserver ou suivre une leçon. Une limite clairement expliquée avec une voie de contact inspire davantage confiance qu’une promesse universelle contredite par l’app.

Apple indique aussi que les fonctions peuvent contribuer à des recherches App Store précises, par exemple un type d’app associé à VoiceOver ou au texte agrandi. Une déclaration exacte peut donc renforcer une visibilité très qualifiée. La localisation de la page produit pourra ensuite présenter cette valeur avec les mots du marché visé.

La méthode Appfyl

Chez Appfyl, nous rattachons chaque déclaration à un parcours vérifiable : compte, action principale, achat, réglages, récupération et assistance. Nous pouvons transformer ces parcours en critères de recette, corriger les composants responsables et laisser une matrice que l’équipe réutilisera lors des versions suivantes.

La personne qui publie n’a ainsi rien à inventer. Pour une nouvelle app ou une refonte, échangez avec Appfyl sur le produit et sa préparation au lancement. La première question utile n’est pas « quelles cases cocher ? », mais « quelle tâche essentielle chacun doit-il pouvoir terminer ? ».

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes