Notes de version Axe DevTools Mobile du 16 septembre 2026

Si vous êtes sur Xcode 27 et exécutez une application Mobile Analyzer Desktop antérieure à 2.0.0, l'application ne peut pas ouvrir le simulateur iOS. Elle échoue lorsqu'elle essaie de lancer /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Vous ne pouvez pas démarrer un scan basé sur le simulateur tant que cela n'est pas résolu.

Pour lancer les analyses à l'aide d'un simulateur sur Xcode 27, mettez à jour le Desktop Analyzer à la version 2.0.0+. Avec cette mise à jour, veuillez noter que les résultats d'accessibilité se trouvent maintenant dans Axe Developer Hub.

Le SDK Axe DevTools utilise le framework Vision d'Apple pour lire le texte à l'écran pour plusieurs règles d'accessibilité (par exemple, contraste des couleurs, vues qui se chevauchent, toute règle dépendant du texte détecté par Vision).

Vision ne renvoie pas toujours le même texte détecté lors de l'exécution du même écran. Lorsque Vision manque le texte sur un contrôle, les règles qui reposent sur ce texte ne s'exécuteront pas pour cet élément lors de cette analyse. Les résultats peuvent sembler incohérents entre deux analyses du même écran - un problème qui échoue lors d'une analyse peut être absent lors de la suivante.

Lorsqu'une règle basée sur Vision signale un échec, cet échec est précis. L'incohérence réside dans l'exécution ou non de la règle. Pour surmonter ce problème, essayez les actions suivantes :

• Relancez l'analyse. Si une règle basée sur Vision a été omise pour un contrôle, une autre analyse du même écran la détectera souvent.
• Considérez tout échec d'une règle basée sur Vision comme valide - si le contraste des couleurs signale un contrôle, le problème de contraste est réel et doit être corrigé.
• Pour une vérification manuelle, utilisez la référence Deque University pour le critère de réussite WCAG pertinent. (Des liens peuvent être trouvés en bas de chaque page de règles.)

Sur iOS 26 et versions ultérieures, si un écran contient du texte avec un signe de pourcentage (par exemple, une étiquette de texte indiquant "50% de réduction"), la règle Supports Dynamic Type peut être signalée comme Incomplète au lieu d'un succès ou d'un échec. Cette règle repose sur un audit d'accessibilité fourni par Apple, et cet audit arrête l'exécution du test lorsqu'il rencontre des signes de pourcentage. Pour que vos tests continuent, notre règle passe cette vérification pour cet écran et signale incomplète pour chaque élément contenant un signe de pourcentage. Toutes les autres règles s'exécutent normalement sur l'écran, et les autres écrans ne sont pas affectés.

Aucune action n'est requise, car votre analyse se terminera toujours. Pour vérifier la prise en charge de Dynamic Type pour ces écrans, augmentez la taille du texte sur votre appareil sous **Réglages** > **Accessibilité** > **Affichage et taille du texte** > **Texte plus grand**, et confirmez que le texte à l'écran s'adapte correctement. Ce problème a été signalé à Apple. (#2985)

La règle de contraste des couleurs utilise le framework Vision (reconnaissance optique de caractères, OCR) d'Apple pour lire le texte à l'intérieur des limites d'un élément. L'OCR peut parfois mal identifier de petits glyphes ressemblant à des icônes - tels que des chevrons de flèches de retour (<), des puces, des symboles décoratifs - comme du texte. Lorsque cela se produit, la règle de contraste des couleurs s'exécute sur un élément qui ne contient pas de texte lisible, ce qui peut produire un résultat pour un bouton uniquement icône. Parce que la sortie OCR n'est pas déterministe d'une analyse à l'autre, le même élément peut apparaître dans les résultats de contraste des couleurs lors d'une analyse et être signalé comme "INAPPLICABLE" lors de l'analyse suivante. C'est une caractéristique connue de l'OCR, pas un bogue dans la règle.

Pour contourner ce problème, vous pouvez utiliser les ignore APIs pour supprimer les résultats de contraste des couleurs pour les éléments affectés.

