Comment remplir les Accessibility Nutrition Labels ? Liste de contrôle App Store 2026

Calendrier de décision et action à mener cette semaine

Au 7 septembre 2026, Apple indique que les Accessibility Nutrition Labels sont initialement volontaires et qu’ils deviendront nécessaires pour les nouvelles apps et les mises à jour, sans avoir publié dans les documents officiels retenus une date universelle de mise en œuvre obligatoire. La présentation officielle des Accessibility Nutrition Labels reste donc la référence à surveiller.

Cette semaine, l’équipe devrait créer une matrice séparant les tâches courantes, les technologies d’assistance et les familles d’appareils. Tant qu’une ligne n’est pas vérifiée sur la version destinée à la publication, la décision correcte est « non déclaré » ou « non confirmé », et non une déclaration optimiste fondée sur le code.

La distinction suivante évite la plupart des erreurs :

• Support dans le code : une propriété, un modificateur ou une API a été ajouté.
• Écran utilisable : une page peut être parcourue dans un scénario limité.
• Tâche courante terminée : l’utilisateur peut accomplir une action importante, y compris ses étapes intermédiaires.
• Déclaration App Store : la capacité est représentée fidèlement dans la version publiée.

Seul le dernier niveau justifie une déclaration, et il dépend du niveau précédent.

La couverture des tâches doit guider chaque déclaration

La première étape consiste à écrire ce que l’utilisateur doit réellement accomplir après le téléchargement. Pour une app d’abonnement, la liste peut inclure le premier lancement, l’inscription, la connexion, la consultation d’une offre, l’achat, la restauration, la modification d’un réglage et la déconnexion. Pour une app créative, il faudra peut-être ajouter l’importation d’un fichier, l’enregistrement audio, le montage vidéo, l’exportation et le partage.

Il ne faut pas réduire cette liste aux écrans les plus simples. Une app peut présenter une page d’accueil parfaitement annoncée par VoiceOver et rester inutilisable si le sélecteur de formule, la confirmation de paiement ou la récupération après une erreur ne sont pas accessibles.

Pour chaque tâche, consignez :

1. le point de départ et le résultat attendu ;
2. les écrans traversés ;
3. la technologie d’assistance utilisée ;
4. les éléments qui doivent être annoncés ou activés ;
5. le résultat observé ;
6. la preuve conservée ;
7. la décision de déclaration.

Les preuves peuvent prendre la forme d’une capture annotée, d’un enregistrement de session, d’un journal de test ou d’une fiche indiquant la version de l’app et le contexte de test. Les comptes, noms d’app, identifiants de paquet, utilisateurs de test et captures destinées au partage externe doivent être anonymisés.

Le guide Apple consacré à la définition des tâches courantes explique pourquoi l’évaluation doit porter sur les parcours importants plutôt que sur la présence de propriétés dans le projet : critères officiels d’évaluation des tâches.

VoiceOver et Voice Control exigent deux décisions séparées

VoiceOver ne vérifie pas seulement si un élément possède une étiquette. Le test doit confirmer que le focus suit une logique compréhensible, que le nom et le rôle sont annoncés, que l’état et la valeur sont accessibles, et que l’action peut être exécutée sans ambiguïté. Les contrôles personnalisés, les feuilles modales, les gestes, les listes dynamiques et les messages d’erreur demandent une attention particulière.

Le référentiel Apple pour l’évaluation de VoiceOver doit être utilisé pour examiner chaque étape. Un résultat « réussi » ne signifie pas que tous les écrans sont parfaits : il doit être relié aux tâches retenues dans la matrice.

Voice Control suit une logique différente. Un bouton utilisable avec VoiceOver peut rester difficile à commander vocalement si son nom n’est pas prononçable, si plusieurs éléments partagent la même commande ou si un geste personnalisé ne possède pas d’alternative claire. L’équipe doit donc conserver une colonne dédiée dans la matrice, au lieu de recopier le résultat de VoiceOver. Les critères Apple pour Voice Control précisent les points à examiner.

Un exemple de fiche reproductible peut être conservé dans le dépôt du projet :

Tâche : acheter l’offre mensuelle
Version : release candidate
Appareil : iPhone — famille déclarée
Technologie : VoiceOver
Résultat : échec — le sélecteur de formule n’annonce pas sa valeur
Preuve : capture-achat-03.png
Décision : ne pas déclarer le support correspondant
Correctif attendu : nom, rôle, valeur et confirmation de sélection

