Notes de version Axe DevTools Mobile du 11 novembre 2026

Versions des composants

iOS

• SDK iOS (axeDevToolsXCUI v5.0.0)

Comment mettre à jour : SDK iOS, Application de bureau iOS Analyzer

Android

• SDK Android (axe-devtools-android v10.0.0)
• Plugin Gradle Android (axe-devtools-android-plugin v2.0.0)
• Analyseur Android (Axe Accessibility Analyzer v4.2.0)

Comment mettre à jour : Plugin Gradle Android, Analyseur Android

Quoi de neuf ?

SDK

À l'approche de la mise hors service du tableau de bord mobile, la configuration des règles globales est désormais définie dans Axe Account. Les administrateurs y configurent les paramètres des règles à exécuter lors des tests automatisés, et ils peuvent également accorder des autorisations aux utilisateurs pour qu'ils modifient les paramètres globaux et ignorent les règles individuelles dans leurs tests. Lorsque les substitutions ne sont pas autorisées, l'appel d'ignorance ne fait rien et le SDK enregistre la raison. Notez que si les paramètres d'organisation ne peuvent pas être lus, les analyses seront tout de même effectuées. Chaque règle est exécutée et les ignorances au niveau du code sont autorisées. Seule une organisation qui désactive explicitement les substitutions les bloque.

iOS

• Trouvez un lien vers vos résultats après le téléchargement. Après le téléchargement d'une analyse, le journal affiche maintenant View your results in Axe Developer Hub: <link>. Les analyses ciblées dirigent vers la page du projet, et Auto Scan vers sa session.
• Les règles sont maintenant ignorées sur AxeDevTools lui-même, par exemple axe.ignoreRules(.colorContrast, .screenTitle), ou par élément avec ignoreRules(onElementWithId:) / ignoreRules(onElementOfClass:). Une règle mal orthographiée échoue maintenant à la construction au lieu de s'exécuter silencieusement. (Changement radical — voir ci-dessous.)

Android

• Trouvez un lien vers vos résultats après le téléchargement. Après le téléchargement d'une analyse, le journal imprime un lien vers Axe Developer Hub. Les analyses ciblées dirigent vers la page du projet, et AutoScan vers sa session.
• Vous ignorez maintenant les règles avec l'énumération AxeRuleName, par exemple axeDevTools.ignoreRules(AxeRuleName.COLOR_CONTRAST, AxeRuleName.SCREEN_TITLE). Pour ignorer des règles sur un élément, utilisez ignoreRulesOnElementWithId("resource_id", AxeRuleName.TOUCH_TARGET_SIZE). Un nom de règle mal orthographié échoue maintenant à la construction au lieu d'être ignoré silencieusement. (Changement radical, voir ci-dessous.)
• Définissez les ignorances de règles une fois par session lors de tests ciblés. Passez ignoreRules et ignoreRulesOnElementIds à la fonction mobile: axeStartSession ; ceux-ci s'appliquent à chaque analyse ciblée jusqu'à la fin de la session. (Remarque : Auto Scan ne permet pas d'ignorer individuellement les règles ; il suit uniquement les paramètres de règle de l'organisation.)

Corrections

iOS

• Améliorations de la précision des règles suivantes : Étiquette dans le nom, Étiquette en premier, Taille de la cible tactile, Espacement de la cible tactile
• Les analyses ne plantent plus lorsque le testeur est construit avec Xcode 16.2 ou d'autres versions antérieures à 16.4
• Journaux de test plus silencieux - le SDK n'imprime plus dans le journal de test à chaque envoi d'analyses

Android

• Précision améliorée de la règle Étiquette dans le nom
• Amélioration des performances pour Auto Scan - le testeur attend maintenant jusqu'à 10 secondes pour un réseau avant de se connecter
• Amélioration des performances du bouton de balayage flottant de l'Axe Accessibility Analyzer lors de l'utilisation de TalkBack - vous pouvez désormais l'atteindre en balayant, et il garde le focus après une analyse ou après l'ouverture d'un menu (le focus de balayage nécessite la version 16.2 ou ultérieure de TalkBack)

Mises à jour

Android