Flutter ne mappe pas AppBar.title à la propriété native du titre de l'écran - UIViewController.title, causant l'échec de la règle du titre d'écran sur tous les écrans Flutter, peu importe si un titre descriptif est présent.

C'est une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Lors de l'exécution de vérifications d'accessibilité sur des tailles d'écran plus petites ou avec des tailles de police plus petites, la règle de contraste des couleurs peut signaler de faux positifs pour des arrière-plans en dégradé. Dans de tels cas, elle peut être incapable de déterminer la couleur du premier plan et comparer à la place les couleurs d'arrière-plan entre elles, entraînant un échec.

Pour contourner ce problème, essayez d'exécuter des vérifications d'accessibilité sur des appareils plus grands. Vous pouvez également choisir d'ignorer la règle dans vos tests et vérifier manuellement le contraste des couleurs pour ces vues.

Les APIs d'accessibilité d'Apple peuvent signaler de manière incorrecte du contenu web à l'intérieur de WKWebView comme "isVisible", même lorsque la vue web est couverte par des superpositions natives (tels que des vues modales, des alertes ou d'autres éléments d'interface utilisateur natives). Cela se produit parce que le système d'accessibilité vérifie si le conteneur WKWebView lui-même est visible, plutôt que de savoir si son contenu web est réellement non obstrué et perceptible pour l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons de réglage par défaut n'annoncent pas "atténué" par la technologie d'assistance pour indiquer qu'ils ne sont pas activés. Par conséquent, les règles iOS considèrent également ces boutons comme activés même s'ils ne le sont pas. Un rapport de bug a été déposé auprès d'Apple, mais tant que cela n'est pas résolu, les règles suivantes peuvent signaler des résultats sur les boutons de réglage désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la résolution sera d'[ignorer les règles](ios-ignore-rule). Les boutons de réglage par défaut ont les identifiants "Decrement" et "Increment", et peuvent être ignorés par identifiant si nécessaire.

Our Color Contrast rule depends on Machine Learning to detect text, which ensures that the text being scanned is visible to users of your application. In cases where the text contained in a view is the same color as the background, our Machine Learning algorithm is unable to detect if any text is present, so the Color Contrast rule does not run on this view.

Certains écrans peuvent signaler des faux positifs avec LabelInName et LabelAtFront en raison d'une propriété associatedText incorrectement trouvée (#1622)

Lors de l'examen d'une amélioration pour nos règles, nous avons constaté que dans XCTest, les contrôles imbriqués ne sont pas retournés dans l'arborescence d'accessibilité. Un bug a été déposé auprès d'Apple. (#1110)

Dans les applications UIKit, une image sans `accessibilityLabel` n'est pas focalisable avec la technologie d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisation d'Apple peuvent être inexactes lorsqu'un `accessibilityIdentifier` est défini sur l'image. En raison de ce comportement inattendu, les résultats pour les problèmes de nom ImageView dans les applications UIKit seront signalés comme nécessitant une révision. Un rapport de bogue a été déposé auprès d'Apple. (#1633)

Nous travaillons activement sur des correctifs pour les faux positifs suivants et nous mettrons à jour cette liste au fur et à mesure que les correctifs seront publiés.

In Scroll View
Les textes dans les éléments se comportant comme des bannières, les en-têtes/pieds de page fixes, les boutons d'action flottants et les vues de tabulation personnalisées peuvent être signalés avec le message "nécessite une révision" ou "écouer". Pour rendre ces éléments disponibles à ceux qui ont besoin d'un texte plus grand, utilisez UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si une UIImageView a un accessibilityIdentifier défini mais n'est pas focalisable par VoiceOver, et qu'elle comporte des contrôles focalisables imbriqués, Active Control Name peut signaler un faux positif sur l'UIImageView. Retirez le accessibilityIdentifier résout le problème. Un bug a été signalé à Apple. (#1633)

Label In Name and Label At Front
Ces deux règles recherchent le libellé visible d'un contrôle parmi les éléments proches pour aider à déterminer l'état de la règle. Dans certaines hiérarchies de vue, le texte incorrect à proximité peut être détecté, provoquant l'échec de ces règles. (#1622)

