Notes de version d'Axe DevTools Mobile d'août 2026

Sur iOS 26 et ultérieur, 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 Supporte le type dynamique peut être signalée comme Incomplète au lieu d'un succès ou d'un é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 maintenir vos tests en cours d'exécution, notre règle saute la vérification pour cet écran et signale incomplet pour 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 nécessaire, car votre analyse sera toujours complétée. Pour vérifier le support du type dynamique pour ces écrans, augmentez la taille du texte sur votre appareil sous **Paramètres** > **Accessibilité** > **Affichage et taille du texte** > **Texte en gras**, et confirmez que le texte sur l'écran s'adapte correctement. Ce problème a été signalé à Apple. (#2985)

La règle de Contraste des couleurs utilise le cadre 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 de type icône - tels que les chevrons de flèche arrière (<), les puces, les symboles décoratifs - comme du texte. Quand cela se produit, la règle de Contraste des couleurs s'exécute sur un élément ne contenant 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 à travers les analyses, le même élément peut apparaître dans les résultats de Contraste des couleurs dans une analyse et être signalé comme "INAPPLICABLE" dans la suivante. C'est une caractéristique connue de l'OCR, pas un bug dans la règle.

Pour contourner ce problème, vous pouvez utiliser les ignore APIs pour supprimer les résultats de Contraste des couleurs pour les éléments affectés.

Flutter ne mappe pas AppBar.title à la propriété du titre de l'écran natif - UIViewController.title, ce qui cause 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.

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

Lors des vérifications d'accessibilité sur les petites tailles d'écran ou avec de petites tailles de police, la règle du Contraste des couleurs peut signaler des faux positifs pour les arrière-plans dégradés. Dans de tels cas, elle peut être incapable de déterminer la couleur de premier plan et comparer plutôt les couleurs d'arrière-plan entre elles, ce qui résulte en un échec.

Pour contourner ce problème, essayez d'effectuer des 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 incorrectement le contenu web à l'intérieur de WKWebView comme «isVisible», même lorsque la vue web est recouverte par des superpositions natives (telles que des vues modales, des alertes ou d'autres éléments d'interface utilisateur native). 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 dégagé et perceptible par l'utilisateur.

iOS 26 contient un bug d'accessibilité où les boutons steppeurs par défaut ne signalent pas comme "estompé" par la technologie d'assistance pour indiquer qu'ils ne sont pas activés. En conséquence, les règles iOS considèrent é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 steppeurs 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 steppeurs 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 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 découvert que dans XCTest, les contrôles imbriqués ne sont pas retourné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 focalisation d'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 nommage des ImageView dans les applications UIKit seront signalés comme nécessitant un réexamen. 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 au fur et à 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 / pieds de page fixes, des boutons d'action flottants et des vues d'onglets personnalisés peut être marqué avec un message "Nécessite un réexamen" 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, le nom Active Control peuvent signaler un faux positif sur le 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 une étiquette 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 vue, le texte incorrect à proximité 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 se trouve au début de son texte annoncé. Une défaillance de la règle peut survenir lorsqu'un élément interactif contient un texte visible comprenant une abréviation (p. ex. "Go", "km") ou un identifiant obstrué / tronqué, et que l'annonce d'accessibilité se compose des mots représentés (p. ex. "gigaoctets", "kilomètres"), même si c'est le modèle recommandé pour rendre le contenu abrégé ou tronqué accessible pour 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 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 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 texte pour afficher des lettres au lieu de générer des images avec les lettres souhaitées comme 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 le texte focalisable pour ignorer deux caractères ou moins, vous risquez potentiellement d'ignorer de nombreux boutons à un mot dans différentes langues (p. ex. « OK », « Non », « Sí »). Pour éviter ces problèmes, vous devriez prendre 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 texte séparées. `FocusableText` ne s'exécutera alors pas sur ces vues.

Flutter ne mappe pas AppBar.title à la propriété native de titre d'écran - Activity.setTitle, provoquant l'échec de la règle de titre d'écran sur tous les écrans Flutter, que ce soit un titre descriptif 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 repose sur AccessibilityEvent des descriptions fournies par le système Android pour annoncer des informations à l'utilisateur lorsqu'aucune autre annonce n'est disponible. Comme les AccessibilityEventsont déclenchées par les actions de l'utilisateur, nous ne sommes pas en mesure d'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 à l'information 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 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, de sorte que la règle de contraste des couleurs ne s'exécute pas sur cette vue.

Les applications écrites avec XML qui utilisent la fonctionnalité d'indice textuel peuvent voir des faux positifs avec la règle EditTextName . Le texte d'indice n'a été introduit qu'à partir d'Android 8 (SDK 26). L'utilisation de cet élément dans votre application XML attribuera le texte d'indice à 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 résoudre ce problème, notre première recommandation est d'exécuter vos tests sur des versions plus récentes d'Android. Cependant, si l'accès à l'application sur des versions antérieures d'Android est important, vous pouvez 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 par la technologie d'assistance, mais Axe DevTools Mobile les signale tout de 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 de ML Kit est requise dans de nombreuses règles d'Axe DevTools Mobile pour assurer 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. Cependant, dans certains cas, l'importation automatique ne se produit pas et vous verrez l'erreur suivante dans le logcat :

La règle de l'espacement de la cible tactile ne s'exécute actuellement sur aucun composant de curseur qui a été écrit dans Jetpack Compose. Aucune action ne peut être entreprise pour le moment. Cependant, un correctif arrive bientôt !

Sur Android API 30, l'une des emplacements où nous essayons d'enregistrer les résultats localement a 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 :

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 écran. Pour tester un élément pour l'accessibilité, assurez-vous qu'il est entièrement à l'écran avant de procéder au scan.

Introduite avec l'API 31 (Android 12), la possibilité de masquer les superpositions non système. Pour utiliser l'application Axe Analyzer, veillez à ce que ce paramètre ne soit pas activé. Si vous avez choisi d'utiliser cette fonctionnalité pour ses améliorations de sécurité, nous vous recommandons de la laisser désactivée pour les versions de test internes où vous pouvez utiliser en toute sécurité les 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 fictives pour éviter les problèmes 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'erreur 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 de 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 à :

Les API Compose sont obsolètes, veuillez utiliser les APIs agnostiques au layout pour continuer à recevoir les 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 Compose setTestTag API.

En raison des limitations de l'architecture des applications MAUI dans l'écosystème Android, la règle du nom de l'Edit Text sera indiquée comme À Réviser dans le tableau de bord lorsqu'un échec est suspecté pour la version SDK 5.5.0 et supérieure. 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 derrière le modal. Dans ce cas, nous vous 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 se comportent comme souhaité avec la technologie d'assistance.

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 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 pleine fonctionnalité dans le tableau de bord Axe DevTools Mobile.

• Android - FLAG_SECURE

Certains noms d'analyse Android qui par défaut prennent le titre de l'écran apparaîtront comme le nom complet de la classe, y compris l'identifiant du bundle. Dans une prochaine version, cela sera résolu afin que le titre de l'écran soit formaté sous une forme plus lisible. En solution de contournement, vous pouvez définir le nom d'analyse depuis le tableau de bord ou les frameworks. (#1643)