axe DevTools Mobile Notes de version du 18 octobre 2023

Versions des composants

• axeDevToolsXCUI v2.8.0
• axe-devtools-android v4.2.0

Quoi de neuf ?

Prise en charge de WCAG 2.2

WCAG 2.2 a été officiellement publié le 5 octobre. Notre règle « Espacement des cibles tactiles » est sortie du statut expérimental. Cette règle est conforme aux WCAG 2.2. 2.5.8 et garantit que les cibles respectent une taille minimale ou disposent d'un espacement suffisant autour d'elles. Ceci est important pour les personnes souffrant de handicaps physiques qui ne peuvent pas cliquer sur de petits boutons rapprochés. En savoir plus sur la [version WCAG 2.2.] (https://www.deque.com/blog/deque-systems-welcomes-and-announces-support-for-wcag-2-2/). Consultez la documentation de la [règle d'espacement des cibles tactiles pour iOS] (ios-touch-target-spacing) et de la [règle d'espacement des cibles tactiles pour Android] (/android-touch-target-spacing).

Saviez-vous ? La règle d'espacement des cibles tactiles (WCAG 2.2, 2.5.8) répond aux normes AA, tandis que la règle de taille des cibles tactiles (WCAG 2.1, 2.5.5) répond aux normes AAA. Pour les contrôles importants, WCAG recommande de viser la règle plus stricte de taille de cible tactile pour répondre aux normes AAA. Deque recommande également de viser la règle la plus stricte sur mobile, car elle impose la conformité avec la ligne directrice 44ptx44pt d'Apple et s'aligne plus étroitement avec la ligne directrice 48dpx48dp de Google pour garantir qu'il n'y ait aucun problème lors de la soumission de votre application aux magasins d'applications.

Changement important – Analyser uniquement les vues visibles

Axe DevTools Mobile analysera désormais uniquement les vues visibles par l'utilisateur au moment de l'analyse. Auparavant, la valeur par défaut était d'analyser toutes les vues, même celles qui étaient hors écran ou masquées par d'autres vues.

Comment cela améliore-t-il les résultats ?

• En analysant uniquement ce qui est visible pour l'utilisateur, les résultats reflètent plus précisément l'expérience utilisateur d'une personne handicapée ou d'une personne utilisant une technologie d'assistance. Tout ce qui se trouve derrière une boîte de dialogue ou une fenêtre modale et qui n'est pas accessible par l'utilisateur ou par une technologie d'assistance ne sera pas analysé.
• Les règles de vision par ordinateur, telles que le contraste des couleurs, ne s'exécutent pas sur les vues hors écran. Par conséquent, auparavant, les vues hors écran ne recevaient que les résultats d'un ensemble de règles limité. En numérisant uniquement les vues dans les limites de l'écran, vous pouvez être assuré que toutes les vues numérisées bénéficient de l'ensemble des règles.

Qu'est-ce que cela signifie pour votre équipe ?

Si les cases pour « Filtrage des problèmes » ne sont pas actuellement cochées sur votre tableau de bord, vous ne remarquerez aucune différence dans les résultats de votre tableau de bord. Les vues qui ne sont pas visibles par l'utilisateur sont déjà exclues de vos résultats.

Sinon, une fois que vous avez effectué la mise à niveau vers axeDevToolsXCUI v2.8.0 et axe-devtools-android v4.2.0 :

• Les vues masquées derrière d'autres vues, telles que les modales ou les fenêtres contextuelles, n'auront pas de résultats d'accessibilité.
• Les vues hors écran, telles que celles situées au-dessus ou en dessous de la position de défilement actuelle, n'auront pas de résultats d'accessibilité.
  • Astuce : effectuez une analyse à chaque position de défilement d'un long écran pour vous assurer de capturer tous les problèmes d'accessibilité. Par exemple, si l'écran d'accueil de votre application s'étend sur 3 écrans, vous devez effectuer 3 analyses comme indiqué ci-dessous :
    
  • Pour les écrans longs avec un type d'affichage répété, comme une liste, plusieurs analyses à chaque position de défilement peuvent ne pas être nécessaires. Une seule analyse de la première zone visible permettra probablement de détecter les problèmes d’accessibilité récurrents.

iOS

• La règle de texte associé est sortie du statut expérimental. Cette règle garantit qu'un contrôle obtient son nom accessible à partir d'une étiquette proche disponible pour les technologies d'assistance telles que VoiceOver et Voice Control.
• La règle de contraste des couleurs a reçu une amélioration pour obtenir une taille de police estimée et améliorer encore la précision des résultats. Ce changement signifie que les résultats de certains scénarios indiqueront désormais le statut « Réussite » ou « Échec » au lieu de « Nécessite une révision ».

Android

• Changement radical dans les règles personnalisées - L'interface d'exécution de règles personnalisées dans Android a reçu une mise à jour pour renvoyer un RunRuleResult objet au lieu d'un String type. Consultez un exemple complet du changement ou plus d'informations sur règles personnalisées dans Android.
• Après un examen attentif, nous avons décidé de supprimer les Règles de Vue Masquée expérimentales de notre bibliothèque - Focus de Vue Active Masquée et Focus de Vue Informative Masquée. Ces règles expérimentales ont connu de nombreuses itérations au fur et à mesure que nous avons recueilli des commentaires pendant deux ans. Nous avons constaté que l'automatisation de ces règles peut potentiellement renvoyer des faux positifs et avons donc décidé de les supprimer de notre ensemble de règles automatisées pour soutenir notre engagement à 0 faux positifs. Avec cette version, nous avons déplacé les Règles de Vue Masquée vers le statut « ignoré ». Ils n'apparaîtront plus dans votre décompte de résultats « échoués » ou « réussis ». Dans notre prochaine version (date à déterminer), ils seront entièrement supprimés de la bibliothèque.
• Nous avons ajouté des résumés plus descriptifs aux règles pour mieux décrire pourquoi elles sont marquées comme réussies, échouées ou nécessitant une révision.
• Les API Compose acceptent désormais de lancer une activité en utilisant ComposeEmptyTestRule [missing phrase] ActivityScenario Cela peut être plus simple que d'utiliser AndroidComposeTestRule, en particulier lorsque vous utilisez à la fois les vues XML et Compose. En savoir plus sur l’utilisation de la Règle de Test Vide Compose.
• Avec cette version, nous sommes passés de la version 1.7 de Kotlin à la version 1.9 de Kotlin pour garantir que nos bibliothèques restent compatibles avec les dernières versions de Jetpack Compose. La version 1.9 de Kotlin est rétrocompatible avec Kotlin 1.8 et versions ultérieures. Si votre application repose sur une version de Kotlin inférieure à 1.8, continuez à utiliser axe-devtools-android v4.1.0 ou inférieure.
• Nous sommes passés de Moshi 1.12.0 à 1.15.0 et de Jetpack Compose 1.4.3 à 1.5.1.

Corrections de bugs

iOS

• Tough Target Spacing a reçu quelques mises à jour pour gérer les cas extrêmes de contrôles cachés et d'éléments qui se chevauchent complètement.
• Améliorations autour de la détection des éléments d'accessibilité dans les cas extrêmes qui amélioreront la précision des résultats pour divers contrôles de test de règles.
• Supports Dynamic Type rule ne s'exécutera pas sur les contrôles sans texte visible.
• Le framework ne se bloque plus sur les éléments Picker. Aucun changement dans les résultats n'est attendu car il n'existe pas de règles actuelles ciblant les éléments Picker. Nous chercherons des opportunités pour aller de l’avant.

Android

• Nous avons ajouté des propriétés d’orientation d’écran compréhensibles par l'homme aux valeurs analysées pour la règle d’orientation de l’écran. Auparavant, il s’agissait de valeurs entières qui ne pouvaient pas être facilement comprises par la personne examinant les résultats.
• Vous pouvez désormais mettre à jour la liste des règles personnalisées lors de l'utilisation de l'analyse indépendante de la mise en page via le registre d'instrumentation.

Tableau de bord

• Améliorations de l'accessibilité à l'arborescence dans la fonctionnalité « Inspecter ». Vous pouvez désormais naviguer avec succès dans l’arborescence à l’aide d’un clavier ou d’une technologie d’assistance.

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.

axe DevTools Mobile pour iOS

axe DevTools Mobile pour Android

implementation 'androidx.core:core-ktx:1.9.0'
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.4'
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.4'
	

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)
	

Tableau de bord axe DevTools Mobile