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

Lors de l'analyse d'un écran avec des hiérarchies de vues grandes ou complexes, la commande axeScan peut prendre plus de 60 secondes pour s'achever. Le proxy WebDriverAgent (WDA) d'Appium applique un délai d'attente par défaut de 60 secondes aux commandes inconnues, et axeScan entre dans cette catégorie. Si l'analyse n'est pas terminée dans ce délai, WDA annule la requête et le test génère une erreur de délai d'attente

Pour remplacer le délai d'attente par commande pour les commandes proxifiées par WDA comme 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 utilisez une application Mobile Analyzer Desktop antérieure à la 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 une analyse basée sur un simulateur tant que cela n'est pas résolu.

Pour exécuter des analyses en utilisant un simulateur sur Xcode 27, mettez à jour 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 se chevauchant, 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 manque le texte sur un contrôle, les règles qui dépendent de ce texte ne fonctionneront pas pour cet élément lors de cette analyse. Les résultats peuvent apparaître incohérents entre deux analyses du même écran - un problème qui échoue à une analyse peut être absent à la suivante.

Lorsqu'une règle basée sur Vision signale un échec, l'échec lui-même 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 :

• Réeffectuez 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étectera souvent.
• Considérez tout échec de 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 devrait être abordé.
• Pour une vérification manuelle, utilisez la référence Université Deque pour le critère de succès 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 apparaître 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 interrompt l'exécution du test lorsqu'il rencontre des signes de pourcentage. Pour continuer vos tests, notre règle saute la vérification pour 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, car votre analyse se terminera tout de même. Pour vérifier le support Dynamic Type pour ces écrans, augmentez la taille du texte sur votre appareil sous **Réglages** > **Accessibilité** > **Affichage & Taille du texte** > **Texte agrandi**, 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 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 confondre de petits glyphes à l'apparence d'icônes - tels que des chevrons de flèche arrière (<), des puces, des symboles décoratifs - avec du texte. Quand 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 composé uniquement d'une icône. Comme la sortie de l'OCR n'est pas déterministe d'un scan à l'autre, le même élément peut apparaître dans les résultats de Contraste des couleurs lors d'un scan et être signalé comme "INAPPLICABLE" lors du suivant. Ceci est une caractéristique connue de l'OCR, non 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é native du titre d'écran - UIViewController.title, ce qui entraîne l'échec de la règle de Titre d'écran sur tous les écrans Flutter, qu'un titre descriptif soit présent ou non.

Il s'agit d'une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Lorsque vous effectuez des vérifications d'accessibilité sur des écrans de petite taille ou avec des polices plus petites, la règle de Contraste des couleurs peut signaler des faux positifs pour les arrière-plans en dégradé. Dans de tels cas, elle peut être incapable de déterminer la couleur de premier plan et comparer à la place les couleurs d'arrière-plan l'une par rapport à l'autre, ce qui entraîne un échec.

