Découvrons ensemble le produit WorldSpace Attest pour Android d’ Deque. Si vous ne connaissez pas encore Attest, il s’agit d’une suite d’outils de tests automatisés pour HTML, iOS et Android qui permet aux développeurs de tester l’accessibilité. Grâce à Attest pour Android, les développeurs d’applications mobiles natives peuvent exécuter des tests d’accessibilité automatisés sur leur code dans le cadre de leurs processus habituels de tests d’intégration et unitaires. J’aimerais consacrer ce temps à passer en revue le workflow qu’un expert en accessibilité suivrait pour utiliser ce produit. En d’autres termes, vous n’avez pas accès au code source ni à l’équipe de développement pour suivre le processus. L’autre workflow possible pour ce produit consisterait en une analyse entièrement automatisée avec des tests unitaires intégrés, en utilisant notre bibliothèque d’analyse.
Si vous le souhaitez, vous pouvez suivre mon tutoriel vidéo ici :
Pour commencer
Avant de commencer, téléchargez et installez l'application WorldSpace Attest depuis le Google Play Store. Dans ma démonstration, je diffuse l'écran d'un véritable appareil mobile sur mon ordinateur portable via Vysor.
Application de démonstration « Attest » pour Android
La première chose que vous verrez en ouvrant le pack WorldSpace Attest, c’est qu’une application est jointe au téléchargement. Cette application sert uniquement de démonstration du produit. Par exemple, si vous avez une question sur le fonctionnement de l'une de nos règles ou sur les comportements observés par les utilisateurs lorsqu'ils constatent ces violations, vous pouvez vous rendre ici et demander : « Est-ce que ce comportement correspond à celui que l'application est censée détecter ? »
Configuration d'Android pour Attest
L’étape suivante consiste à accéder à vos paramètres. Rendez-vous dans la section « Accessibilité » et recherchez le service « Attest for Android ». Il figure dans la même rubrique que d’autres services d’accessibilité, tels que TalkBack. Activez le service : vous constaterez que notre test commence alors à capturer tout ce qui s’affiche sur votre écran. Cette fonctionnalité est conçue pour effectuer une analyse du contraste des couleurs. Si cette analyse ne vous intéresse pas, vous pouvez ignorer cette étape. Revenons à l’exemple des libellés de contrôle. Si vous observez ce qui se passe dans cette application de bureau, vous remarquerez que vous pouvez cliquer sur « Rechercher des appareils ». Une fenêtre contextuelle s’affichera pour vous permettre de sélectionner votre appareil mobile ; vous devrez alors cliquer sur « OK ». Votre client de bureau et votre application sont désormais synchronisés.
Exemple : Workflow relatif aux violations d'accessibilité des étiquettes de contrôle
Sur cet appareil et sur mon client de bureau, lorsque vous cliquez sur « Analyser », le système analyse tout ce qui s’affiche à l’écran de cet appareil, n’est-ce pas ? Ainsi, si vous cliquez sur « Analyser », vous verrez s’afficher une violation des règles relatives aux étiquettes des contrôles. Les contrôles qui ne disposent pas de leur propre nom accessible doivent être associés à une étiquette visible. Vous verrez également d’autres informations détaillées qui vous aideront à comprendre pourquoi ce problème se produit et à identifier le contrôle concerné. Notez qu’il y a cet identifiant, mais il est très souvent nécessaire d’ajouter notre propre identifiant. L’ID de vue correspondra au nom de la ressource ou, s’il y en a un, au nom de la ressource d’ID de vue associé à la vue. Le nom de classe correspond évidemment à la classe. Tous ces éléments auront une signification différente selon les publics. Le nom de classe est particulièrement pertinent pour un développeur.
Voici les informations que vous devrez transmettre à vos développeurs. Par exemple : « Le bouton comportant ce texte à cet emplacement présente ce problème. » Vous pouvez même le mettre en surbrillance et faire une capture d'écran pour le signaler à votre développeur. Tout en bas, vous remarquerez que l'application indique que les éléments « Android.switch » ont enregistré des informations, qu'ils n'ont pas de nom et qu'ils doivent être associés à une étiquette visible.
Comment utiliser Attest pour Android afin d'analyser n'importe quelle application tierce
Il est important de noter que vous n’êtes pas obligé d’effectuer l’analyse sur notre application de démonstration. Cette fonctionnalité fonctionne avec n’importe quelle application tierce, et c’est précisément ce qui fait d’Attest for Android un produit aussi performant. Vous pouvez, par exemple, analyser les commandes de Talkback. Attest for Android est capable d’effectuer une analyse sur cette vue au niveau du système. Ainsi, si vous analysez les commandes de Talkback, vous constaterez ces violations des règles d’accessibilité.
Notez que la fonction de surlignage est toujours activée ; vous pouvez donc surligner ces vues au fur et à mesure que vous les parcourez. Ici, vous pouvez consulter la vue des libellés de contrôle ; vous constaterez que ce bouton d’arrêt n’est pas associé au fait qu’il désactive TalkBack. De plus, l’analyse du contraste des couleurs n’est pas conforme. Enfin, la vue de l’image n’est pas conforme : aucune information n’est associée à cette image. L’une des solutions pourrait consister à ajouter une description du contenu, mais une autre pourrait simplement consister à masquer cette vue de la couche des technologies d’assistance, de la même manière que l’on utilise l’attribut « presentational » dans ARIA sur un site web. En résumé, voici comment les experts métier peuvent utiliser Attest pour Android dans leur processus de test d’accessibilité. Si vous avez des questions sur le produit ou si vous souhaitez voir Attest pour Android en action, contactez-nous pour une démonstration!
