Automatisieren von Screenreader-Tests auf macOS mit Auto VO

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Automatisiertes Testen ist ein wichtiger Bestandteil jedes Softwareprojekts, einschließlich des Testens auf Barrierefreiheit. Es gibt bereits Tools für Linting- und Integrationstests für Barrierefreiheit, aber was ist mit End-to-End-Tests mit echter Hilfstechnologie? Da ich das noch nie zuvor gesehen hatte, machte ich mich daran, Auto VO zu bauen, einen Treiber für den VoiceOver-Bildschirmleser.

Wenn Sie ein Zugänglichkeits-Nerd wie ich sind oder einfach nur neugierig auf Hilfstechnologien sind, werden Sie Auto-VO lieben. Auto-VO ist ein Knotenmodul und eine CLI zum automatisierten Testen von Webinhalten mit dem VoiceOver-Screenreader unter macOS.

Ich habe Auto VO entwickelt, um es Entwicklern, PMs und QA zu erleichtern, wiederholbare, automatisierte Tests mit echter Hilfstechnologie schneller durchzuführen, ohne den Einschüchterungsfaktor zu lernen, wie man einen Bildschirmleser verwendet.

Lass uns gehen!

Lassen Sie uns es zuerst in Aktion sehen, und dann werde ich näher darauf eingehen, wie es funktioniert. Hier wird die auto-vo CLI auf smashingmagazine.com ausgeführt, um die gesamte VoiceOver-Ausgabe als Text zu erhalten.

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

Scheint eine vernünftige Seitenstruktur zu sein: Wir haben Skip-Navigationslinks, gut strukturierte Listen und semantische Navigation. Gute Arbeit! Lassen Sie uns jedoch etwas tiefer graben. Wie ist die Überschriftenstruktur?

 $ 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! Irgendetwas stimmt mit unserer Überschriftenhierarchie nicht. Wir sollten eine Gliederung sehen, mit einer Überschrift, Ebene eins und einer geordneten Hierarchie danach. Stattdessen sehen wir eine Art Mischmasch aus Ebene 1, Ebene 2 und einer fehlerhaften Ebene 4. Dies erfordert Aufmerksamkeit, da es die Erfahrung der Benutzer von Screenreadern beim Navigieren auf der Seite beeinträchtigt.

Die Ausgabe des Screenreaders als Text ist großartig, da diese Art der Analyse viel einfacher wird.

Etwas Hintergrund

VoiceOver ist der Bildschirmleser auf macOS. Screenreader ermöglichen Benutzern das laute Vorlesen von Anwendungsinhalten und die Interaktion mit Inhalten. Das bedeutet, dass Menschen mit Sehbehinderung oder Blinde theoretisch auf Inhalte zugreifen können, einschließlich Webinhalte. In der Praxis weisen jedoch 98 % der Zielseiten im Web offensichtliche Fehler auf, die durch automatisierte Tests und Überprüfungen erfasst werden können.

Es gibt viele automatisierte Test- und Überprüfungstools, darunter AccessLint.com für die automatisierte Codeüberprüfung (Offenlegung: Ich habe AccessLint erstellt) und Axe, eine gängige Anlaufstelle für die Automatisierung. Diese Tools sind wichtig und nützlich, aber sie sind nur ein Teil des Bildes. Manuelles Testen ist genauso wichtig oder sogar noch wichtiger, aber es ist auch zeitaufwändiger und kann einschüchternd sein.

Sie haben vielleicht schon einmal die Anleitung gehört, „einfach Ihren Screenreader einzuschalten und zuzuhören“, um Ihnen ein Gefühl für das blinde Erlebnis zu vermitteln. Ich denke, das ist falsch. Screenreader sind ausgeklügelte Anwendungen, deren Beherrschung Monate oder Jahre dauern kann und die zunächst überwältigend sind. Wenn Sie es willkürlich verwenden, um die blinde Erfahrung zu simulieren, können Sie blinde Menschen bemitleiden oder, schlimmer noch, versuchen, die Erfahrung auf die falsche Weise zu „reparieren“.

Ich habe gesehen, wie Leute in Panik geraten, wenn sie VoiceOver aktivieren, ohne zu wissen, wie sie es ausschalten können. Auto-VO verwaltet den Lebenszyklus des Screenreaders für Sie. Es automatisiert das Starten, Steuern und Schließen von VoiceOver, sodass Sie es nicht tun müssen. Anstatt zu versuchen, zuzuhören und mitzuhalten, wird die Ausgabe als Text zurückgegeben, den Sie dann lesen, auswerten und für später als Referenz in einem Fehler oder für automatisierte Snapshots erfassen können.

Verwendungszweck

Vorbehalt

Aufgrund der Anforderung, AppleScript für VoiceOver zu aktivieren, ist derzeit möglicherweise eine benutzerdefinierte Konfiguration von CI-Build-Computern erforderlich, um ausgeführt zu werden.

Szenario 1: QA & Abnahme

Nehmen wir an, ich (der Entwickler) habe ein Design mit Blueline-Anmerkungen – wo der Designer Beschreibungen von Dingen wie zugänglichem Namen und Rolle hinzugefügt hat. Nachdem ich die Funktion erstellt und das Markup in den Chrome- oder Firefox-Entwicklungstools überprüft habe, möchte ich die Ergebnisse in eine Textdatei ausgeben, damit mein PM die Ausgabe des Screenreaders mit den Designspezifikationen vergleichen kann, wenn ich die Funktion als abgeschlossen markiere . Ich kann das mit der Auto-Vo-CLI tun und die Ergebnisse in eine Datei oder das Terminal ausgeben. Ein Beispiel dafür haben wir weiter oben im Artikel gesehen:

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

Szenario 2: Testgetriebene Entwicklung

Hier bin ich wieder als Entwickler und baue mein Feature mit einem Blueline-annotierten Design aus. Ich möchte den Inhalt testen, damit ich das Markup anschließend nicht an das Design anpassen muss. Ich kann das tun, indem ich das Auto-Vo-Knotenmodul verwende, das in meinen bevorzugten Test-Runner importiert wird, z. B. 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); });

Unter der Haube

Auto-VO verwendet eine Kombination aus Shell-Scripting und AppleScript, um VoiceOver zu steuern. Beim Stöbern in der VoiceOver-Anwendung bin ich auf eine CLI gestoßen, die das Starten von VoiceOver über die Befehlszeile unterstützt.

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

Anschließend verwaltet eine Reihe von ausführbaren JavaScript-Dateien die AppleScript-Anweisungen zum Navigieren und Erfassen von VoiceOver-Ansagen. Dieses Skript ruft beispielsweise den letzten Satz aus den Screenreader-Ankündigungen ab:

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

Abschließend

Ich würde gerne Ihre Erfahrungen mit auto-vo hören und freue mich über Beiträge auf GitHub. Probieren Sie es aus und lassen Sie mich wissen, wie es läuft!

Mehr nach dem Sprung! Lesen Sie unten weiter ↓