Notes de version Axe DevTools Mobile du 20 juillet 2026

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 parfois mal identifier de petites figures iconiques - comme les chevrons de flèche arrière (<), les puces, les symboles décoratifs - comme texte. Lorsque 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 uniquement iconique. 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. Il s'agit d'une caractéristique connue de l'OCR, et non 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.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

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

Lors de l'exécution de vérifications d'accessibilité sur des écrans de taille plus réduite ou avec des tailles de police 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, il peut être incapable de déterminer la couleur de premier plan et comparer à la place les couleurs d'arrière-plan entre elles, entraînant 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 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 car 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 bogue d'accessibilité où les boutons de steppers par défaut ne signalent pas "dimmed" 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 bogue 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 de steppers désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

En attendant qu'Apple corrige ce bogue, la solution sera d'[ignorer les règles](ios-ignore-rule). Les boutons de steppers 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 Supports Dynamic Type de fonctionner. 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 bogue a été déposé auprès d'Apple.

En examinant une amélioration de nos règles, nous avons découvert que dans XCTest, les contrôles imbriqués ne sont pas retournés dans l'arbre d'accessibilité. Un bogue 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 focalisation à partir d'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 nommage d'ImageView dans les applications UIKit nécessiteront un examen. Un rapport de bug a été soumis à 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
Le texte au sein d'éléments se comportant comme des bannières peut être signalé avec un message "À revoir". 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, ActiveControlName peut signaler un faux positif sur l'UIImageView. Supprimer le `accessibilityIdentifier` résout le problème. Un bug a été soumis à Apple. (#1633)

Label In Name and Label At Front
Ces deux règles cherchent une étiquette 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 vues, le texte incorrect à proximité peut être détecté, ce qui provoque l'échec de ces règles. (#1622)

La règle Label at Front vérifie que l'étiquette visible d'un élément se trouve au début de son texte annoncé. Un échec de règle peut survenir lorsqu'un élément interactif contient un texte visible avec une abréviation (par exemple "Go", "km") ou un identifiant masqué/tronqué, et que l'annonce d'accessibilité consiste en les mots représentés (par exemple "gigabytes", "kilomètres"), même si c'est le schéma recommandé pour rendre le contenu abrégé ou tronqué accessible aux lecteurs d'écran.

Si la première partie de l'étiquette 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/masqué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.

Lors de l'utilisation de 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 au lieu de générer des images avec les lettres désiré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 déterminer de manière fiable si vous avez introduit une violation d'accessibilité.

Si vous modifiez du texte focalisable pour ignorer deux caractères ou moins, vous pourriez par inadvertance ignorer de nombreux boutons d'un seul mot dans diverses 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 vues de texte séparées. `FocusableText` ne sera alors pas exécuté sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété de titre d'écran native - Activity.setTitle, provoquant 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 AccessibilityEvent descriptions du système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Puisque AccessibilityEvents sont déclenchées par des 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 aux informations de 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 permet d'assurer 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'applique pas à cette vue.

Les applications écrites avec XML qui utilisent la fonctionnalité de texte d'indication peuvent voir des faux positifs avec la EditTextName règle. Le texte d'indication n'a été introduit qu'avec Android 8 (SDK 26). L'utilisation de cet élément dans votre application XML affectera le texte d'indication à 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 de réaliser vos tests sur des versions plus récentes d'Android. Si l'accessibilité de l'application sur d'anciennes versions d'Android est toutefois importante, vous pourriez envisager d'éviter d'utiliser 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 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 par 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 doit être importée automatiquement 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 :

Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

Pour résoudre ce problème, vous devriez importer manuellement la bibliothèque ML Kit dans votre projet. Dans le build.gradle de votre application, ajoutez ce qui suit sous dépendances :

debugImplementation 'com.google.mlkit:text-recognition:16.0.1'

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

Sur Android API 30, un des endroits où nous tentons d'enregistrer les résultats localement 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'

Dans certaines applications hybrides et multi-plateformes, nous pourrions renvoyer des résultats inattendus lorsque des éléments dans une vue de défilement sont partiellement hors écran. Pour tester l'accessibilité d'un élément, assurez-vous qu'il est complètement visible à l'écran avant de lancer l'analyse.

Introduite avec l'API 31 (Android 12), la possibilité de masquer les superpositions non-système. Pour utiliser l'application Axe Analyzer, assurez-vous que ce paramètre n'est pas activé. Si vous avez choisi de l'utiliser pour ses améliorations de sécurité, nous recommandons de le laisser désactivé pour les versions de test internes où vous pouvez utiliser en toute sécurité des données de test 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) sur les fenêtres d'activité concernées. setHideOverlayWindows(false) dans les fenêtres d'activité concerné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 qui utilise des données factices 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 signalant 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 en 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 à :

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)
	

Les APIs Compose sont obsolètes, veuillez utiliser les APIs indépendantes de la disposition pour continuer à recevoir des 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 consulter API Compose setTestTag.

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle pour le Nom de Texte Éditable apparaîtra comme Nécessite 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 des modaux personnalisés qui ne s'étendent pas aux 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 contre ces modaux ou dialogues personnalisés et de les vérifier manuellement pour s'assurer qu'ils fonctionnent avec la technologie d'assistance comme souhaité.

Si la capture d'écran est manquante sur la page des détails de l'analyse, votre application peut empêcher les captures d'écran d'être prises. Souvent, cela est dû à 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 Axe DevTools Mobile.

• Android - FLAG_SECURE

Certains noms de scan Android qui sont par défaut le titre de l'écran apparaîtront comme le nom de classe complet, y compris 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 depuis le tableau de bord ou les frameworks. (#1643)