Notes de version Axe DevTools Mobile 5 août 2026

Sur iOS 26 et versions ultérieures, 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 d'un succès ou d'un échec. Cette règle dépend d'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 continuent, 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 s'exécutent normalement sur l'écran, et les autres écrans ne sont pas affectés.

Aucune action n'est requise, car votre scan sera toujours complet. Pour vérifier la prise en charge du type dynamique pour ces écrans, augmentez la taille du texte sur votre appareil sous **Réglages** > **Accessibilité** > **Affichage et taille du texte** > **Texte large**, et confirmez que le texte à l'écran s'adapte correctement. Ce problème a été signalé à Apple. (#2985)

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 se tromper et identifier des glyphes ressemblant à des icônes - tels que des chevrons de flèche arrière (<), des puces, des 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 contenant uniquement une icône. Étant donné que la sortie 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 "NON APPLICABLE" lors du suivant. C'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.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - UIViewController.title, ce qui fait échouer la règle de Titre d'Écran sur tous les écrans Flutter, que ce soit en présence d'un titre descriptif 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 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 fonds en dégradé. Dans de tels cas, elle peut être incapable de déterminer la couleur du premier plan et comparer à la place les couleurs de fond les unes aux autres, 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 incorrectement rapporter le 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 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 vérifier si son contenu web est réellement non obstrué et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons par défaut des pas à pas ne signalent pas "estompé" 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 de pas à pas désactivés : AssociatedText, InaccessibleAction, et ColorContrast.

Jusqu'à ce qu'Apple corrige ce bug, la solution consistera à [ignorer les règles](ios-ignore-rule). Les boutons de pas à pas 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)

En examinant une amélioration pour nos règles, nous avons trouvé que dans XCTest, les contrôles imbriqués ne sont pas renvoyés dans l'arbre 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 avec la technologie d'assistance par défaut.
Les propriétés que nous utilisons pour vérifier la focalisabilité 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 Nom ImageView dans les applications UIKit seront signalés comme Besoin de Révision. Un rapport de bug a été déposé auprès d'Apple. (#1633)

Nous travaillons activement à des corrections pour les faux positifs suivants et mettrons à jour cette liste au fur et à mesure que les corrections seront publiées.

In Scroll View
Le texte dans des éléments se comportant comme des bannières, des en-têtes/pieds de page flottants, des boutons d'action flottants et des vues d'onglets personnalisés peut être marqué avec un message "Besoin de Révision" ou "Échec". Pour rendre ces éléments accessibles à ceux qui ont besoin de textes plus grands, 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 en son sein, Active Control Name 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 proches pour aider à déterminer le statut 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)

La règle Label à l'Avant vérifie que le label visible d'un élément se trouve au début de son texte annoncé. Un échec de la règle peut se produire lorsqu'un élément interactif comporte un texte visible contenant une abréviation (par exemple "GB", "km") ou un identifiant obstrué / tronqué, et que l'annonce d'accessibilité est constituée des mots représentés (par exemple "gigaoctets", "kilomètres"), bien que ce soit le modèle recommandé pour rendre le contenu abrégé ou tronqué accessible aux lecteurs d'écran.

Si la première partie du label visible d'un élément interactif correspond au début de l'annonce du lecteur d'écran et que seule la portion abrégée / obstrué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 se lit comme prévu.

Lorsque vous utilisez un 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, et que vous déclarez ensuite que cette vue 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 pouvez par inadvertance ignorer de nombreux boutons constitués d'un seul mot dans différentes langues (par exemple « 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 comme partie de l'image au lieu de 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 du 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 s'appuie sur AccessibilityEvent des descriptions du système Android pour annoncer des informations à l'utilisateur lorsque aucune autre annonce n'est disponible. Puisque AccessibilityEvents sont déclenchées par des actions 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 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 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 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 de suggestion peuvent voir des faux positifs avec la règle EditTextName . Le texte de suggestion n'a été introduit qu'à partir d'Android 8 (SDK 26). Utiliser cet élément dans votre application XML assignera le texte de suggestion à 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 il est important que l'application soit accessible sur les versions antérieures d'Android, vous pourriez envisager d'éviter l'utilisation de la fonctionnalité hintText , 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 sur l'écran. Ces vues cachées ne sont pas accessibles à la technologie d'assistance, mais Axe DevTools Mobile les signale malgré tout comme 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 garantir l'accessibilité.

La détection de texte ML Kit est requise dans plusieurs règles de 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 :

La règle d'espacement des cibles tactiles ne fonctionne actuellement pas sur les composants curseurs qui ont été écrits dans Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, un correctif 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 sauvegardé en tant que 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 pouvons renvoyer 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 à l'écran avant de réaliser l'analyse.

Introduit avec l'API 31 (Android 12), la possibilité 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 interne 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é concernées. setHideOverlayWindows(false)

Pour déverrouiller 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 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 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 réduction pour vos builds de débogage avec Axe DevTools implémenté. (#729)

Un build avec r8 activé peut tenter de réduire la bibliothèque axeDevTools, ce qui entraîne une erreur similaire à :

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 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 l'API Compose setTestTag.

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle Nom du texte modifiable apparaîtra comme Nécessitant un examen dans le tableau de bord lorsqu'une anomalie est suspectée pour la version SDK 5.5.0 et supérieure. Veuillez confirmer le comportement correct manuellement dans 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 situées derrière le modal. Dans ce cas, nous recommandons de ne pas utiliser notre outil sur ces modaux ou dialogues personnalisés et de les vérifier manuellement pour assurer qu'ils fonctionnent comme souhaité avec les technologies d'assistance.

Si la capture d'écran est absente de la page de détails de l'analyse, votre application pourrait empêcher la prise de captures d'écran. Souvent, cela est dû à des raisons de sécurité dans votre application en 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 d'analyse Android, qui sont fixés par défaut au 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. Comme solution de contournement, vous pouvez définir le nom de l'analyse depuis le tableau de bord ou les frameworks. (#1643)