Notes de version d'Axe DevTools Mobile du 23 octobre 2026

Lors de l'analyse d'un écran avec des hiérarchies de vue larges ou complexes, la commande axeScan peut prendre plus de 60 secondes pour s'exécuter. Le proxy WebDriverAgent (WDA) d'Appium applique un délai d'attente par défaut de 60 secondes aux commandes inconnues, et axeScan tombe dans cette catégorie. Si l'analyse n'est pas terminée dans ce délai, WDA annule la demande et le test déclenche une erreur de délai d'attente

Pour remplacer le délai d'attente par commande pour les commandes proxifiées via WDA telles que axeScan, nous recommandons les paramètres suivants dans vos capacités Appium :

• appium:commandTimeouts: 240000 (4 minutes)
• appium:wdaConnectionTimeout: 30000 (5 minutes)

Note: appium:newCommandTimeout is a different setting. It controls how long Appium waits between commands from the test script. That is not the cause of this issue. The relevant setting is appium:commandTimeouts

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

Pour exécuter des 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 désormais dans Axe Developer Hub.

Le SDK Axe DevTools utilise le cadre Vision d'Apple pour lire le texte à l'écran pour plusieurs règles d'accessibilité (par exemple, Contraste des Couleurs, Vues en Collision, ou toute règle dépendant du texte détecté par Vision).

Vision ne renvoie pas toujours le même texte détecté entre les exécutions du même écran. Lorsque Vision ne parvient pas à détecter le texte sur un contrôle, les règles qui dépendent de ce texte ne s'appliqueront pas à 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 le fait que la règle s'exécute ou non. Pour surmonter ce problème, essayez ce qui suit :

• Relancez l'analyse. Si une règle basée sur Vision a été ignorée pour un contrôle, une autre analyse du même écran la détecte souvent.
• Considérez tout échec d'une règle basée sur Vision comme valide - si 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 de Deque University pour le critère de réussite WCAG pertinent. (Des liens peuvent être trouvés en bas de chacune des pages de règles.)

