Notes de version d'Axe DevTools Mobile du 30 juin 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 petits glyphes ressemblant à des icônes - comme les chevrons de flèches de retour (<), les puces, les symboles décoratifs - comme du 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 en icônes. 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 déclaré "INAPPLICABLE" lors du scan suivant. Ceci est une caractéristique connue de l'OCR, et non un bug 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 concerné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 native - 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.

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

Lors de l'exécution de vérifications d'accessibilité sur des tailles d'écran plus petites 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'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 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 (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 non obstrué et perceptible pour 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 é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 n'est pas résolu, les règles suivantes peuvent signaler des résultats sur les boutons de stepper désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution consiste à [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 écrans peuvent signaler des faux positifs avec LabelInName et LabelAtFront en raison d'une propriété associatedText incorrecte (#1622)

Il y a un problème affectant le simulateur iPhone 15 Pro qui empêche la règle Supports Dynamic Type de s'exécuter. Si vous avez activé la règle Supports Dynamic Type, vous ne pourrez pas la tester avec un simulateur iPhone 15 Pro. Un bug a été signalé à Apple.

En cherchant une amélioration pour nos règles, nous avons constaté que dans XCTest, les contrôles imbriqués ne sont pas retourné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 les technologies d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisation à partir d'Apple peuvent être inexactes lorsque `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 présenteront comme nécessitant une révision. Un rapport de bug a été soumis à Apple. (#1633)

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

In Scroll View
Le texte dans les éléments se comportant comme des bannières peut être signalé avec un message « Nécessite une révision ». Pour rendre ces éléments disponibles à ceux qui nécessitent un texte plus large, 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é déposé auprès d'Apple. (#1633)

Label In Name and Label At Front
Ces deux règles recherchent le label visible d'un contrôle parmi les éléments à proximité pour aider à déterminer le statut de la règle. Dans certaines hiérarchies de vues, le texte à proximité incorrect peut être détecté provoquant 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 d'introduire un problème d'accessibilité. Si vous utilisez une vue texte pour afficher des lettres au lieu de générer des images avec les lettres souhaitées en tant que vecteurs, puis que vous déclarez cette vue texte comme non importante pour l'accessibilité, nous ne pourrons pas déterminer de manière fiable si vous avez introduit une violation de l'accessibilité.

Si vous modifiez le texte focalisable pour ignorer deux caractères ou moins, vous pourriez involontairement ignorer de nombreux boutons d'un seul mot dans diverses 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 le cadre de l'image plutôt qu'en tant que vues de texte séparées. `FocusableText` ne s'exécutera alors pas 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 toutes 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 des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Puisque AccessibilityEvents sont déclenchés 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 depuis la vue, que notre outil pourra alors détecter.

Notre règle de contraste des couleurs repose sur l'apprentissage automatique pour détecter le texte, afin de garantir que le texte analysé est visible pour 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 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 en XML qui utilisent la fonctionnalité de texte d'indication peuvent voir de faux positifs avec la EditTextName règle. Le texte d'indication n'a été introduit qu'à partir d'Android 8 (SDK 26). Utiliser cet élément dans votre application XML attribuera 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 d'exécuter vos tests sur des versions plus récentes d'Android. Cependant, s'il est important que l'application soit accessible sur les versions antérieures d'Android, vous pouvez envisager d'éviter l'utilisation de la hintText fonctionnalité, car elle n'est pas officiellement prise en charge.

Vous pourriez voir des résultats pour des vues qui sont masquées derrière d'autres vues à l'écran. Ces vues masquées ne sont pas accessibles par la technologie d'assistance, mais axe DevTools Mobile les signale quand même 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 via ML Kit est requise dans de nombreuses règles 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 fait 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 devez importer la bibliothèque ML Kit dans votre projet manuellement. Dans le fichier de votre application build.gradle , ajoutez ce qui suit sous les dépendances :

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

La règle d'espacement de la cible tactile n'est actuellement pas exécutée sur les composants de curseur écrits en Jetpack Compose. Aucune action ne peut être prise pour le moment. Cependant, une solution arrive bientôt !

Sur Android API 30, l'un des emplacements où nous essayons d'enregistrer les résultats localement présente une erreur de permissions. Le résultat sera quand même 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 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 complètement sur l'écran avant d'effectuer l'analyse.

Introduit avec l'API 31 (Android 12), la capacité de masquer les superpositions non-systèmes. Pour utiliser l'application axe Analyzer, assurez-vous 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 désactiver pour les versions de test internes où vous pouvez utiliser en toute sécurité des données de test et éliminer ainsi les inquiétudes liées à la 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é affectées.

Pour débloquer la fonctionnalité complète des outils de développement axe pour Mobile, assurez-vous que les captures d'écran sont activées. Nous recommandons d'activer les captures d'écran sur une version de test ou de débogage de votre application qui utilise des données fictives pour éviter les problèmes de sécurité. Consultez notre guide pour activer les captures d'écran dans les applications Android.

Si vous réduisez votre build, vous verrez un plantage avec un journal d'erreurs indiquant qu'un adaptateur n'a pas été trouvé lors de la tentative de connexion à la bibliothèque axe DevTools. Désactivez la réduction pour vos versions de débogage avec axe DevTools implémenté. (#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)
    

Les API Compose sont obsolètes, veuillez utiliser les API 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 à l'API Compose setTestTag.

En raison des limitations de l'architecture d'application MAUI rendue dans l'écosystème Android, la règle de nom de champ de texte éditable apparaîtra comme nécessitant une révision dans le tableau de bord lorsqu'un échec est suspecté pour la version SDK 5.5.0 et plus. Veuillez confirmer le comportement correct manuellement pour ce cas.

Lorsque vous implémentez des dialogues ou modaux personnalisés qui n'étendent pas les contrôles natifs, vous pouvez obtenir des résultats pour les vues se trouvant derrière le modal. Dans ce cas, nous recommandons de ne pas exécuter notre outil sur ces modaux ou dialogues personnalisés et plutôt de les vérifier manuellement pour s'assurer qu'ils fonctionnent avec les technologies 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 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 au titre de l'écran apparaîtront comme le nom de classe complet incluant l'identifiant de bundle. Dans une future version, cela sera résolu afin 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)