Notes de version d'Axe DevTools Mobile du 10 décembre 2025

Lors de l'exécution de contrôles d'accessibilité sur des écrans plus petits 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 ces cas, elle peut ne pas être en mesure de déterminer la couleur du premier-plan et comparer les couleurs d'arrière-plan entre elles, résultant en un échec.

Pour contourner ce problème, essayez d'effectuer les contrôles 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 incorrectement signaler 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 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 stepper par défaut ne sont pas annoncés comme « atténués » par la technologie d'assistance pour indiquer qu'ils ne sont pas activés. En conséquence, les règles d'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 les boutons 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 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.

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

Il y a un problème affectant le simulateur iPhone 15 Pro qui empêche la règle Supporte la taille de police dynamique de s'exécuter. Si vous avez opté pour la règle Supporte la taille de police dynamique, vous ne pourrez pas la tester à l'aide d'un simulateur iPhone 15 Pro. Un rapport de bug a été déposé auprès d'Apple.

En examinant une amélioration de 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 rapport de bug a été déposé auprès d'Apple. (#1110)

Dans les applications UIKit, une image sans un accessibilityLabel n'est pas focalisable par la technologie d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisation depuis 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 nommage 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 nous 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 dans des é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 a des contrôles focalisables imbriqués à l'intérieur, ActiveControlName peut signaler un faux positif sur l'UIImageView. Supprimer le accessibilityIdentifier résout le problème. Un rapport de bug a été déposé auprès d'Apple. (#1633)

Label In Name and Label At Front
Ces deux règles recherchent une étiquette visible d'un contrôle parmi les éléments proches pour aider à déterminer le statut de la règle. Dans certaines hiérarchies de vues, le texte incorrect proche peut être détecté, ce qui provoque l'échec de ces règles. (#1622)

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 le fond, notre algorithme d'apprentissage automatique n'est pas capable 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 fonction de texte indicatif peuvent voir des faux positifs avec la règle EditTextName . Le texte indicatif n'a été introduit qu'à partir d'Android 8 (SDK 26). L'utilisation de cet élément dans votre application XML assignera 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. Si l'accessibilité de l'application sur des versions antérieures d'Android est importante, cependant, vous pourriez envisager d'éviter l'utilisation de la fonction de 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 sur 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 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 correctif pour garantir l'accessibilité.

La détection de texte ML Kit est requise dans de nombreuses règles d'Axe DevTools Mobile pour garantir 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. Cependant, dans certains cas, 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 le fichier de votre application build.gradle , ajoutez ce qui suit sous les dépendances :

La règle d'espacement des cibles tactiles ne s'exécute actuellement sur aucun composant curseur écrit en Jetpack Compose. Aucune action ne peut être prise pour le moment. Cependant, une correction est à venir bientôt !

Sur Android API 30, l'un des emplacements où nous tentons de sauvegarder localement les résultats a une erreur de permissions. Le résultat sera toujours sauvegardé en tant que fichier JSON malgré cette erreur affichée. 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 API 30 car il causera des problèmes lors de l'enregistrement local pour d'autres niveaux d'API.

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 de l'écran. Pour tester un élément pour l'accessibilité, assurez-vous qu'il est complètement à l'écran avant de procéder au scan.

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 fonction pour ses améliorations en matière de sécurité, nous recommandons de la désactiver pour les versions de test interne où vous pouvez utiliser des 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 tout appel à 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 utilisant des données simulées pour éviter les problèmes 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 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 semblable à :
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 dans votre fichier ProGuard pour conserver les classes axeDevTools :
keep class com.deque.** { *; }

Les API Compose sont obsolètes, veuillez utiliser les API indépendantes du layout pour continuer à recevoir des mises à jour. Si vous continuez à utiliser les API Compose et que vous rencontrez une erreur du genre `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` ou `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, veuillez consulter l'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 d'élément imbriqué. (#841)

En raison des limitations de l'architecture d'application MAUI dans l'écosystème Android, la règle du nom de texte modifiable apparaîtra comme à réviser dans le tableau de bord lorsqu'un échec est suspecté pour la version SDK 5.5.0 et supérieure. Veuillez confirmer le comportement correct manuellement pour ce cas.

Lorsque vous mettez en œuvre des dialogues ou modaux personnalisés qui n'étendent pas les contrôles natifs, vous pouvez obtenir des résultats pour des vues derrière le modal. Dans ce cas, nous recommandons de ne pas utiliser notre outil contre ces modaux ou dialogues personnalisés et d'effectuer plutôt un contrôle manuel pour s'assurer qu'ils se comportent avec la technologie d'assistance comme souhaité.

Si la capture d'écran manque dans la page des détails du scan, votre application peut empêcher la prise de captures d'écran. Cela est souvent le cas pour des raisons de sécurité dans votre application de production. Envisagez de supprimer cette exigence pour votre build de test pour permettre pleinement les fonctionnalités dans le tableau de bord mobile Axe DevTools.

• Android - FLAG_SECURE

Certains noms de scans Android par défaut au titre de l'écran s'afficheront comme le nom complet de la classe incluant l'identifiant du bundle. Dans une version future, cela sera résolu pour que le titre de l'écran soit formaté afin d'être plus lisible. Comme solution, vous pouvez définir le nom du scan depuis le tableau de bord ou les frameworks. (#1643)