Notes de version de Axe DevTools Mobile du 17 juin 2026

La règle de Contraste de couleur 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 à tort de petites glyphes ressemblant à des icônes - comme les chevrons fléchés (<), les puces, les symboles décoratifs - comme du texte. Dans ce cas, la règle de Contraste de couleur s'exécute sur un élément qui ne contient aucun texte lisible, ce qui peut produire un résultat pour un bouton uniquement icône. 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 de couleur lors d'un scan et être signalé comme "INAPPLICABLE" lors du suivant. C'est une caractéristique connue de l'OCR, pas un bug de la règle.

Pour contourner ce problème, vous pouvez utiliser les ignore APIs pour supprimer les résultats de Contraste de couleur 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é de titre d'écran natif - UIViewController.title, ce qui entraîne l'échec de la règle de titre d'écran sur tous les écrans Flutter, qu'un titre descriptif soit présent ou non.

C'est une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Lorsque vous effectuez des vérifications d'accessibilité sur des tailles d'écran plus petites ou avec des petites tailles de police, la règle Contraste de Couleur peut signaler des faux positifs pour les arrière-plans en dégradé. Dans de tels cas, elle 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 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 de Couleur pour ces vues.

Les APIs d'accessibilité d'Apple peuvent rapporter de manière incorrecte 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 UI 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 libre et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons de 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 aussi 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 ce problème n'est pas résolu, les règles suivantes peuvent rapporter des résultats sur les boutons de stepper 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 de l'incrémentateur par défaut ont les identifiants « Décrémenter » 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 pages peuvent signaler des faux positifs avec LabelInName et LabelAtFront en raison d'une propriété associatedText incorrecte détectée (#1622)

Un problème affecte le simulateur iPhone 15 Pro qui empêche l'exécution de la règle Supports Dynamic Type. Si vous êtes inscrit à la règle Supports Dynamic Type, vous ne pourrez pas la tester en utilisant un simulateur iPhone 15 Pro. Un bug a été signalé à 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 renvoyés dans l'arbre d'accessibilité. Un bug a été signalé à Apple. (#1110)

Dans les applications UIKit, une image sans `accessibilityLabel` n'est pas focalisable avec la technologie d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisabilité 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 nom de l'ImageView dans les applications UIKit seront signalés comme nécessitant une révision. Un rapport de bug a été signalé à Apple. (#1633)

Nous travaillons activement sur des correctifs pour les faux positifs suivants et mettrons à jour cette liste à mesure que les correctifs seront publiés.

In Scroll View
Le texte dans les éléments agissant comme des bannières peut être signalé avec un message « Nécessite une révision ». Pour rendre ces éléments disponibles aux personnes 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 l'UIImageView. Supprimer l'`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 proches pour aider à déterminer le statut de la règle. Dans certaines hiérarchies de vues, le texte proche incorrect peut être détecté, causant l'échec de ces règles. (#1622)

Lors de l'utilisation de texte décoratif dans des vues telles que « Icônes de contact », il est possible de créer 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 le texte focalisable pour ignorer deux caractères ou moins, vous risquez d'ignorer par inadvertance de nombreux boutons d'un seul mot dans différentes langues (par exemple, « OK », « Non », « Sí »). Pour éviter ces problèmes, vous devez 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 rendre sous forme de vues de texte distinctes. `FocusableText` ne s'exécutera alors pas sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété de titre d'écran natif - Activity.setTitle, ce qui entraîne l'échec de la règle de titre d'écran sur tous les écrans Flutter, qu'un titre descriptif soit présent ou non.

C'est une limitation connue de la plateforme Flutter suivie dans flutter/flutter#185894.

Dans certains cas, la technologie d'assistance repose sur AccessibilityEvent des descriptions du système Android pour annoncer l'information à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Étant donné que AccessibilityEvents sont déclenchées 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 aux informations à partir de la vue, que notre outil peut 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 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'exécute pas sur 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 pas été introduit avant Android 8 (SDK 26). L'utilisation de cet élément dans votre application XML assignera le texte d'indication à la valeur du champ 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 les versions antérieures d'Android est importante, cependant, vous pourriez envisager d'éviter l'utilisation de la hintText fonctionnalité, car elle n'est pas officiellement supportée.

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 accessibles à 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 accéder à 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 pour de nombreuses règles de axe DevTools Mobile afin d'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. Cependant, dans certains cas, 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 surmonter ce problème, vous devez importer manuellement la bibliothèque ML Kit dans votre projet. Dans le build.gradle de votre application, ajoutez ce qui suit sous dependencies :

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

La règle d'espacement des cibles tactiles ne s'applique actuellement à aucun composant curseur écrit en Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, un correctif arrive bientôt !

Sous Android API 30, l'un des emplacements où nous tentons de sauvegarder les résultats localement a un problème de droits d'accès. Le résultat sera tout de même enregistré sous forme de fichier JSON malgré l'affichage de cette erreur. L'erreur peut être supprimée en mettant en commentaire 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 multiplateformes, nous pouvons obtenir des résultats inattendus lorsque des éléments d'une vue défilante sont partiellement hors écran. Pour tester l'accessibilité d'un élément, assurez-vous qu'il est entièrement à l'écran avant d'effectuer le scan.

Introduite avec l'API 31 (Android 12), la possibilité de masquer les superpositions non-systèmes est disponible. 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 en matière de sécurité, nous vous recommandons de la désactiver pour les versions de test internes où vous pouvez utiliser les 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 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 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 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)

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

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle du nom de l'édition de texte sera affichée comme nécessitant un examen dans le tableau de bord lorsqu'un échec est suspecté pour les versions de SDK 5.5.0 et supérieures. Veuillez confirmer le comportement correct manuellement dans ce cas.

Lorsque vous implémentez des dialogues ou modales personnalisés qui n'étendent pas les contrôles natifs, vous pouvez obtenir des résultats pour les vues situées 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 correctement avec la technologie d'assistance.

Si la capture d'écran est manquante sur la page de 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 la fonctionnalité complète du 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 afin que le titre de l'écran soit formaté en un nom plus lisible. En attendant, vous pouvez définir le nom du scan depuis le tableau de bord ou les frameworks. (#1643)