Après correction, la même tâche doit être rejouée depuis le début. Tester uniquement l’écran corrigé ne vérifie pas la transition entre les écrans, la conservation du focus ni le message d’erreur qui suit une action refusée.

Les critères visuels se valident pendant les tâches, pas dans un écran isolé

Les grandes tailles de texte, le contraste, le mode sombre, la distinction qui ne repose pas uniquement sur la couleur et la réduction des animations doivent être évalués dans les parcours courants. Une capture de réglages montrant que Dynamic Type est activé ne prouve pas qu’un achat ou qu’un export reste réalisable avec une taille de texte élevée.

Pour le texte agrandi, vérifiez notamment :

• les titres qui passent sur plusieurs lignes ;
• les boutons dont le libellé est tronqué ;
• les tableaux qui débordent horizontalement ;
• les alertes qui masquent l’action principale ;
• les formulaires dont le clavier empêche le défilement ;
• les valeurs qui ne sont plus associées au bon libellé.

Les seuils et les conditions doivent être pris dans les critères Apple pour Larger Text, plutôt que remplacés par une règle interne non documentée.

Le mode sombre et le contraste doivent être examinés dans une tâche réelle : sélection d’un élément, lecture d’un état, confirmation d’une erreur ou comparaison de deux valeurs. Une couleur différente ne peut pas être l’unique indication si elle disparaît ou devient ambiguë dans un autre réglage d’affichage. Les principes de conception sont regroupés dans les Human Interface Guidelines sur l’accessibilité.

La réduction des mouvements mérite également un test indépendant. Une animation décorative n’est pas le seul sujet : transitions, aperçu vidéo, déplacement automatique du focus et indicateurs de progression peuvent modifier la compréhension ou l’exécution d’une tâche. Utilisez les critères Apple pour Reduced Motion et notez le comportement observé dans la preuve.

Tableau de décision pour éviter les déclarations excessives

Le tableau suivant permet de distinguer l’état du produit de la décision à prendre dans App Store Connect. Il ne remplace pas les critères Apple ; il sert à empêcher qu’une capacité partielle soit traitée comme un support global.

Cette grille est particulièrement importante pour les apps audio, vidéo et créatives. Une transcription d’accompagnement ne doit pas être assimilée automatiquement à des sous-titres synchronisés, et une description textuelle ne remplace pas nécessairement une audio-description. Commencez par déterminer si le média est indispensable à une tâche courante, puis vérifiez sa disponibilité dans les langues, états de lecture et scénarios prévus.

Les critères Apple pour les sous-titres et les audio-descriptions doivent être appliqués séparément. Une app de montage vidéo, de formation ou de création musicale doit documenter précisément ce que l’utilisateur peut percevoir et contrôler, au lieu d’indiquer simplement qu’un fichier texte est présent.

Les familles d’appareils imposent une matrice distincte

Un résultat obtenu sur iPhone ne peut pas être copié automatiquement vers iPad ou Mac. La largeur disponible, la barre d’outils, les raccourcis clavier, le pointeur, les menus, les gestes et les contrôles natifs peuvent modifier la possibilité de terminer une tâche.

La matrice minimale devrait séparer :

• la famille d’appareil réellement distribuée ;
• le parcours métier ;
• VoiceOver ;
• Voice Control ;
• texte agrandi ;
• contraste et mode sombre ;
• réduction des mouvements ;
• sous-titres et audio-description lorsqu’ils s’appliquent ;
• résultat, preuve et version testée.

Si une capacité n’a aucun sens pour un type d’appareil ou de contenu, indiquez pourquoi et vérifiez que l’option correspondante est bien proposée ou non par la version actuelle d’App Store Connect. Il ne faut pas inventer une réponse pour remplir une colonne.

Le contrôle peut être préparé localement ou sur un Mac distant. Pour une équipe qui ne conserve pas en permanence plusieurs simulateurs, états de connexion et versions de test, une machine macOS louée par période peut servir d’environnement séparé. La page française de NodeMini permet d’examiner cette approche sans confondre l’environnement de régression avec le poste principal du développeur.

La commande suivante illustre seulement une organisation de preuves ; elle ne prétend pas exécuter un audit automatique :

mkdir -p accessibility-evidence/{iphone,ipad,mac}
printf '%s\n' "version;device;task;technology;result;evidence" \
  > accessibility-evidence/matrix.csv

