Automatisation des tests de lecteur d'écran sur macOS à l'aide d'Auto VO

Si vous êtes un nerd de l'accessibilité comme moi, ou simplement curieux des technologies d'assistance, vous allez creuser Auto-VO. Auto-VO est un module de nœud et une CLI pour le test automatisé du contenu Web avec le lecteur d'écran VoiceOver sur macOS.

J'ai créé Auto VO pour permettre aux développeurs, aux PM et à l'assurance qualité d'effectuer plus rapidement des tests reproductibles et automatisés avec une véritable technologie d'assistance, sans le facteur d'intimidation lié à l'apprentissage de l'utilisation d'un lecteur d'écran.

Allons-y!

Voyons d'abord cela en action, puis j'expliquerai plus en détail son fonctionnement. Voici en cours d'exécution auto-vo CLI sur smashingmagazine.com pour obtenir toute la sortie VoiceOver sous forme de texte.

 $ auto-vo --url https://smashingmagazine.com --limit 200 > output.txt $ cat output.txt link Jump to all topics link Jump to list of all articles link image Smashing Magazine list 6 items link Articles link Guides 2 of 6 link Books 3 of 6 link Workshops 4 of 6 link Membership 5 of 6 More menu pop up collapsed button 6 of 6 end of list end of navigation ...(truncated)

Cela semble être une structure de page raisonnable : nous avons des liens de navigation, des listes bien structurées et une navigation sémantique. Bon travail! Creusons un peu plus quand même. Comment est la structure des titres ?

 $ cat output.txt | grep heading heading level 2 link A Complete Guide To Accessibility Tooling heading level 2 link Spinning Up Multiple WordPress Sites Locally With DevKinsta heading level 2 link Smashing Podcast Episode 39 With Addy Osmani: Image Optimization heading level 2 2 items A SMASHING GUIDE TO Accessible Front-End Components heading level 2 2 items A SMASHING GUIDE TO CSS Generators & Tools heading level 2 2 items A SMASHING GUIDE TO Front-End Performance 2021 heading level 4 LATEST POSTS heading level 1 link When CSS Isn't Enough: JavaScript Requirements For Accessible Components heading level 1 link Web Design Done Well: Making Use Of Audio heading level 1 link Useful Front-End Boilerplates And Starter Kits heading level 1 link Three Front-End Auditing Tools I Discovered Recently heading level 1 link Meet :has, A Native CSS Parent Selector (And More) heading level 1 link From AVIF to WebP: A New Smashing Book By Addy Osmani

Hmm! Quelque chose est un peu funky avec notre hiérarchie des titres. Nous devrions voir un aperçu, avec un titre de niveau un et une hiérarchie ordonnée après cela. Au lieu de cela, nous voyons un peu un méli-mélo de niveau 1, niveau 2 et un niveau 4 errant. Cela nécessite une attention particulière car cela a un impact sur l'expérience des utilisateurs de lecteurs d'écran lors de la navigation sur la page.

Avoir la sortie du lecteur d'écran sous forme de texte est génial car ce type d'analyse devient beaucoup plus facile.

Un peu de contexte

VoiceOver est le lecteur d'écran sur macOS. Les lecteurs d'écran permettent aux utilisateurs de lire le contenu de l'application à voix haute et d'interagir avec le contenu. Cela signifie que les personnes malvoyantes ou aveugles peuvent en théorie accéder au contenu, y compris au contenu Web. En pratique, cependant, 98 % des pages de destination sur le Web comportent des erreurs évidentes qui peuvent être détectées grâce à des tests et à un examen automatisés.

Il existe de nombreux outils de test et de révision automatisés, notamment AccessLint.com pour la révision automatisée du code (divulgation : j'ai créé AccessLint) et Axe, une référence commune pour l'automatisation. Ces outils sont importants et utiles, mais ils ne sont qu'une partie de l'image. Les tests manuels sont tout aussi importants, voire plus, mais ils prennent également plus de temps et peuvent être intimidants.

Vous avez peut-être entendu des conseils pour "allumer simplement votre lecteur d'écran et écouter" pour vous donner une idée de l'expérience aveugle. Je pense que c'est malavisé. Les lecteurs d'écran sont des applications sophistiquées qui peuvent prendre des mois ou des années à maîtriser et qui sont écrasantes au début. L'utiliser au hasard pour simuler l'expérience aveugle peut vous amener à vous sentir désolé pour les aveugles, ou pire, à essayer de "réparer" l'expérience dans le mauvais sens.

J'ai vu des gens paniquer lorsqu'ils activaient VoiceOver, ne sachant pas comment le désactiver. Auto-VO gère pour vous le cycle de vie du lecteur d'écran. Il automatise le lancement, le contrôle et la fermeture de VoiceOver, pour que vous n'ayez pas à le faire. Au lieu d'essayer d'écouter et de suivre, la sortie est renvoyée sous forme de texte, que vous pouvez ensuite lire, évaluer et capturer pour plus tard comme référence dans un bogue ou pour un instantané automatisé.

Usage

Caveat

À l'heure actuelle, en raison de la nécessité d'activer AppleScript pour VoiceOver, cela peut nécessiter une configuration personnalisée des machines de construction CI pour s'exécuter.

Scénario 1 : AQ et acceptation

Disons que je (le développeur) ai une conception avec des annotations blueline - où le concepteur a ajouté des descriptions de choses comme le nom et le rôle accessibles. Une fois que j'ai créé la fonctionnalité et examiné le balisage dans les outils de développement Chrome ou Firefox, je souhaite générer les résultats dans un fichier texte afin que, lorsque je marque la fonctionnalité comme terminée, mon PM puisse comparer la sortie du lecteur d'écran avec les spécifications de conception. . Je peux le faire en utilisant la CLI auto-vo et en sortant les résultats dans un fichier ou le terminal. Nous en avons vu un exemple plus haut dans l'article :

 $ auto-vo --url https://smashingmagazine.com --limit 100

Scénario 2 : Développement piloté par les tests

Me voici à nouveau en tant que développeur, construisant ma fonctionnalité avec un design annoté blueline. Je souhaite tester le contenu afin de ne pas avoir à refactoriser le balisage par la suite pour qu'il corresponde à la conception. Je peux le faire en utilisant le module de nœud auto-vo importé dans mon testeur préféré, par exemple Mocha.

 $ npm install --save-dev auto-vo import { run } from 'auto-vo'; import { expect } from 'chai'; describe('loading example.com', async () => { it('returns announcements', async () => { const options = { url: 'https://www.example.com', limit: 10, until: 'Example' }; const announcements = await run(options); expect(announcements).to.include.members(['Example Domain web content']); }).timeout(5000); });

Sous la capuche

Auto-VO utilise une combinaison de scripts shell et d'AppleScript pour piloter VoiceOver. En creusant dans l'application VoiceOver, je suis tombé sur une CLI qui prend en charge le démarrage de VoiceOver à partir de la ligne de commande.

 /System/Library/CoreServices/VoiceOver.app/Contents/MacOS/VoiceOverStarter

Ensuite, une série d'exécutables JavaScript gèrent les instructions AppleScript pour naviguer et capturer les annonces VoiceOver. Par exemple, ce script récupère la dernière phrase des annonces du lecteur d'écran :

 function run() { const voiceOver = Application('VoiceOver'); return voiceOver.lastPhrase.content(); }

En conclusion

J'aimerais connaître votre expérience avec auto-vo et accueillir les contributions sur GitHub. Essayez-le et faites-moi savoir comment ça se passe!