Notes de version Axe DevTools Mobile 4 février 2026

Lorsque vous effectuez des vérifications d'accessibilité sur des tailles d'écran plus petites ou avec des tailles de police réduites, 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 ne pas être capable 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 d'effectuer les vérifications d'accessibilité sur des appareils plus grands. Vous pouvez également choisir d'ignorer la règle dans vos tests et de vérifier manuellement le Contraste des couleurs pour ces vues.

Les APIs d'accessibilité d'Apple peuvent rapporter incorrectement le 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 de savoir si son contenu web est réellement dégagé et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons incrémenteurs par défaut n'annoncent pas "grisé" 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 tant que cela ne sera pas résolu, les règles suivantes peuvent signaler des résultats sur les boutons d'incrémentation désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution sera de [ignorer les règles](ios-ignore-rule). Les boutons par défaut de l'incrémentateur ont les identifiants « Décrementer » et « Incrémenter », 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 propriété associatedText incorrecte qui est trouvée (#1622)

Il y a un problème affectant le simulateur iPhone 15 Pro qui empêche l'exécution de la règle Supporte la taille dynamique. Si vous êtes inscrit à la règle Supporte la taille dynamique, vous ne pourrez pas la tester à l'aide d'un simulateur iPhone 15 Pro. Un bug a été signalé à Apple.

Alors que nous examinions une amélioration de nos règles, nous avons découvert que dans XCTest, les contrôles imbriqués ne sont pas renvoyés dans l'arbre d'accessibilité. Un bug a été signalé à Apple. (#1110)

Dans les applications UIKit, une image sans un accessibilityLabel n'est pas focalisable avec les technologies 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 des problèmes de nom ImageView dans les applications UIKit seront signalés comme nécessitant un examen. 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
Peut signaler des problèmes pour le texte au sein d'éléments se comportant comme des bannières. Pour rendre ces éléments accessibles à ceux qui nécessitent un texte plus grand, utilisez UILargeContentViewer. (#622)

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 contient des contrôles focalisables imbriqués, ActiveControlName peut signaler un faux positif sur le UIImageView. Retirer 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 l'étiquette visible d'un contrôle parmi les éléments à proximité pour aider à déterminer l'état de la règle. Dans certaines hiérarchies de vues, le texte incorrect à proximité peut être détecté, ce qui provoque l'échec de ces règles. (#1622)

Dans certains cas, la technologie d'assistance dépend de AccessibilityEvent descriptions du système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Puisque AccessibilityEvents are triggered by user actions, we are unable to access the correct description if this information is not provided.

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 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 analysé soit visible par les utilisateurs de votre application. Dans les cas où le texte contenu dans une vue a la même couleur que l'arrière-plan, notre algorithme d'apprentissage automatique est incapable de détecter la présence de texte, 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 règle EditTextName . Le texte indicatif n'a été introduit qu'avec Android 8 (SDK 26). Utiliser cet élément dans votre application XML assignera le texte indicatif à la valeur du champ de saisie. Les versions plus récentes d'Android sont mieux équipées pour rendre cette fonction accessible.

Pour surmonter ce problème, notre première recommandation est d'effectuer vos tests sur des versions plus récentes d'Android. Si l'accessibilité de l'application sur les versions antérieures d'Android est importante, vous pourriez envisager d'éviter l'utilisation de la fonctionnalité hintText , car elle n'est pas officiellement prise en charge.

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

Nous travaillons sur un correctif 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 bon nombre des règles Axe DevTools Mobile pour assurer l'exactitude des résultats. La bibliothèque ML Kit devrait être automatiquement importée lors de la 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 :

Pour surmonter ce problème, vous devez importer manuellement la bibliothèque ML Kit dans votre projet. Dans votre fichier build.gradle de votre application, ajoutez ce qui suit sous les dépendances :

La règle de l'espacement des cibles tactiles ne s'exécute actuellement sur aucun composant curseur écrit en Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, une solution est en cours d'élaboration !

Sur Android API 30, l'un des emplacements où nous tentons d'enregistrer localement les résultats 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 :
def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
executable "${android.getAdbExecutable().toString()}"
args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'
// finalizedBy {
// fetchAndroidFolderAxeReportsTask
// }
}

Veuillez noter que ce code ne doit être commenté que pour l'API 30, car cela causerait des problèmes lors de l'enregistrement local pour d'autres niveaux d'API.

Dans certaines applications hybrides et multiplateformes, nous pouvons obtenir 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 affiché avant de procéder à l'analyse.

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

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

Si vous réduisez votre build, vous rencontrerez 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 réduction pour vos builds de débogage avec Axe DevTools implémenté. (#729)

Un build avec r8 activé peut tenter de réduire la bibliothèque axeDevTools, ce qui entraîne une erreur similaire à :
Caused by: java.lang.NullPointerException: throw with null exception
at g.b.b.a$a.a(Unknown Source:1)
at g.b.b.a$a.a(Unknown Source:0)
at g.b.b.a.a(AccessToken.java:190)
Pour résoudre cette erreur, ajoutez la ligne suivante à votre fichier ProGuard pour conserver les classes de axeDevTools :
keep class com.deque.** { *; }

Les API Compose sont obsolètes, veuillez utiliser les APIs agnostiques de mise en page pour continuer à recevoir des mises à jour. Si vous continuez à utiliser les API Compose et que vous 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 à la API Compose setTestTag.

Si vous rencontrez ce message, certains résultats de règles peuvent ne pas être renvoyés comme prévu lorsque cette règle utilise l'intelligence artificielle. Les règles affectées incluent Contraste de couleur, Texte focalisable et Nom de l'élément imbriqué. (#841)

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle de nom du texte d'édition apparaîtra comme à réviser dans le tableau de bord lorsqu'une défaillance est suspectée 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 fenêtres modales personnalisés qui n'extendent pas les contrôles natifs, vous pouvez obtenir des résultats pour les vues derrière la fenêtre modale. Dans ce cas, nous recommandons de ne pas exécuter notre outil sur ces fenêtres modales ou dialogues personnalisés et de les vérifier manuellement pour s'assurer qu'ils fonctionnent bien avec la technologie d'assistance comme souhaité.

Si la capture d'écran est manquante sur la page de détails de l'analyse, votre application peut empêcher la prise de captures d'écran. Souvent c'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 le plein fonctionnement dans le Tableau de bord Mobile d'Axe DevTools.

• Android - FLAG_SECURE

Certains noms de scans Android par défaut, basés sur le titre de l'écran, apparaîtront sous forme de 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. Comme solution de contournement, vous pouvez définir le nom du scan à partir du tableau de bord ou des frameworks. (#1643)