axe DevTools Mobile Notes de version du 26 juin 2024

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

26 juin 2024

Not for use with personal data

Versions des composants

  • Plugin Appium (v2.2.0)
  • SDK et analyseur iOS (axeDevToolsXCUI v2.12.0)
  • SDK Android (axe-devtools-android v5.5.1)
  • Analyseur Android (analyseur d'accessibilité axe v1.8.1)
    Comment mettre à jour : iOS SDK, iOS Analyzer, Android SDK, Android Analyzer

Quoi de neuf ?

Appium

  • Nouvelles règles : nous avons ajouté la prise en charge WCAG 2.2 avec la règle d'Espacement des Cibles Tactiles pour iOS et Android. Nous avons également ajouté la règle Modifier la Valeur du Texte pour Android.
  • Plus de prise en charge des types de contrôle dans les règles sur iOS : nous prenons désormais en charge les contrôles au-delà des simples boutons pour toutes les règles.
  • Service d'utilisation : si votre équipe utilise le service d'utilisation pour suivre l'utilisation de l'outil axe DevTools Mobile, les données Appium seront désormais incluses.

iOS

  • La version iOS minimale prise en charge a été augmentée à iOS 15.
  • Après les avis d'obsolescence précédents, la règle des contrôles en collision ne fonctionnera plus en faveur de la règle d'espacement des cibles tactiles qui couvre les contrôles en collision ainsi que la taille de la cible.

Corrections

Android

  • Améliorations et perfectionnements pour augmenter la précision et réduire les faux positifs dans les règles suivantes : nom de la vue active, taille de la cible tactile, étiquette dans le nom et étiquette en avant.
  • Amélioration de l'identification et des résultats des règles pour les vues hors écran ou partiellement hors écran.

iOS

  • Amélioration de la règle du nom du contrôle actif pour garantir une meilleure expérience d'accessibilité à vos utilisateurs finaux lors de l'utilisation du contrôle de l'incrément.
  • Améliorations et perfectionnements pour augmenter la précision et réduire les faux positifs et négatifs dans les règles suivantes : nom du contrôle actif, nom de la vue d'image et étiquette en avant.

Appium

  • La règle de taille de la cible tactile sur Android s'exécutera désormais sur n'importe quel élément cliquable, quelle que soit sa capacité à recevoir le focus.

Problèmes connus

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

important
  • Les tests automatisés axe DevTools Mobile s'exécutent sur les applications natives iOS, Android natives et React Native. Veuillez contacter votre représentant Deque pour des solutions de test d'accessibilité sur votre pile technologique.
  • Bien que vous puissiez obtenir des résultats à partir de vues Web ou de PDF rendus, nous vous recommandons vivement de tester à l'aide d'axe DevTools pour le Web ou axe Monitor pour les tests d'accessibilité les plus complets pour le Web.

axe DevTools Mobile pour iOS

Erreur dans le projet Analyzer et les tests par ID de bundle dans 2.8.1

La fonctionnalité de test d'une application par identifiant de bundle était interrompue dans la version 2.8.1, ce qui entraînait une erreur intitulée « Aucun chemin d'application cible spécifié via la configuration de test : ... ». Mettez à jour vers la version 2.8.2 ou la dernière version pour résoudre l'erreur. Mettez à jour vers la dernière version dans le cadre du projet iOS Analyzer.

Les vues hors-champ peuvent afficher les résultats des applications SwiftUI testées dans iOS 17

Avec la version 2.8.0 (Voir les notes de publication), les résultats ne sont plus signalés sur les vues qui ne sont pas visibles, y compris hors-champ ou masquées par une autre vue. Nous avons découvert que dans les applications SwiftUI testées dans iOS 17, certains résultats apparaissent encore. (#1383)

La règle 'Supports Dynamic Type' ne fonctionne pas avec le simulateur iOS 15 Pro

Il existe un problème affectant le simulateur iPhone 15 Pro qui empêche l'exécution de la règle Prend en charge le type dynamique. Si vous avez opté pour la règle « Prend en charge le type dynamique », vous ne pourrez pas la tester à l’aide d’un simulateur iPhone 15 Pro. Un bug a été signalé à Apple.

Règles contre les contrôles imbriqués

En recherchant une amélioration de nos règles, nous avons constaté que dans XCTest, les contrôles imbriqués ne sont pas renvoyés dans l’arborescence d’accessibilité. Un bug a été signalé à Apple. (#1110)

Les résultats de la règle de nom ImageView doivent être examinés pour les applications UIKit

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 des problèmes de nom ImageView dans les applications UIKit seront signalés comme Nécessite une révision. Un rapport de bogue a été déposé auprès d'Apple. (#1633)

Faux positif : dans Scroll View, Label In Name, Label at Front, et Image View Name v2.11.0 & ActiveControlName


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

En mode défilement
Peut signaler des problèmes de texte dans les éléments se comportant comme des bannières. Pour rendre ces éléments accessibles à ceux qui ont besoin d’un texte plus grand, utilisez UILargeContentViewer. (#622)

v2.11.0 Nom de la vue d'image & ActiveControlName
Si un UIImageView possède un `accessibilityIdentifier` attribut mais n'est pas focalisable par VoiceOver et qu'il contient des contrôles focalisables imbriqués, ActiveControlName peut signaler un faux positif sur le UIImageView. La suppression du `accessibilityIdentifier` résout le problème. Un bug a été signalé à Apple. (#1633)

Étiquette dans le nom et étiquette en avant
Ces deux règles recherchent l'étiquette visible d'un contrôle parmi les éléments proches pour aider à déterminer l'état de la règle. Dans certaines hiérarchies de vues, le texte incorrect à proximité peut être détecté, ce qui entraîne l'échec de ces règles. (#1622)

axe DevTools Mobile pour Android

Crash lorsque `minifiedEnabled` est défini sur true

Si vous minifiez votre construction, vous verrez un crash avec un journal d'erreurs signalant qu'un adaptateur n'a pas pu être trouvé lors de la tentative de se connecter à la bibliothèque axe DevTools. Désactivez la minification pour vos constructions de débogage avec axe DevTools intégré. (#729)

Les builds avec r8 activé génèrent une erreur

Une construction avec r8 activé peut tenter de minifier la bibliothèque axeDevTools, ce qui entraîne 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)
	
Pour résoudre cette erreur, ajoutez la ligne suivante à votre fichier ProGuard pour conserver les classes axeDevTools :
keep class com.deque.** { *; }

Message d'erreur similaire à :
Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)
ou: No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?

Si 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 à API Compose setTestTag .

Tableau de bord axe DevTools Mobile

Capture d'écran manquante

Si la capture d'écran est manquante sur la page des détails de l'analyse, votre application peut empêcher la prise de captures d'écran. 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.

Certains noms d'analyse Android ne sont pas formatés

Certains noms de scan Android qui sont par défaut dans le titre de l'écran apparaîtront comme le nom de classe complet, y compris l'identifiant du bundle. Dans une version ultérieure, ce problème sera résolu afin que le titre de l'écran soit formaté en un nom plus lisible. Pour contourner ce problème, vous pouvez définir le nom du scan à partir du tableau de bord ou des frameworks. (#1643)

Axe DevTools Mobile pour Appium

Faux-positifs : nom de la vue active, espacement des cibles tactiles


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

Nom de la vue active
En raison des limitations des informations disponibles via la plateforme Appium, nous avons identifié un faux positif pour Nom de Vue Active lors de l'utilisation de la propriété labeledBy pour fournir une étiquette pour un élément de bouton.

Touch Target Spacing sur la plateforme iOS pour les applications SwiftUI et React Native
Les contrôles plus grands peuvent échouer à l'Espacement des cibles tactiles lorsqu'ils sont supérieurs à l'exigence minimale de 24 pt x 24 pt. (#411)

Faux négatif : action inaccessible sur Android React Native


Vous pouvez voir des résultats contradictoires pour cette nouvelle règle lors de l'analyse des applications React Native sur la plate-forme Android. Certaines vues auront un élément de bouton imbriqué entraînant une erreur pour le bouton parent, mais une réussite pour le bouton enfant. (#407)

React Native : Étiquette dans le nom et étiquette au début

En raison des limitations des informations disponibles via la plateforme Appium, nous avons identifié que les règles Label In Name et Label At Front ne peuvent pas fonctionner pour les applications créées avec React Native. Nous explorons des solutions et attendons un correctif dans une future version.

React Native et .NET MAUI : inspecter la hiérarchie des vues affichant l'écran précédent

Parfois, la propriété source de la page Appium nécessite un temps supplémentaire pour être mise à jour entre les analyses. Si cela se produit, vous verrez la hiérarchie des vues d'un écran précédent lorsque vous utilisez la fonction d'inspection sur le tableau de bord. Pour résoudre ce problème, ajoutez un petit délai d’attente avant d’appeler l’API source de la page pour déclencher l’analyse d’accessibilité. Exemple :

			await driver.pause(1000);
    		const result = await driver.getPageSource();
		

Limitation : nom de la vue d'image pour les images décoratives dans Android

En raison des limitations des informations disponibles via la plateforme Appium, nous avons identifié que la règle Nom de la vue d'image n'est pas en mesure de tester avec précision les critères de réussite des images décoratives dans Android. Les résultats des images sans nom accessible s'afficheront comme « Nécessite un examen » dans le tableau de bord pour une analyse plus approfondie.