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

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 fonds en dégradé. Dans de tels cas, elle peut être incapable de déterminer la couleur de premier plan et au lieu de cela comparer les couleurs de fond entre elles, entraînant ainsi un échec.

Pour contourner ce problème, essayez d'exécuter 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 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 les vues modales, les alertes ou d'autres éléments d'IU 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 sans obstruction et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons steppers 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 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 jusqu'à ce que cela soit résolu, les règles suivantes peuvent signaler des résultats sur des boutons steppers désactivés : AssociatedText, InaccessibleActionet ColorContrast.

Tant qu'Apple n'aura pas corrigé ce bug, la solution sera d'[ignorer les règles](ios-ignore-rule). Les boutons steppers 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 propriété associatedText incorrecte 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 Supports Dynamic Type. Si vous avez opté pour la règle Supports Dynamic Type, vous ne pourrez pas la tester en utilisant un simulateur iPhone 15 Pro. Un bug a été déposé auprès d'Apple.

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 renvoyés dans l'arborescence 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 par la technologie d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisation 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 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 à mesure que les correctifs seront publiés.

In Scroll View
Peut signaler des problèmes pour le texte à l'intérieur d'éléments se comportant comme des bannières. Pour rendre ces éléments disponibles à ceux qui ont besoin de 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, ActiveControlName peut signaler un faux positif sur l'UIImageView. Enlever 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 l'étiquette visible d'un contrôle parmi les éléments voisins pour aider à 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)

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 par 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 ne peut pas 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 fonctionnalité de texte d'indice peuvent voir des faux positifs avec la EditTextName règle. 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 sur des versions antérieures d'Android est importante, 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 disponibles pour la technologie d'assistance, mais Axe DevTools Mobile les signale quand 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 par ML Kit est requise dans bon nombre des règles d'Axe DevTools Mobile pour garantir l'exactitude des résultats. La bibliothèque ML Kit devrait être importée automatiquement 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 la bibliothèque ML Kit dans votre projet manuellement. Dans le build.gradle de votre application, 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 entreprise pour le moment. Cependant, une solution arrive bientôt !

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

Dans certaines applications hybrides et multi-plateformes, nous pouvons retourner des résultats inattendus lorsque les é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 visible à l'écran avant d'effectuer l'analyse.

Introduite avec l'API 31 (Android 12), la possibilité 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 de sécurité, nous 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) sur les fenêtres d'activité affectées. setHideOverlayWindows(false)

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 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 crash avec un journal d'erreur 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ée. (#729)

Un build avec r8 activé peut tenter de réduire la bibliothèque axeDevTools, entraînant 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 maintenir les classes axeDevTools :
keep class com.deque.** { *; }

Les API Compose sont obsolètes, veuillez utiliser les API agnostiques aux dispositions 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.

Si vous rencontrez ce message, certains résultats de règles peuvent ne pas être retournés comme prévu lorsque cette règle utilise l'intelligence artificielle. Les règles affectées comprennent le contraste des couleurs, le texte focalisable et le nom des éléments imbriqués. (#841)

En raison des limitations de l'architecture de l'application MAUI sur le système Android, la règle du nom de l'édition de texte 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 plus. Veuillez confirmer manuellement le bon comportement dans ce cas.

Lorsque vous implémentez des dialogues ou des modales personnalisés qui n'étendent pas les contrôles natifs, vous pouvez obtenir des résultats pour les vues derrière la modale. Dans ce cas, nous vous recommandons de ne pas exécuter notre outil contre ces modales ou dialogues personnalisés et de les vérifier manuellement pour vous assurer qu'ils fonctionnent avec la technologie d'assistance comme souhaité.

Si la capture d'écran est absente de la page des détails du scan, votre application peut empêcher la prise de captures d'écran. Souvent, cela est fait 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 Axe DevTools Mobile.

• Android - FLAG_SECURE

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