Pour contourner ce problème, essayez d'effectuer 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 API d'accessibilité d'Apple peuvent signaler incorrectement le contenu web à l'intérieur de WKWebView comme "isVisible", même lorsque la vue web est couverte par des superpositions natives (comme des vues modales, des alertes ou d'autres éléments UI natifs). 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 vérifier si son contenu web est réellement non obstrué et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons de stepper par défaut ne signalent 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 cela soit résolu, les règles suivantes peuvent signaler des résultats sur des boutons de stepper désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution consiste à [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 des faux positifs avec LabelInName et LabelAtFront en raison d'une associatedText propriété incorrecte trouvée (#1622)

En cherchant à améliorer nos règles, nous avons constaté que dans XCTest, les contrôles imbriqués ne sont pas renvoyés dans l'arbre 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 l'aptitude à être focalisé par 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 revue. Un rapport de bug a été déposé auprès d'Apple. (#1633)

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

In Scroll View
Le texte au sein des éléments se comportant comme des bannières, des en-têtes/pieds de page collants, des boutons d'action flottants et des vues de tabulations personnalisées peut être signalé avec un message "Nécessite une revue" ou "Échec". Pour rendre ces éléments accessibles à ceux qui nécessitent 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 contient des contrôles focalisables imbriqués, le Nom du contrôle actif peut signaler un faux positif sur l'UIImageView. Supprimer le accessibilityIdentifier résout le problème. Un bug a été déposé auprès d'Apple. (#1633)

Label In Name and Label At Front
Ces deux règles recherchent le label visible d'un contrôle parmi les éléments à proximité pour aider à déterminer le statut de la règle. Dans certaines hiérarchies de vue, le mauvais texte à proximité peut être détecté, ce qui entraîne l'échec de ces règles. (#1622)

La règle de Label at Front vérifie que le libellé visible d'un élément apparaît au début de son texte annoncé. Une défaillance de la règle peut se produire quand le texte visible d'un élément interactif contient une abréviation (par exemple "GB", "km") ou un identifiant obstrué / tronqué, et que l'annonce d'accessibilité se compose des mots représentés (par exemple "gigabytes", "kilomètres"), même si cela est la méthode recommandée 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 est lue comme prévu.

Lorsque vous utilisez du texte décoratif dans des vues telles que "Icônes de contact", il est possible d'introduire un problème d'accessibilité. Si vous utilisez une vue de texte pour afficher des lettres plutôt que de générer des images avec les lettres souhaitées sous forme de vecteurs, et que vous déclarez ensuite que cette vue de texte n'est pas importante pour l'accessibilité, nous ne pourrons pas dire 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 pourriez par inadvertance ignorer de nombreux boutons d'un seul mot dans différentes langues (par exemple "OK", "No", "Sí"). Pour éviter ces problèmes, vous devez extraire les lettres souhaitées du mot que vous souhaitez représenter dans l'icône et générer les lettres comme une partie de l'image plutôt que comme des 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 d'écran - Activity.setTitle, ce qui entraîne l'échec de la règle de Titre d'écran sur tous les écrans Flutter, qu'un titre descriptif soit présent ou non.

Il s'agit d'une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Dans certains cas, la technologie d'assistance s'appuie sur les AccessibilityEvent descriptions fournies par le système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Puisque 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 soient marquées comme importantes pour l'accessibilité. Cela permettra à Talkback d'accéder aux informations à partir de la vue, que notre outil pourra ensuite 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 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 du 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 fonction de texte d'indices peuvent rencontrer des faux positifs avec la règle EditTextName . Le texte d'indices n'a été introduit qu'à partir d'Android 8 (SDK 26). Utiliser cet élément dans votre application XML attribuera le texte d'indices à 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. Si l'accessibilité de l'application sur les versions Android antérieures est importante, vous pourriez envisager d'éviter l'utilisation de la fonction hintText , 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 disponibles pour la technologie d'assistance, mais Axe DevTools Mobile les signale tout de même 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 garantir l'accessibilité.

La détection de texte ML Kit est requise dans de nombreuses règles d'Axe DevTools Mobile pour assurer la précision des résultats. La bibliothèque ML Kit devrait être automatiquement importée lorsque vous faites référence à 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 des cibles tactiles ne s'applique actuellement pas aux composants de curseur écrits avec Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, une correction est à venir bientôt !

Sur Android API 30, l'un des emplacements où nous essayons d'enregistrer les résultats localement présente une erreur de permissions. Le résultat sera tout de même enregistré sous la forme d'un 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 pourrions obtenir des résultats inattendus lorsque des éléments d'une vue de défilement sont partiellement hors écran. Pour tester un élément pour l'accessibilité, assurez-vous qu'il soit entièrement à l'écran avant d'effectuer l'analyse.

Introduite avec l'API 31 (Android 12), la capacité de masquer les superpositions non système. Pour utiliser l'application Axe Analyzer, veuillez vous assurer que ce paramètre n'est pas activé. Si vous avez choisi d'utiliser cette fonctionnalité pour ses améliorations en matière de sécurité, nous recommandons de la désactiver pour les versions de test internes où vous pouvez utiliser les données de test en toute sécurité 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) vers setHideOverlayWindows(false) sur les fenêtres d'activités affectées.

Pour débloquer toute la fonctionnalité 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 fictives pour éviter les préoccupations de sécurité. Consultez notre guide pour activer les captures d'écran dans les applications Android.

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

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

Les API Compose sont obsolètes, veuillez utiliser les API indépendantes du layout pour continuer à recevoir des mises à jour. Si vous continuez d'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 Nom de texte d'édition apparaîtra comme Nécessite une révision sur le tableau de bord lorsqu'une défaillance est suspectée pour la version SDK 5.5.0 et supérieure. Veuillez confirmer le bon comportement manuellement pour ce cas.

Lorsque vous implémentez des boîtes de dialogue 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 sur ces modaux ou boîtes de dialogue personnalisés et de les vérifier manuellement pour assurer qu'ils se comportent avec la technologie d'assistance comme souhaité.

Si la capture d'écran est absente de la page de détails de l'analyse, il se peut que votre application empêche les captures d'écran d'être prises. 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 Mobile Axe DevTools.

• Android - FLAG_SECURE

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