Sur iOS 26 et ultérieur, 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 de Prise en charge de la taille dynamique peut signaler le résultat comme Incomplet 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 continuer vos tests, notre règle ignore la vérification de cet écran et signale incomplet 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, puisque votre analyse sera toujours terminée. Pour vérifier le support de la taille dynamique pour ces écrans, augmentez la taille du texte sur votre appareil sous **Paramètres** > **Accessibilité** > **Affichage et Taille du Texte** > **Texte Large**, et confirmez que le texte sur l'écran est mis à l'échelle de manière appropriée. Ce problème a été signalé à Apple. (#2985)

La règle de Contraste des Couleurs utilise le cadre Vision d'Apple (Reconnaissance Optique de Caractères, ou OCR) pour lire le texte à l'intérieur des limites d'un élément. L'OCR peut occasionnellement identifier à tort de petits glyphes ressemblant à des icônes - tels que les chevrons flèche de retour (<), les puces, les symboles décoratifs - comme du texte. Lorsque cela se produit, la règle de Contraste des Couleurs s'applique à un élément qui ne contient pas de texte lisible, ce qui peut produire un résultat pour un bouton contenant uniquement une icône. Parce que la sortie de l'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 la suivante. C'est une caractéristique connue de l'OCR, pas un bug de la règle.

Pour contourner ce problème, vous pouvez utiliser les ignore API pour supprimer les résultats de Contraste des Couleurs pour les éléments concernés.

Flutter ne mappe pas AppBar.title à la propriété titre d'écran native - UIViewController.title, provoquant l'échec de la règle Titre de l'écran sur tous les écrans Flutter, indépendamment de la présence d'un titre descriptif.

Ceci 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 Contraste des Couleurs peut signaler de faux positifs pour les arrière-plans en gradient. Dans de tels cas, il peut être incapable de déterminer la couleur de premier plan et comparer plutôt les couleurs d'arrière-plan entre elles, entraînant un échec.

Pour contourner ce problème, essayez de faire fonctionner les vérifications d'accessibilité sur des appareils plus grands. Alternativement, vous pouvez choisir d'ignorer la règle dans vos tests et vérifier manuellement le Contraste des Couleurs pour ces vues.

Les API d'accessibilité d'Apple peuvent signaler à tort le contenu web à l'intérieur de WKWebView comme étant "isVisible", même lorsque la vue Web est couverte par des superpositions natives (telles que des vues modales, des alertes ou d'autres éléments d'interface utilisateur native). Cela se produit parce que le système d'accessibilité vérifie si le conteneur WKWebView lui-même est visible, plutôt que si son contenu web est réellement dégagé et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons de stepper par défaut n'annoncent pas "atténué" par la technologie d'assistance pour indiquer qu'ils ne sont pas activés. En conséquence, 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 jusqu'à ce que ce problème soit résolu, les règles suivantes peuvent signaler des résultats sur les boutons de stepper désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution est de [ignorer les règles](ios-ignore-rule). Les boutons de stepper par défaut portent 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.

Certaines écrans peuvent signaler de faux positifs avec LabelInName et LabelAtFront en raison d'une associatedText propriété incorrecte 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'arbre d'accessibilité. Un bug a été signalé à 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 focalisabilité 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 d'ImageView dans les applications UIKit apparaîtront comme nécessitant une révision. Un rapport de bug a été déposé auprès d'Apple. (#1633)

Nous travaillons activement sur des correctifs pour les faux positifs énumérés ci-dessous et mettrons à jour cette liste au fur et à mesure que des correctifs seront publiés.

In Scroll View
Le texte dans les éléments se comportant comme des bannières, les en-têtes/pieds de pages collants, les boutons d'action flottants et les vues d'onglets personnalisés peuvent être signalés avec un message "Nécessite Révision" ou "Échec". Pour rendre ces éléments disponibles à ceux qui nécessitent un texte plus grand, utilisez UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si un UIImageView a une accessibilityIdentifier définie mais n'est pas focalisable par VoiceOver, et qu'il contient des contrôles focalisables imbriqués, le nom du contrôle actif peut signaler un faux positif sur l'UIImageView. Retirer 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 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)

Le bouton d'action flottant (FAB) de l'Android Accessibility Analyzer n'est pas compatible avec la navigation par balayage de Talkback dans les versions de Talkback antérieures à 16.2. Avec la sortie de la version 16.2, Talkback a corrigé un bug dans leur code pour permettre le focus par balayage pour les FAB en superposition.

Notez qu'il s'agit purement d'un bug de Talkback, qui ne permettait pas aux FAB rendus dans des superpositions d'accessibilité de gagner ou de perdre le focus via le balayage. La récente mise à jour de notre application Accessibility Analyzer permet de scanner plus de types d'applications ; vous pourriez donc constater ce problème que maintenant.

Ce problème peut être résolu en mettant à jour Talkback à la version 16.2 ou ultérieure.

La règle du label à l'avant vérifie que le libellé visible d'un élément est au début de son texte annoncé. Un échec de la règle peut survenir lorsque le texte visible d'un élément interactif contient une abréviation (par exemple "Go", "km") ou un identifiant obstrué / tronqué, et que l'annonce d'accessibilité consiste en les mots représentés (par exemple "gigaoctets", "kilomètres"), bien que ce soit le schéma 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 / obstruée 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 se lit comme prévu.

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

Si vous modifiez un texte focalisable pour ignorer deux caractères ou moins, vous risquez de manière inattendue d'ignorer de nombreux boutons d'un mot dans différentes langues (par exemple "OK", "No", "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 comme partie de l'image plutôt que comme des vues texte séparées. `FocusableText` ne s'exécutera pas alors sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété titre d'écran native - Activity.setTitle, provoquant l'échec de la règle Titre de l'écran sur tous les écrans Flutter, indépendamment de la présence d'un titre descriptif.

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

Dans certains cas, la technologie d'assistance s'appuie sur des AccessibilityEvent descriptions du système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Comme les AccessibilityEventsont déclenchées par les actions de l'utilisateur, nous ne pouvons pas accéder à la description correcte 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 à partir de la vue, que notre outil peut alors détecter.

Notre règle de Contraste des Couleurs repose sur l'apprentissage automatique pour détecter le texte, ce qui garantit que le texte scanné 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 Contraste des Couleurs ne s'exécute pas sur cette vue.

Les applications écrites avec XML qui utilisent la fonctionnalité de texte d'indication peuvent rencontrer des faux positifs avec la EditTextName règle. Le texte d'indication n'a été introduit qu'à partir d'Android 8 (SDK 26). Utiliser cet élément dans votre application XML attribuera le texte d'indication à 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. S'il est important que l'application soit accessible sur des versions antérieures d'Android néanmoins, vous pourriez envisager d'éviter l'utilisation de la hintText fonctionnalité, car elle n'est pas officiellement prise en charge.

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 à la disposition de la technologie d'assistance, mais Axe DevTools Mobile les signale toujours comme des problèmes.

Nous travaillons sur une correction 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 garantir l'accessibilité.

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

La règle d'espacement de la cible tactile ne s'exécute actuellement sur aucun composant curseur écrit en Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, une correction arrive bientôt !

Sur Android API 30, l'un des emplacements où nous tentons d'enregistrer les résultats localement présente une erreur de permissions. Le résultat sera toujours enregistré sous forme de 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 renvoyer des résultats inattendus lorsque des éléments dans une vue de défilement sont partiellement hors écran. Pour tester un élément pour l'accessibilité, assurez-vous qu'il est entièrement à l'écran avant d'effectuer le scan.

Introduit avec l'API 31 (Android 12) est la capacité de masquer les superpositions non système. Pour utiliser l'application Axe Analyzer, assurez-vous que ce paramètre n'est pas activé. Si vous avez choisi d'utiliser cette fonctionnalité 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 ainsi éliminer 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) à setHideOverlayWindows(false) sur les fenêtres d'activité affectées.

Pour débloquer toutes les fonctionnalités d'Axe DevTools pour 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 tout problème de sécurité. Consultez notre guide pour activer les captures d'écran dans les applications Android.

Si vous compressez votre build, un crash se produira avec un journal d'erreurs indiquant qu'un adaptateur n'a pas pu être trouvé lors de la tentative de connexion à la bibliothèque Axe DevTools. Désactivez la compression pour vos builds de débogage avec Axe DevTools implémenté. (#729)

Un build avec r8 activé peut tenter de compresser la bibliothèque axeDevTools, ce qui entraîne une erreur similaire à :

Les API Compose sont obsolètes, veuillez utiliser les APIs indépendantes de la mise en page pour continuer à recevoir des mises à jour. Si vous continuez à utiliser les API Compose et rencontrez une erreur du type `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 à l'API Compose setTestTag.

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle de nommage de texte d'édition apparaîtra comme nécessitant une révision dans le tableau de bord lorsqu'une défaillance est suspectée pour la version SDK 5.5.0 et ultérieure. Veuillez confirmer le comportement correct manuellement dans ce cas.

Lorsque vous implémentez des dialogues ou modaux 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 contre ces modaux ou dialogues personnalisés et de les vérifier manuellement pour garantir qu'ils fonctionnent avec la technologie d'assistance comme souhaité.

Si la capture d'écran est manquante sur la page de détails du scan, 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 build de test afin de permettre une fonctionnalité complète dans le Tableau de bord mobile Axe DevTools.

• Android - FLAG_SECURE

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