Notes de version Axe DevTools Mobile du 8 septembre 2026

Ce statut est obsolète et sera supprimé en octobre 2026. À ce moment-là, les règles ignorées seront sautées lors de l'itération et ne renverront plus de résultat.

Notez que AxeDevTools itself n'est pas obsolète. Les méthodes suivantes seront remplacées ou supprimées intégralement dans la version d'octobre 2026.

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) (Sera remplacé par ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName))
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

Le concept de règles expérimentales sera entièrement supprimé dans la version d'octobre. Il en va de même pour les tags - ils disparaîtront avec la mise hors service du Tableau de Bord Mobile.

Ces règles étaient expérimentales et ne sont pas promues. Elles ont été retirées de notre itération de règles.

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - Cela sera remplacé par dbUrl constructeur à argument unique
• class TagsSet()
• Les règles expérimentales sont promues ou supprimées

Le SDK Axe DevTools utilise le framework Vision d'Apple pour lire le texte à l'écran pour plusieurs règles d'accessibilité (par exemple, Contraste des couleurs, Vues En Collision, toute règle dépendant du texte détecté par Vision).

Vision ne renvoie pas toujours le même texte détecté entre les exécutions du même écran. Lorsque Vision manque le texte sur un contrôle, les règles qui dépendent de ce texte ne fonctionneront pas pour cet élément lors de ce scan. Les résultats peuvent apparaître incohérents entre deux scans du même écran - un problème qui échoue sur un scan peut être absent sur le suivant.

Lorsqu'une règle basée sur Vision signale un échec, celui-ci est précis. L'incohérence réside dans le fait que la règle s'exécute ou non. Pour surmonter ce problème, essayez ce qui suit :

• Relancer l'analyse. Si une règle basée sur Vision a été ignorée pour un contrôle, un autre scan du même écran la détecte souvent.
• Considérez tout échec de règle basée sur Vision comme valable - si le Contraste des couleurs signale un problème sur un contrôle, le problème de contraste est réel et doit être résolu.
• Pour une vérification manuelle, utilisez la référence de Deque University pour le critère de succès WCAG pertinent. (Les liens se trouvent en bas de chaque page de règle.)

Sous iOS 26 et ultérieurs, si un écran contient du texte avec un signe de pourcentage (par exemple, une étiquette de texte indiquant "50% de réduction"), la règle Prend en Charge le Type Dynamique peut être signalée comme Incomplète au lieu de réussite ou d'échec. Cette règle repose sur un audit d'accessibilité fourni par Apple, et cet audit arrête l'exécution du test lorsqu'il rencontre des signes de pourcentage. Pour que vos tests se poursuivent, notre règle saute la vérification pour cet écran et signale comme incomplet chaque élément contenant un signe de pourcentage. Toutes les autres règles fonctionnent normalement sur l'écran, et les autres écrans ne sont pas affectés.

Aucune action n'est requise, puisque votre analyse se terminera toujours. Pour vérifier le support du Type Dynamique pour ces écrans, augmentez la taille du texte sur votre appareil dans **Réglages** > **Accessibilité** > **Affichage et Taille du Texte** > **Texte Grand**, et confirmez que le texte à l'écran évolue correctement. Ce problème a été signalé à Apple. (#2985)

La règle 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 occasionnellement confondre de petits glyphes semblables à des icônes - tels que les chevrons de flèche arrière (<), les puces, les symboles décoratifs - avec du texte. Lorsque cela se produit, la règle Contraste des Couleurs s'applique à un élément qui ne contient pas de texte lisible, ce qui peut produire un résultat pour un bouton uniquement avec une icône. Étant donné que les résultats de l'OCR ne sont pas déterministes 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 "NON APPLICABLE" au 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 API pour supprimer les résultats de Contraste des Couleurs pour les éléments concernés.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - UIViewController.title, ce qui fait échouer la règle Titre de l'É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 contrôles d'accessibilité sur des tailles d'écran plus petites 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 dégradés. 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 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 signaler incorrectement du contenu web à l'intérieur de WKWebView comme étant «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 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 non obstrué et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons stepper 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 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)

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 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 focalisation depuis 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 nom 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 mettrons à jour cette liste à mesure que les correctifs seront publiés.

