Notes de mise à jour d'Axe DevTools Mobile du 23 octobre 2026

Lors du scan d'un écran avec des hiérarchies de vues larges ou complexes, la axeScan commande peut prendre plus de 60 secondes pour se terminer. 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 le scan n'est pas terminé dans ce laps de temps, WDA annule la demande et le test renvoie une erreur de délai dépassé.

Pour remplacer le délai d'attente par commande pour les commandes proxy 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 utilisez Xcode 27 et 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 commencer un scan basé sur un simulateur tant que cela n'est pas résolu.

Pour exécuter des scans via 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 framework Vision d'Apple pour lire le texte à l'écran pour plusieurs règles d'accessibilité (par exemple, Contraste des couleurs, Vues en collision, toute règle qui dépend du texte détecté par Vision).

Vision ne renvoie pas toujours le même texte détecté lors de plusieurs 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 s'exécuteront pas pour cet élément lors de ce scan. Les résultats peuvent donc sembler incohérents entre deux scans du même écran - un problème qui échoue lors d'un scan peut être absent lors du suivant.

Lorsqu'une règle basée sur Vision signale un échec, celui-ci 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 les actions suivantes :

• Relancez le scan. Si une règle basée sur Vision a été ignorée pour un contrôle, un autre scan du même écran la détectera souvent.
• Considérez tout échec de règle basée sur Vision comme valable - si le Contraste des couleurs signale un contrôle, le problème de contraste est réel et doit être résolu.
• Pour une vérification manuelle, utilisez la référence Deque University pour le critère de succès WCAG pertinent. (Les liens se trouvent en bas de chaque page de règle.)