• Le SDK, l'Analyseur et les cibles d'exemples se construisent maintenant avec Android SDK 37 (compileSdk / targetSdk 37). Le minSdk reste à 26. Votre application n'a besoin d'aucun changement.
• Les tests Java peuvent maintenant appeler AxeAutoScan.skipScan(...) directement, sans .Companion
• resetIgnoredRules() n'est plus obsolète et vous pouvez continuer à l'utiliser

Dépréciations et suppressions

iOS

• La règle Action inaccessible a été supprimée. Les analyses ne l'exécutent jamais, et AxeRuleId.InaccessibleAction ne compile plus. Supprimez toutes les références à cette règle de votre code de test - Tout code ajouté pour désactiver ou ignorer la règle peut être supprimé.
• Les API de règles expérimentales ont été supprimées. La clé experimental a également disparu du JSON exporté.
• La clé optInToSupportsDynamicType a été supprimée. Si vous l'avez encore dans votre code, supprimez la ligne qui la définit.
• Les API de tableau de bord mobile suivantes ont maintenant été supprimées. Celles-ci étaient dépréciées dans une version antérieure. Le chemin vers le Axe Developer Hub est le seul qui reste :
  • getResult, tagResult, deleteResult, updateScanName, AxeDevToolsResultKey, AxeResult.tags — supprimés, sans remplacement.
  • login(withAPIKey:toServer:) et startSession(apiKey:url:projectId:) — utilisez startScanSession(...) ou authenticate(...) à la place.
  • postResult(_:withTags:withScanName:) — utilisez postResult(_:withScanName:), qui maintenant ne retourne rien.
  • axeServiceUrl / axeServerUrl (pour Auto Scan) — utilisez axeAccountUrl.
  • AxeStatus.IGNORED - supprimé. Les règles ignorées ne produisent plus de résultat du tout, donc "status":"IGNORED" n'apparaît jamais dans le JSON exporté.

Android

• Les règles expérimentales ont été supprimées :
  • NestedElementName et NestedActiveControl n'existent plus.
  • ignoreExperimental() et le drapeau experimental sur AxeRule ont disparu.
• AxeRuleViewHierarchy a été déprécié en mars 2025 et a maintenant été supprimé. Les règles personnalisées doivent étendre AxeRule et remplacer isApplicable / runRule en utilisant AxeView.
• Les API du tableau de bord mobile ont été supprimées. Axe Developer Hub est désormais le seul chemin de téléchargement :
  • loginWithApiKey(...) et startSession(apiKey, projectId, serverUrl) — utilisez startScanSession(apiKey, projectId, axeAccountUrl).
  • tagScanAs, getResult, deleteResult, AxeDevToolsResultKey, TagsSet — supprimé, pas de remplacement.
• ScanResultHandler.uploadToDashboard(uploadOnly) — utilisez uploadToDashboard() sans arguments. Remarque : Cela envoie les résultats à Axe Developer Hub.
• Plugin Gradle axeServerUrl — utilisez axeAccountUrl.
• AxeStatus.IGNORED - supprimé. Les règles ignorées ne produisent plus de résultat, donc "status":"IGNORED" n'apparaît jamais dans le JSON exporté.

Changements majeurs

iOS

• La version minimale requise d'iOS est maintenant 17. Les cibles de test UI qui ciblent encore iOS 16 doivent augmenter leur cible de déploiement. Exécuter sur des appareils iOS 16 n'est plus supporté.
• L'ignorance des règles a été retirée de axe.configuration, et axe.configuration est supprimé. Les anciens appels échouent à la compilation avec un message nommant le nouvel appel :
  • axe.configuration.ignore(rules:) - utilisez axe.ignoreRules(...)
  • axe.configuration.ignore(rulesFor:) - utilisez axe.ignoreRules(onElementWithId:_:) ou ignoreRules(onElementOfClass:_:)
  • axe.configuration.customRules.insert(rule) - utilisez axe.addCustomRule(rule)
  • Ignorer les règles personnalisées et réactiver une règle ne sont plus pris en charge
• Les valeurs AxeRuleId sont maintenant en lowerCamelCase (par exemple, .ColorContrast devient .colorContrast). Le code Swift utilisant l'orthographe ancienne ne compile plus. Le code Objective-C, le JSON exporté, Axe Developer Hub et les paramètres Appium ignoreRules restent inchangés.
• Les URLs de compte http:// sont refusées lors de la connexion avec une clé API. Les clients sur site dont l'URL de compte commence par http:// doivent passer à https://.
• Les APIs supprimées listées sous Dépréciations et suppressions échouent à la compilation.

