Automatizzare i test del lettore di schermo su macOS utilizzando Auto VO

Pubblicato: 2022-03-10
Riepilogo rapido ↬ Il test automatizzato è una parte importante di qualsiasi progetto software, incluso il test per l'accessibilità. Esistono già strumenti per l'accessibilità dei test di linting e integrazione, ma che dire dei test end-to-end con una vera tecnologia assistiva? Dato che non l'avevo visto prima, ho deciso di creare Auto VO, un driver per lo screen reader VoiceOver.

Se sei un nerd dell'accessibilità come me, o semplicemente curioso della tecnologia assistiva, adorerai Auto-VO. Auto-VO è un modulo nodo e un'interfaccia a riga di comando per il test automatizzato di contenuti Web con lo screen reader VoiceOver su macOS.

Ho creato Auto VO per rendere più facile per sviluppatori, PM e QA eseguire più rapidamente test ripetibili e automatizzati con una vera tecnologia assistiva, senza il fattore intimidatorio di imparare a utilizzare uno screen reader.

Andiamo!

Per prima cosa, vediamolo in azione, quindi entrerò più nel dettaglio su come funziona. Ecco in esecuzione la CLI di auto-vo su smashingmagazine.com per ottenere tutto l'output di VoiceOver come testo.

 $ 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)

Sembra una struttura di pagina ragionevole: abbiamo collegamenti per saltare la navigazione, elenchi ben strutturati e navigazione semantica. Ottimo lavoro! Scaviamo un po' più a fondo però. Com'è la struttura dell'intestazione?

 $ 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! Qualcosa è un po' strano con la nostra gerarchia di titoli. Dovremmo vedere uno schema, con un livello di intestazione uno e una gerarchia ordinata dopo. Invece, vediamo un po' un miscuglio di livello 1, livello 2 e un livello 4 errante. Ciò richiede attenzione poiché influisce sull'esperienza degli utenti di screen reader durante la navigazione nella pagina.

Avere l'output dello screen reader come testo è ottimo perché questo tipo di analisi diventa molto più semplice.

Un po' di sfondo

VoiceOver è l'utilità per la lettura dello schermo su macOS. Le utilità per la lettura dello schermo consentono alle persone di leggere ad alta voce il contenuto dell'applicazione e anche di interagire con il contenuto. Ciò significa che le persone ipovedenti o non vedenti possono in teoria accedere ai contenuti, inclusi i contenuti web. In pratica, però, il 98% delle pagine di destinazione sul Web presenta errori evidenti che possono essere rilevati con test e revisioni automatizzati.

Esistono molti strumenti di test e revisione automatizzati, tra cui AccessLint.com per la revisione automatizzata del codice (divulgazione: ho creato AccessLint) e Axe, un punto di riferimento comune per l'automazione. Questi strumenti sono importanti e utili, ma sono solo una parte del quadro. Il test manuale è ugualmente o forse più importante, ma richiede anche più tempo e può intimidire.

Potresti aver sentito una guida per "accendere lo screen reader e ascoltare" per darti un'idea dell'esperienza cieca. Penso che questo sia fuorviante. I lettori di schermo sono applicazioni sofisticate che possono richiedere mesi o anni per essere padroneggiate e all'inizio sono travolgenti. Usarlo a casaccio per simulare l'esperienza dei ciechi potrebbe portarti a dispiacerti per i ciechi o, peggio, cercare di "aggiustare" l'esperienza nel modo sbagliato.

Ho visto persone nel panico quando abilitano VoiceOver, non sapendo come disattivarlo. Auto-VO gestisce per te il ciclo di vita dello screen reader. Automatizza l'avvio, il controllo e la chiusura di VoiceOver, quindi non è necessario. Invece di cercare di ascoltare e tenere il passo, l'output viene restituito come testo, che puoi quindi leggere, valutare e acquisire per dopo come riferimento in un bug o per lo snapshot automatico.

Utilizzo

Avvertimento

In questo momento, a causa del requisito di abilitare AppleScript per VoiceOver, potrebbe essere necessaria la configurazione personalizzata delle macchine di compilazione CI per l'esecuzione.

Scenario 1: QA e accettazione

Diciamo che io (lo sviluppatore) ho un design con annotazioni blueline, in cui il designer ha aggiunto descrizioni di cose come nome e ruolo accessibili. Dopo aver creato la funzione e aver esaminato il markup negli strumenti di sviluppo di Chrome o Firefox, desidero inviare i risultati in un file di testo in modo che quando contrassegno la funzione come completa, il mio PM possa confrontare l'output dello screen reader con le specifiche di progettazione . Posso farlo usando l'auto-vo CLI e inviando i risultati a un file o al terminale. Abbiamo visto un esempio di questo in precedenza nell'articolo:

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

Scenario 2: sviluppo basato su test

Eccomi di nuovo come sviluppatore, costruendo la mia funzionalità con un design annotato in blueline. Voglio testare il contenuto in modo da non dover rifattorizzare il markup in seguito per adattarlo al design. Posso farlo usando il modulo nodo auto-vo importato nel mio test runner preferito, ad esempio 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); });

Sotto il cappuccio

Auto-VO utilizza una combinazione di script di shell e AppleScript per guidare VoiceOver. Durante l'esplorazione dell'applicazione VoiceOver, mi sono imbattuto in una CLI che supporta l'avvio di VoiceOver dalla riga di comando.

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

Quindi, una serie di eseguibili JavaScript gestisce le istruzioni AppleScript per navigare e acquisire gli annunci VoiceOver. Ad esempio, questo script ottiene l'ultima frase dagli annunci dello screen reader:

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

In chiusura

Mi piacerebbe sentire la tua esperienza con auto-vo e dare il benvenuto a contributi su GitHub. Provalo e fammi sapere come va!

Altro dopo il salto! Continua a leggere sotto ↓