Automatiser les tests de lecteur d'écran sur macOS à l'aide de la VO automatique —

À propos de l'auteur

Cameron Cundiff est un ingénieur logiciel et un leader en matière d'accessibilité et de conception inclusive. Il construit AccessLint et est le co-fondateur et organisateur du New…

En savoir plus sur

Cameron
↬

Si vous êtes un passionné de l'accessibilité comme moi, ou si vous êtes simplement curieux de connaître les technologies d'assistance, vous allez adorer Auto-VO. Auto-VO est un module de nœud et une interface de ligne de commande permettant de tester automatiquement le contenu Web avec le lecteur d'écran VoiceOver sur macOS.

J'ai créé Auto VO pour permettre aux développeurs, aux chefs de projet et à l'assurance qualité de travailler plus rapidement. effectuez des tests automatisés reproductibles avec une véritable technologie d'assistance, sans le facteur d'intimidation d'apprendre à utiliser un lecteur d'écran. Comment ça fonctionne. Voici l'exécution de la CLI auto-vo sur smashingmagazine.com pour obtenir toutes les sorties VoiceOver sous forme de texte.

$ auto-vo --url https://smashingmagazine.com --limit 200 > output.txt
$ cat sortie.txt
lien Aller à tous les sujets
lien Aller à la liste de tous les articles
lien image Smashing Magazine
liste 6 articles
lien articles
lien Guides 2 sur 6
lien Livres 3 sur 6
lien Ateliers 4 sur 6
lien Adhésion 5 sur 6
Plus de menu contextuel bouton réduit 6 sur 6
fin de liste
fin de navigation
...(tronqué)

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

$ cat output.txt | titre grep
titre niveau 2 lien Un guide complet des outils d'accessibilité
lien de niveau 2 pour créer plusieurs sites WordPress localement avec DevKinsta
titre niveau 2 lien Smashing Podcast Épisode 39 avec Addy Osmani: Optimisation de l'image
titre niveau 2 2 éléments UN GUIDE ÉCLAIR DES Composants Front-End accessibles
titre niveau 2 2 éléments UN GUIDE ÉCLAIR DES Générateurs & Outils CSS
titre niveau 2 2 éléments UN GUIDE ÉCLAIR DE LA PERFORMANCE Front-End 2021
titre niveau 4 DERNIERS MESSAGES
lien de niveau 1 lorsque CSS ne suffit pas : exigences JavaScript pour les composants accessibles
Lien d'en-tête niveau 1 Conception Web bien faite : utilisation de l'audio
Liaison niveau 1 de la rubrique Plaques chauffantes frontales utiles et kits de démarrage
lien de niveau 1 d'en-tête Trois outils d'audit frontaux que j'ai découverts récemment
lien de niveau 1 de titre Meet :has, un sélecteur de parent CSS natif (et plus)
lien de niveau 1 d'en-tête D'AVIF à WebP : un nouveau livre fracassant par Addy Osmani

Hum ! Quelque chose est un peu génial avec notre hiérarchie de titres. Nous devrions voir un aperçu, avec un niveau de titre 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, de 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 lorsqu'ils naviguent sur la page. ce type d'analyse devient beaucoup plus facile.

Un peu d'arrière-plan

VoiceOver est le lecteur d'écran sur macOS. Les lecteurs d'écran permettent aux utilisateurs de lire à haute voix le contenu de l'application 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. Dans la pratique, cependant, 98 % des pages de destination sur le Web contiennent des erreurs évidentes qui peuvent être capturées à l'aide de tests et d'examens automatisés.

Il existe de nombreux outils de test et d'examen automatisés, notamment AccessLint.com pour revue de code automatisée (divulgation : j'ai construit AccessLint) et Axe, une référence commune pour l'automatisation. Ces outils sont importants et utiles, mais ils ne sont qu'une partie du tableau. Les tests manuels sont tout aussi ou peut-être plus importants, 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 à l'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 sont écrasantes au début. L'utiliser au hasard pour simuler l'expérience des aveugles peut vous amener à vous sentir désolé pour les personnes aveugles, ou pire, à essayer de « réparer » l'expérience de la mauvaise manière.

J'ai vu des gens paniquer lorsqu'ils activent VoiceOver, ne sachant pas comment éteignez-le. 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, vous n'avez donc 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 l'exigence d'activer AppleScript pour VoiceOver, cela peut nécessiter une configuration personnalisée des machines de construction CI pour s'exécuter. – 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 afficher 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 l'auto-vo CLI et en publiant les résultats dans un fichier ou le terminal. Nous en avons vu un exemple plus tôt 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é en bleu. Je souhaite tester le contenu afin de ne pas avoir à remanier 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 lanceur de test préféré, par ex. Moka.

$ npm install --save-dev auto-vo
importer { exécuter } depuis 'auto-vo' ;
importer { attendre } de 'chai' ;

describe('chargement example.com', async () => {
  it('retourne les annonces', async () => {
    const options = { url : 'https://www.example.com', limite : 10, jusqu'à : 'Example' } ;

    annonces const = wait run(options);

    s'attendre à ce que les (annonces).incluent.des.membres(['Example Domain web content']);
  }).timeout(5000);
});

Under the Hood

Auto-VO utilise une combinaison de script 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 obtient la dernière phrase des annonces du lecteur d'écran :

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

En clôture

Je serais ravi d'entendre votre expérience avec auto-voet les contributions bienvenues sur GitHub. Essayez-le et dites-moi comment ça se passe !

(vf, il)