Sur iOS 26 et plus, si un écran contient un texte avec un 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 de Réussie ou Échouée. 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 se poursuivent, notre règle ignore la vérification pour cet écran et indique 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 scan se terminera toujours. Pour vérifier le support de Dynamic Type pour ces écrans, augmentez la taille du texte sur votre appareil via **Réglages** > **Accessibilité** > **Affichage et taille du texte** > **Texte en gras** et confirmez que le texte à l'écran s'adapte correctement. Ce problème a été signalé à Apple. (#2985)

La règle du 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 parfois identifier incorrectement de petits glyphes ressemblant à des icônes - tels que les chevrons de flèche arrière (<), 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 uniquement icône. Comme la sortie OCR n'est pas déterministe au travers des scans, 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. Il s'agit d'une caractéristique connue de l'OCR, pas d'un bogue dans 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 affectés.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - UIViewController.title, causant l'échec de la règle du Titre de l'é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.

Lors de l'exécution de vérifications d'accessibilité sur des écrans de petite taille ou avec des tailles de police réduites, la règle de Contraste des couleurs peut signaler de faux positifs pour les arrière-plans en dégradé. Dans de tels cas, il peut être incapable de déterminer la couleur de premier plan et comparer les couleurs d'arrière-plan entre elles, entraînant un échec.

Pour contourner ce problème, essayez de lancer 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 le Contraste des couleurs manuellement pour ces vues.

Les API d'accessibilité d'Apple peuvent signaler incorrectement du contenu web à l'intérieur de WKWebView comme "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 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 si son contenu web est réellement dégagé et perceptible pour l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons du 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 voient é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 du stepper désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution sera d'[ignorer les règles](ios-ignore-rule). Les boutons du stepper 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 de faux positifs avec LabelInName et LabelAtFront en raison d'une associatedText propriété incorrecte trouvée (#1622)

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

Dans les applications UIKit, une image sans `accessibilityLabel` n'est pas focalisable par défaut avec la technologie d'assistance.
Les propriétés que nous utilisons pour vérifier la focalisabilité chez 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 seront signalés 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 suivants et mettrons à jour cette liste au fur et à mesure que les 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 page fixes, les boutons d'action flottants et les vues d'onglets personnalisés peuvent être signalés avec un message "Nécessite une révision" ou "Échec". Pour rendre ces éléments accessibles à ceux qui ont besoin d'un texte plus grand, utilisez UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si un UIImageView a un accessibilityIdentifier défini mais n'est pas focalisable par VoiceOver, et qu'il a des contrôles focalisables imbriqués, Active Control Name peut signaler un faux positif sur l'UIImageView. Supprimer 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 cherchent le label 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é, entraînant l'échec de ces règles. (#1622)

Le Floating Action Button (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 superposés.

Notez que c'est purement un bug de Talkback, qui n'autorisait pas les FABs rendus dans les superpositions d'accessibilité à gagner ou perdre le focus par balayage. La récente mise à jour de notre application Analyzer d'accessibilité permet de scanner plus de types d'applications ; vous pouvez donc constater ce problème maintenant.

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

La règle Label at Front vérifie que le label visible d'un élément vient 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 "Go", "km") ou un identifiant occulté / tronqué, et que l'annonce d'accessibilité se compose des mots représentés (par exemple "gigaoctets", "kilomètres"), même si c'est le modèle recommandé pour rendre le contenu abrégé ou tronqué accessible aux lecteurs d'écran.

Si la première partie du label visible d'un élément interactif correspond au début de l'annonce du lecteur d'écran et que seule la portion abrégée / occulté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.

En utilisant du texte décoratif dans les vues telles que « Icônes de contact », il est possible d'introduire un problème d'accessibilité. Si vous utilisez une vue textuelle pour afficher des lettres au lieu de générer des images avec les lettres souhaitées comme vecteurs, et que vous déclarez ensuite cette vue textuelle 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 éditez le texte focalisable pour ignorer deux caractères ou moins, vous risquez par inadvertance d'ignorer de nombreux boutons d'un seul 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 dans l'image, au lieu de les utiliser comme vues textuelles séparées. `FocusableText` ne s'exécutera alors pas sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - Activity.setTitle, causant l'échec de la règle du Titre de l'é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 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és 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 à l'information depuis 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 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 le fond, 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 en XML qui utilisent la fonctionnalité de texte d'indice peuvent rencontrer des faux positifs avec la règle EditTextName . Le texte d'indice n'a été introduit qu'avec Android 8 (SDK 26). Utiliser cet élément dans votre application XML attribuera le texte d'indice à 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 est importante sur les versions Android antérieures, vous pourriez envisager d'éviter l'utilisation de la fonction hintText , car elle n'est pas officiellement prise en charge.

Vous pouvez voir les résultats pour les 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 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 devrait être importée automatiquement lorsque vous référencez 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 Espacement des cibles tactiles ne fonctionne actuellement sur aucun composant de curseur écrit en Jetpack Compose. Aucune action ne peut être prise pour le moment. Cependant, une solution arrive bientôt !

Sur Android API 30, un des emplacements où nous essayons de sauvegarder les résultats localement présente une erreur de permissions. Le résultat sera toujours sauvegardé 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 retourner des résultats inattendus lorsque des éléments dans une vue de défilement sont partiellement hors écran. Pour tester un élément en matière d'accessibilité, assurez-vous qu'il est complètement à l'écran avant d'effectuer le scan.

La capacité de masquer les superpositions non système a été introduite avec l'API 31 (Android 12). Afin d'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 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 les préoccupations de sécurité de cette manière. 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é concernées.

Pour débloquer la fonctionnalité complète 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 debug 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 minifiez votre build, vous verrez un crash 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 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, ce qui entraîne une erreur similaire à :

Les APIs Compose sont obsolètes, veuillez utiliser les APIs agnostiques au layout pour continuer à recevoir les mises à jour. Si vous continuez à utiliser les APIs 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 à Compose setTestTag API.

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 nécessitant une révision dans le tableau de bord lorsqu'un échec est suspecté pour la version SDK 5.5.0 et plus. Veuillez confirmer manuellement le comportement correct 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 situées 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 afin de s'assurer qu'ils fonctionnent avec les technologies d'assistance comme désiré.

Si la capture d'écran est manquante dans la page des détails de l'analyse, votre application peut empêcher la capture 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 d'analyses 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 future version, ceci 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 à partir du tableau de bord ou des frameworks. (#1643)