La règle Libellé au Début vérifie que le libellé visible d'un élément apparaît au début de son texte annoncé. Un échec de la règle peut se produire lorsqu'un élément interactif contient un texte visible avec une abréviation (par exemple, « GB », « km ») ou un identifiant obscurci/tronqué, et que l'annonce d'accessibilité consiste en les mots représentés (par exemple, « gigaoctets », « kilomètres »), bien que ce soit le modèle recommandé pour rendre le contenu abrégé ou tronqué accessible aux lecteurs d'écran.

Si la première partie du libellé visible d'un élément interactif correspond au début de l'annonce du lecteur d'écran et que seule la partie abrégée/obscurcie diffère, le résultat signalé peut être ignoré en toute sécurité. Vérifiez avec un lecteur d'écran que l'annonce complète est lue comme prévu.

Lors de l'utilisation de texte décoratif dans des vues telles que "Icônes de Contacts", il est possible d'introduire un problème d'accessibilité. Si vous utilisez une vue de texte pour afficher des lettres au lieu de générer des images avec les lettres souhaitées en tant que vecteurs, et que vous déclarez ensuite cette vue de texte comme non importante pour l'accessibilité, nous ne pourrons pas déterminer de manière fiable si vous avez introduit une violation d'accessibilité.

Si vous modifiez le texte focalisable pour ignorer deux caractères ou moins, vous pouvez par inadvertance ignorer de nombreux boutons d'un mot dans diverses langues (par exemple, « OK », « Non », « Sí »). Pour éviter ces problèmes, vous devriez extraire les lettres souhaitées du mot que vous souhaitez représenter dans l'icône et générer les lettres dans l'image plutôt que comme vues de texte séparées. `FocusableText` ne s'exécutera alors pas sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété native du titre de l'écran - Activity.setTitle, causant l'échec de la règle du titre d'écran sur tous les écrans Flutter, peu importe si un titre descriptif est présent.

C'est une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Dans certains cas, la technologie d'assistance repose sur AccessibilityEvent des descriptions du système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Étant donné que AccessibilityEvents sont déclenchées par les actions de l'utilisateur, nous ne pouvons pas accéder à la bonne description si cette information n'est pas fournie.

Pour éviter ce problème, assurez-vous que toutes les vues pertinentes sont marquées comme importantes pour l'accessibilité. Cela permettra à Talkback d'accéder aux informations de la vue, que notre outil pourra alors détecter.

Notre règle de contraste des couleurs dépend de l'apprentissage automatique pour détecter le texte, ce qui garantit que le texte analysé est visible pour les utilisateurs de votre application. Dans les cas où le texte contenu dans une vue est de la même couleur que l'arrière-plan, notre algorithme d'apprentissage automatique est incapable de détecter si un texte est présent, donc la règle de contraste des couleurs ne s'exécute pas sur cette vue.

Les applications écrites avec XML qui utilisent la fonctionnalité de texte indicatif peuvent voir des faux positifs avec la EditTextName règle. Le texte indicatif n'a pas été introduit avant Android 8 (SDK 26). Utiliser cet élément dans votre application XML attribuera le texte indicatif à la valeur du champ de saisie de texte. Les versions plus récentes d'Android sont mieux équipées pour rendre cette expérience accessible.

Pour surmonter ce problème, notre première recommandation est d'exécuter vos tests sur des versions plus récentes d'Android. Cependant, si l'importance de l'accessibilité de l'application sur les versions antérieures d'Android est primordiale, vous pourriez envisager d'éviter l'utilisation de la hintText fonctionnalité, car elle n'est pas officiellement supportée.

Vous pouvez voir des résultats pour des vues qui sont cachées derrière d'autres vues à l'écran. Ces vues cachées ne sont pas accessibles à la technologie d'assistance, mais Axe DevTools Mobile les signale toujours comme des problèmes.

Nous travaillons sur une solution pour ce problème complexe. En attendant, si TalkBack ne peut pas atteindre ces vues, vous pouvez ignorer les problèmes correspondants. Ils ne nécessitent pas de correction pour assurer l'accessibilité.