Android

• Les APIs d'ignorance de règles ont changé. Les anciens appels ne compilent plus :
  • ignoreRules(listOf("ColorContrast")) - utilisez ignoreRules(AxeRuleName.COLOR_CONTRAST)
  • ignoreByViewIdResourceName(id, listOf(...)) - utilisez ignoreRulesOnElementWithId(id, AxeRuleName.X, ...)
  • ignoreExperimental() - supprimez l'appel.
• TouchSizeWcag est maintenant TouchTargetSize, ce qui correspond à iOS et Axe Developer Hub. Mettez à jour tout code, filtre ou tableau de bord qui recherche le nom ancien.
• Les règles personnalisées qui étendent AxeRuleViewHierarchy, ou qui passent le drapeau experimental à AxeRule, ne compilent plus.
• Plugin Gradle : Les builds qui définissent encore axeServerUrl dans le bloc axeDevTools { } doivent passer à axeAccountUrl.
• Les APIs supprimées listées sous Dépréciations et suppressions échouent à la compilation.

Problèmes connus

Nouveaux problèmes

Si vous rencontrez l'un des problèmes ci-dessous, veuillez nous contacter à l'adresse helpdesk@deque.com ou à support.deque.com. Nous pourrons alors vous notifier une fois que le problème est résolu ou d'une solution de contournement identifiée si aucune n'est listée.

iOS

Faux positifs pour les règles Supports Dynamic Type et Clipped Text

Les règles Supports Dynamic Type et Clipped Text (iOS 17 et ultérieur) utilisent les résultats de l'audit d'accessibilité d'Apple. Cet audit signale parfois du texte qui se met correctement à l'échelle ou qui est entièrement visible, et ces règles rapportent ce que retourne Apple. La plupart des échecs de ces règles sont de vrais problèmes, nous ne recommandons donc pas de les ignorer en tant que groupe. Ce problème a été signalé à Apple, et nous travaillons à réduire ces faux positifs.

Pour confirmer un échec, activez les Tailles d'accessibilité plus grandes dans Settings > Accessibility > Display & Text Size > Larger Text. Passez en revue chaque taille de texte, de la taille par défaut à la plus grande, et vérifiez que le texte signalé se met à l'échelle et reste entièrement visible. Le texte peut sembler correct à la plus grande taille mais se briser à une taille intermédiaire.

Si l'échec est un faux positif, ignorez la règle sur cet élément par son identifiant d'accessibilité. Nous ne recommandons pas d'ignorer la règle pour tout le scan ou par nom de classe, car cela pourrait également masquer de vraies défaillances.

Android

Faux positifs lors du balayage des cartes

Il n'est actuellement pas possible de déterminer avec précision si un élément à l'écran est contenu dans une carte, donc nos règles pourraient scanner par inadvertance des épingles de carte et donner des résultats faux positifs. C'est un problème avec la façon dont le système Android rapporte les cartes au Service d'accessibilité.

Utilisez notre API d'ignorance des règles pour exclure votre carte ou vos épingles de carte du balayage en utilisant leurs IDs.

En savoir plus sur l'ignorance des règles.

Les applications construites avec Unity ne peuvent pas être scannées

Axe DevTools Mobile ne peut pas scanner le contenu à l'écran des applications construites avec le moteur de jeu Unity. Cela affecte les balayages automatisés avec la bibliothèque Android ainsi que les balayages effectués avec l'application Accessibility Analyzer. Les résultats ne montrent que des vérifications au niveau de l'écran - pour des règles telles que l'Orientation de l'écran et le Titre de l'écran - et rien pour les boutons, textes, ou interrupteurs de l'application.

Il n'existe pas de solution de contournement pour le moment.

Problèmes résolus

iOS

Supprimé : Image View Name et Active Control Name obsolètes avec faux positifs

Nous avons supprimé une entrée obsolète concernant les faux positifs de Active Control Name sur un UIImageView qui a un accessibilityIdentifier. Ce problème ne concernait que la version v2.11.0 et a été résolu dans la version de juin 2024. Active Control Name ne fonctionne plus sur ces images dans les applications UIKit. Image View Name les signale désormais comme Nécessitant un examen à la place (voir Résultats de la révision de la règle de nommage ImageView pour les applications UIKit).