L’inspection visuelle avec Accessibility Inspector peut compléter les essais manuels, mais elle ne remplace pas la réalisation d’un achat, d’une importation, d’un export ou d’une récupération après erreur. Les propriétés détectées par l’outil doivent être reliées à une tâche et à un résultat observé.

Le paquet de preuves doit rester aligné sur la version publiée

Avant l’envoi, rassemblez les éléments suivants dans un paquet traçable :

1. la liste des tâches courantes et leur justification ;
2. les familles d’appareils incluses ;
3. les versions de système et de l’app utilisées ;
4. les résultats séparés pour VoiceOver et Voice Control ;
5. les captures ou journaux anonymisés ;
6. les échecs connus et les correctifs appliqués ;
7. la décision finale pour chaque label ;
8. la date de la dernière régression ;
9. la confirmation que la version testée est bien celle soumise.

Une équipe peut automatiser la préparation des builds et des simulateurs, mais l’automatisation ne doit pas produire une déclaration à partir de la seule présence d’un modificateur. Les informations de déclaration peuvent aussi être configurées via l’API officielle ; sa documentation technique décrit le périmètre des objets et des opérations disponibles. L’API accélère la saisie ; elle ne décide pas si l’utilisateur peut terminer une tâche.

Après publication, vérifiez la fiche visible et le statut de la version. Si le label n’apparaît pas immédiatement, comparez la version déclarée, le traitement de la soumission et les conditions d’affichage décrites dans la page Apple consacrée à la gestion des Accessibility Nutrition Labels. Ne corrigez pas une différence d’affichage en ajoutant une capacité qui n’a pas été testée.

La vérification finale tient sur une liste courte

Avant de confirmer la déclaration, le responsable de publication peut cocher les points suivants :

• [ ] Les tâches métier principales sont écrites avec un résultat attendu.
• [ ] Le premier lancement, la connexion, l’achat et les réglages pertinents ont été testés.
• [ ] Les contrôles personnalisés, les fenêtres, les gestes et les erreurs ont été inclus.
• [ ] VoiceOver et Voice Control possèdent des résultats distincts.
• [ ] Le texte agrandi a été vérifié pendant une tâche complète.
• [ ] Le mode sombre, le contraste et les indications non chromatiques ont été contrôlés.
• [ ] La réduction des mouvements a été évaluée dans les animations importantes.
• [ ] Les médias nécessaires disposent du support effectivement vérifié.
• [ ] L’iPhone, l’iPad et le Mac ne partagent pas une conclusion non testée.
• [ ] Les preuves sont anonymisées et rattachées à la version candidate.
• [ ] Aucun correctif encore absent de la version publiée n’est déclaré.
• [ ] La fiche App Store Connect a été relue après traitement de la version.

Si plusieurs cases restent indécises, le choix prudent est de ne pas déclarer la capacité correspondante et de créer une tâche corrective. Les labels peuvent être enrichis après une validation réelle ; une déclaration trop large, elle, fragilise la confiance dans la fiche et rend les régressions plus difficiles à repérer.

Pour une petite équipe, conserver cette matrice sur une machine locale encombrée par plusieurs simulateurs peut aussi créer des états difficiles à reproduire, des comptes de test mélangés et des preuves dispersées. Un Mac distant réservé par période offre alors un environnement isolé pour reconstruire les parcours, exécuter Accessibility Inspector et conserver les résultats de régression sans immobiliser un Mac personnel. Cette solution ne remplace ni les appareils physiques ni la validation humaine, mais elle convient aux campagnes temporaires et aux versions candidates.

La meilleure approche consiste donc à comparer le poste actuel et le Mac distant selon les contraintes réelles : le poste local évite la latence et reste préférable pour un travail quotidien ou pour les périphériques physiques ; en revanche, il peut manquer d’espace, de disponibilité continue et de séparation entre les tests. Un environnement distant exige une connexion stable et ne résout pas tous les cas liés au matériel, mais il permet de réserver une machine macOS dédiée, de repartir d’un état documenté et de maintenir une chaîne de régression accessible à l’équipe. Dans ce contexte précis, louer un Mac auprès de NodeMini peut être plus cohérent que conserver une machine supplémentaire uniquement pour les campagnes d’accessibilité et les versions de validation. Consultez les options de Mac distant disponibles chez NodeMini après avoir défini les appareils et les tâches à tester.

Le critère de décision reste inchangé : une API présente ne suffit pas. Seule une tâche courante réellement accomplie, sur la famille d’appareils concernée et dans la version destinée aux utilisateurs, justifie le label correspondant.