La détection de texte ML Kit est requise dans de nombreuses règles d'Axe DevTools Mobile pour garantir la précision des résultats. La bibliothèque ML Kit doit être automatiquement importée lors de la référence d'Axe DevTools Mobile dans vos tests automatisés Espresso ou UIAutomator. Cependant, dans certains cas, l'importation automatique ne se produit pas et vous verrez l'erreur suivante dans le logcat :

La règle d'Espacement des Cibles Tactiles ne s'exécute actuellement sur aucun composant de curseur écrit en Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, une solution arrive bientôt !

Sur Android API 30, l'un des emplacements où nous tentons de sauvegarder les résultats localement présente une erreur de permissions. Le résultat sera tout de même sauvegardé en tant que fichier JSON malgré l'affichage de cette erreur. L'erreur peut être supprimée en commentant le code dans le bloc suivant :

Dans certaines applications hybrides et multiplateformes, nous pouvons obtenir des résultats inattendus lorsque les éléments d'une vue de défilement sont partiellement hors écran. Pour tester un élément pour l'accessibilité, assurez-vous qu'il est entièrement visible à l'écran avant d'effectuer le scan.

Introduite avec l'API 31 (Android 12), la possibilité de masquer les superpositions non systèmes. Pour utiliser l'application d'analyse Axe, assurez-vous que ce paramètre n'est pas activé. Si vous avez choisi d'utiliser cette fonction pour ses améliorations de sécurité, nous vous recommandons de la laisser désactivée pour les versions de test internes où vous pouvez utiliser en toute sécurité des données de test et éliminer ainsi les préoccupations de sécurité. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Pour utiliser l'application Axe Accessibility Analyzer, mettez à jour tous les appels à la méthode setHideOverlayWindows(true) sur les fenêtres d'activités affectées. setHideOverlayWindows(false)

Pour déverrouiller la pleine fonctionnalité d'Axe DevTools for Mobile, assurez-vous que les captures d'écran sont activées. Nous recommandons d'activer les captures d'écran sur une version de débogage ou de test de votre application qui utilise des données simulées pour éviter les préoccupations de sécurité. Consultez notre guide pour activer les captures d'écran dans les applications Android.

Si vous minifiez votre build, vous verrez un plantage avec un journal d'erreurs signalant qu'un adaptateur n'a pas été trouvé lors de la tentative de connexion à la bibliothèque Axe DevTools. Désactivez la minification pour vos builds de débogage avec Axe DevTools implémenté. (#729)

Un build avec r8 activé peut tenter de minifier la bibliothèque axeDevTools, entraînant une erreur similaire à :

Les APIs Compose sont obsolètes, veuillez utiliser les APIs indépendantes de la mise en page pour continuer à recevoir les mises à jour. Si vous continuez à utiliser les APIs Compose et rencontrez une erreur telle que `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` ou `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, veuillez vous référer à API Compose setTestTag.

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle de nom d'édition de texte apparaîtra comme À réviser dans le tableau de bord lorsqu'une défaillance est suspectée pour les versions SDK 5.5.0 et supérieures. Veuillez confirmer manuellement le comportement correct pour ce cas.

Lorsque vous implémentez des dialogues ou modales personnalisés qui n'étendent pas les contrôles natifs, vous pouvez obtenir des résultats pour les vues derrière le modal. Dans ce cas, nous recommandons de ne pas exécuter notre outil sur ces modales ou dialogues personnalisés et de les vérifier manuellement pour assurer qu'ils fonctionnent avec les technologies d'assistance comme souhaité.

Si la capture d'écran est manquante dans la page de détails de l'analyse, votre application peut empêcher la prise de captures d'écran. Souvent, cela est pour des raisons de sécurité dans votre application de production. Envisagez de supprimer cette exigence pour votre version de test afin de permettre une fonctionnalité complète dans le tableau de bord Axe DevTools Mobile.

• Android - FLAG_SECURE

Certains noms d'analyse Android qui sont définis par défaut sur le titre de l'écran apparaîtront comme le nom complet de la classe, y compris l'identifiant du bundle. Dans une future version, cela sera résolu afin que le titre de l'écran soit formaté en un nom plus lisible. En guise de solution de contournement, vous pouvez définir le nom de l'analyse depuis le tableau de bord ou les frameworks. (#1643)