In Scroll View
Le texte à l'intérieur des éléments se comportant comme des bannières, des en-têtes/infos collants, des boutons d'action flottants et des vues d'onglets personnalisées peut être signalé avec un message « Nécessite une révision » ou « Échec ». Pour rendre ces éléments disponibles à ceux qui nécessitent un texte plus grand, utilisez UILargeContentViewer. (#622, #2077)

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, Active Control Name peut signaler un faux positif sur l'UIImageView. Retirer 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 environnants pour aider à déterminer l'état de la règle. Dans certaines hiérarchies de vue, un texte environnant incorrect peut être détecté, causant l'échec de ces règles. (#1622)

La règle Label at Front vérifie que l'étiquette visible d'un élément apparaît 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 ex. « Go », « km ») ou un identifiant obscurci / tronqué, et que l'annonce d'accessibilité est constituée des mots représentés (par ex. « gigaoctets », « kilomètres »), même si c'est le modèle recommandé pour rendre le contenu abrégé ou tronqué compatible avec les 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 / obscurcie 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 se lit 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 texte pour afficher des lettres au lieu de générer des images avec les lettres souhaitées sous forme de vecteurs, et que vous déclarez ensuite que cette vue texte n'est pas importante pour l'accessibilité, nous ne pourrons pas savoir de manière fiable si vous avez introduit une violation d'accessibilité.

Si vous éditez du texte focalisable pour ignorer deux caractères ou moins, vous pouvez par inadvertance ignorer de nombreux boutons d'un seul mot dans différentes langues (par ex. « OK », « Non », « 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 le cadre de l'image au lieu d'en faire des vues texte séparées. `FocusableText` ne s'appliquera alors pas à ces vues.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - Activity.setTitle, ce qui fait échouer la règle Titre de l'É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 se fie à AccessibilityEvent des descriptions du système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Puisque AccessibilityEventsont 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 concernées 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 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 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 en XML qui utilisent la fonctionnalité de texte d'indication peuvent observer des 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 assignera 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, si l'accessibilité de l'application sur les anciennes versions d'Android est importante, vous pouvez 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 toujours comme des problèmes.

Nous travaillons sur une solution à 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 assurer l'accessibilité.

La détection de texte de ML Kit est requise dans de nombreuses règles d'Axe DevTools Mobile pour garantir la précision des résultats. La bibliothèque ML Kit devrait être importée automatiquement lorsque vous faites 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 :

La règle d'espacement des cibles tactiles ne fonctionne actuellement pas sur les composants de curseur qui ont été écrits en Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, une correction arrive bientôt !

Sur Android API 30, l'un des emplacements où nous essayons de sauvegarder les résultats localement rencontre une erreur de permissions. Le résultat sera tout de même enregistré sous forme de fichier JSON malgré cette erreur affichée. L'erreur peut être supprimée en commentant le code dans le bloc suivant :

Dans certaines applications hybrides et multiplateformes, nous pourrions obtenir 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 entièrement à l'écran avant d'effectuer l'analyse.

Introduite avec l'API 31 (Android 12), la capacité de cacher des superpositions non-système a été ajoutée. 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 vous 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 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é 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 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 minimisez votre build, vous verrez un crash 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 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 à :

Les APIs Compose sont obsolètes, veuillez utiliser les APIs indépendantes de la mise en page pour continuer à recevoir des mises à jour. Si vous continuez d'utiliser les APIs 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 des applications MAUI dans l'écosystème Android, la règle du nom d'édition du texte sera affichée 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 manuellement le comportement correct dans ce cas.

Lors de l'implémentation de dialogues ou de modals personnalisés qui n'étendent pas les 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 modals ou dialogues personnalisés et de les vérifier manuellement afin de s'assurer qu'ils fonctionnent avec les technologies 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 complet de la classe, y compris l'identifiant du bundle. Dans une future version, cela sera résolu afin que le titre de l'écran soit formaté dans 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)