Nahezu jedes Barrierefreiheitsprogramm, das auditiert wird, meldet dieselbe Zahl: Irgendwo um die neunzig Prozent der Frontend-Entwicklerinnen und -Entwickler geben an, sie „testen mit einem Screenreader“. Bittet man sie darum, dies vorzuführen, ist die Demo meist dieselben drei Tastendrücke — einschalten, durch die Seite tabben, ausschalten. Das ist kein Test. Das ist das Abhaken einer Checkbox.

Der Grund dafür ist strukturell, nicht nachlässig. Ein Screenreader ist kein Werkzeug, das man so aufnimmt wie einen neuen Linter. Es ist ein anderes Interaktionsmodell mit eigenem modalen Zustand, eigener Shortcut-Grammatik und einer Reihe von Konventionen, die erst nach mehreren Stunden echter Arbeit Sinn ergeben. Bis man diese Schwelle überschreitet, sagt das Werkzeug einem fast nichts — und schlimmer: Es sagt einem Dinge, die falsch sind, weil die gehörten Ansagen von Lesermodus, Accessibility Tree des Browsers und IME-Schicht der Plattform abhängen, was von außen nicht offensichtlich ist.

Kompetenz bedeutet für unsere Zwecke den Punkt, an dem man einer Kollegin oder einem Kollegen eine fehlerhafte Komponente geben, deren Tastatur übernehmen und den Fehler mit laufendem Screenreader reproduzieren kann — ohne auf den Bildschirm zu schauen, ohne eine Kurzübersicht zu verwenden und ohne die Ansage schlechter zu machen, als sie im echten Gebrauch wäre. Bekanntheit ist der Punkt, an dem man einen Screenreader gehört hat. Der Abstand zwischen den beiden beträgt ungefähr dreißig bis fünfunddreißig Stunden gezielter Übung.

Der Markt hat drei Screenreader, die für Desktop-Web-Arbeit wichtig sind: NVDA unter Windows, VoiceOver unter macOS und iOS sowie JAWS unter Windows. Jeder hat genügend Nutzende, dass man ihn nicht ignorieren kann, und jeder gibt dasselbe Markup geringfügig anders aus. Eine kompetente Entwicklerin oder ein kompetenter Entwickler kann mindestens zwei davon bedienen.

Die Empfehlung, die sich nach Beobachtung dutzender Entwicklerinnen und Entwickler an der Schwelle zur Kompetenz ergibt, ist eindeutig: mit NVDA unter Windows und VoiceOver unter macOS beginnen. Beide sind kostenlos. Beide sind vorinstalliert (VoiceOver) oder in weniger als fünf Minuten installiert (NVDA). Beide werden von genügend echten Nutzenden verwendet — NVDA hält laut der jüngsten WebAIM-Umfrage ca. 65 % des Windows-Screenreader-Marktanteils, VoiceOver dominiert Mobile und einen bedeutenden Anteil von macOS —, dass das Erlernte unmittelbar auf Fehler übertragbar ist, für die ein Fix veröffentlicht werden kann. JAWS ist das dritte Werkzeug, nicht das erste, auch wenn es nach wie vor den Screenreader mit der größten Enterprise-Installationsbasis darstellt. Drei Gründe.

Die drei Gründe, JAWS anfangs zu überspringen, sind pädagogischer Natur, nicht politischer. Erstens teilen JAWS und NVDA dasselbe Denkmodell — Windows-Browse-Modus versus Fokus-Modus, dasselbe Insert-basierte Befehlspräfix, denselben virtuellen Puffer —, sodass nach dem Erlernen von NVDA neunzig Prozent der tatsächlich benötigten JAWS-Befehle eine Glossar-Suche entfernt sind. Zweitens hat JAWS jahrzehntelange „intelligente“ Inferenz angesammelt: Es versucht, schlechtes Markup zu korrigieren, bevor die Nutzerin oder der Nutzer es hört — was bedeutet, dass ein Fehler, den JAWS überspielt, nach wie vor NVDA-Nutzende erreicht. NVDAs bewusst konservatives Verhalten macht es zum besseren Referenz-Leser, wenn man lernen möchte, was defekt ist. Drittens ist JAWSs Lizenzierungsaufwand — Aktivierung, der vierzig-Minuten-Testmodus, der bei jedem Neustart nervt — eine Lernsteuer, die man sich bis zur Erlangung ausreichender Sicherheit sparen kann.

VoiceOver wird mit NVDA kombiniert statt in Konkurrenz gesetzt, weil die beiden Reader die zwei dominanten Interaktionsmodelle repräsentieren. NVDA (und JAWS) verwenden das „PC-Cursor“-Modell: einen virtuellen Puffer, der die Seite als lineares Dokument aufbaut, und einen separaten Fokus, der der Tab-Reihenfolge folgt. VoiceOver verwendet einen einzigen VoiceOver-Cursor, der über dem Fokus liegt und per Rotor und VO+Pfeiltasten navigiert wird. Eine Entwicklerin oder ein Entwickler, der oder die nur ein Modell beherrscht, schreibt Code, der im eigenen Reader gut und im anderen schlecht angekündigt wird. Beide gleichzeitig zu erlernen ist die einzige zuverlässige Methode, den Unterschied zu spüren.

Das Wochenprogramm hat eine Regel: Den Monitor ausschalten. Nicht gedimmt, nicht minimiert, nicht „Ich schließe die Augen“ — physisch ausschalten oder mit einem Stück Karton abdecken, wenn der Bildschirm der einzige im Raum ist. Es geht darum, die Möglichkeit des Schummelns zu beseitigen. Der Instinkt einer sehenden Entwicklerin oder eines sehenden Entwicklers ist, sobald ein Screenreader etwas Verwirrendes sagt, auf den Bildschirm zu schauen und die Mehrdeutigkeit visuell aufzulösen. Genau dieser Instinkt ist der einzelne wichtigste Grund, warum „Ich habe mit einem Screenreader getestet“ echte Fehler nicht findet.

In Woche eins sollten drei Sitzungen von je ca. neunzig Minuten geplant werden, mit mindestens einem Tag Abstand zwischen den Sitzungen, damit das Muskelgedächtnis Zeit zur Festigung hat. Jede Sitzung hat einen Auftrag. Die erste baut die grundlegende Befehlsgrammatik auf. Die zweite erzwingt eine echte Interaktion. Die dritte prüft die Merkleistung unter einem kleinen Stresspegel.

Die Wochen zwei bis vier sollten insgesamt rund zwanzig Übungsstunden ergeben — zwei neunzigminütige Sitzungen pro Woche plus ein geringes Maß an beiläufiger Nutzung während der regulären Arbeit. Ziel in diesem Abschnitt ist es, die zwei Dinge zu verinnerlichen, die neue Screenreader-Nutzende mehr als alles andere verwirren: die Unterscheidung zwischen Browse-Modus und Fokus-Modus sowie den Unterschied zwischen dem, was der Rotor sieht, und dem, was die Tab-Reihenfolge sieht.

Die mit Abstand häufigste Verwirrung in Woche zwei ist der Moment, in dem eine Entwicklerin oder ein Entwickler in NVDA eine Pfeiltaste drückt, erwartet, dass der virtuelle Puffer sich bewegt, und stattdessen hört, wie das fokussierte Kombinationsfeld seine Optionsliste öffnet. Das ist der Browse-Modus, der automatisch in den Fokus-Modus wechselt, weil der Fokus auf einem Element landet, das NVDA als „Anwendungs“-Widget einstuft. Neue Entwicklerinnen und Entwickler erleben das als Fehlfunktion des Readers. Das ist es nicht — der Reader tut genau das, was die Spezifikation verlangt. Sobald man es zehn- oder fünfzehnmal gehört hat, ist man nicht mehr überrascht; bis dahin sollte man damit rechnen, ungefähr jede zweite Sitzung überrascht zu werden.

Das Woche-drei-Muster sind Formulare. Eine private Testseite mit acht bis zehn Steuerelementen erstellen: ein erforderliches Texteingabefeld mit Inline-Fehlermeldung, ein Datumsauswahl-Feld, ein Mehrfachauswahl-Feld, eine benutzerdefiniert gestaltete Checkbox, ein deaktivierter Button, der aktiviert wird, eine Schaltfläche „Passwort anzeigen“, ein Telefonnummernfeld mit Ländervorwahlauswahl und ein Absenden-Button, der eine serverseitige Validierungszusammenfassung auslöst. Monitor aus, fünfmal hindurch navigieren — zuerst mit NVDA im Browse-Modus, dann NVDA im Fokus-Modus, dann NVDA erneut mit erhöhter Ausführlichkeitseinstellung (Insert+Z, mehr dazu in Abschnitt fünf), dann VoiceOver mit dem Rotor, dann VoiceOver ohne den Rotor. Dasselbe Formular klingt fünfmal unterschiedlich. So fühlt sich Kompetenz von innen an: zu bemerken, dass dasselbe Markup fünf verschiedene Geschichten erzählt, und im Voraus vorhersagen zu können, welche gespielt wird.

Woche vier ist Navigation. Eine echte, komplexe Website nehmen — ein Dokumentationsportal, ein Arbeitsplatz-Dashboard, eine E-Commerce-Kategorieseite — und versuchen, eine bestimmte Information nur mit Screenreader-Shortcuts zu finden. H für Überschriften-Sprünge verwenden. D (NVDA) oder VO+U dann „Landmarks“ (VoiceOver) für Landmark-Sprünge verwenden. 1 bis 6 für Sprünge zu einer bestimmten Überschriftenebene verwenden. Am Ende von Woche vier sollten die Navigations-Shortcuts Reflexe statt Entscheidungen sein — so wie Tab und Umschalt-Tab es bereits sind.

Sobald die Nutzer-Modus-Befehle Reflexe sind, folgt der nächste Schritt in die entwicklerorientierten Oberflächen jedes Readers. Dies sind die Modi und Shortcuts, die die Handbücher vergraben — teils weil sie auf Entwicklerinnen und Entwickler ausgerichtet sind, teils weil sie ausreichend laut sind, dass eine tägliche Nutzerin oder ein täglicher Nutzer sie nicht eingeschaltet lassen würde. Drei sind sofort wissenswert.

Zwei weitere Gewohnheiten sparen mehr Zeit als jeder einzelne Shortcut. Erstens: NVDAs Speech Viewer dauerhaft auf einem zweiten Monitor (oder in einer Ecke des einen Monitors) geöffnet lassen, während entwickelt wird. Das wörtliche Log aller Ankündigungen verhält sich zu Screenreader-Arbeit wie die Dev-Tools-Konsole zu JavaScript: Es ist der Unterschied zwischen Raten und Wissen. Zweitens: Den Accessibility Tree in den Browser-Dev-Tools lesen lernen — Chrome’s Accessibility-Bereich, Firefoxs Accessibility Inspector, Safaris Audit-Reiter. Der Reader kündigt an, was der Accessibility Tree enthält, nicht was das DOM enthält, und die beiden weichen häufig genug voneinander ab, dass Live-Regions, ARIA oder Shadow DOM ohne direkte Tree-Analyse nicht debuggt werden können.

Eine Verwechslung, die jetzt angesprochen werden sollte, weil sie in Wochen zwei und drei Stunden kostet: Lese-Modus versus Fokus-Modus ist nicht dieselbe Achse wie „die Seite ist interaktiv“ versus „die Seite ist ein Dokument“. NVDA wechselt automatisch in den Fokus-Modus, wenn der Fokus auf ein Steuerelement mit role=“application” oder auf ein contenteditable oder auf bestimmte benutzerdefinierte Widgets fällt, die der Reader heuristisch als interaktiv einstuft — unabhängig davon, ob die Seite hauptsächlich statisch ist. Umgekehrt bleibt eine reichhaltig interaktive Single-Page-App, deren Root-Element ein main-Landmark ist und deren Widgets gut mit nativen Buttons ausgezeichnet sind, für nahezu die gesamte Sitzung im Browse-Modus. Der Modus ist eine Eigenschaft des fokussierten Elements, nicht eine Eigenschaft der Seite.

Die folgenden Zahlen stammen aus informellem Tracking von rund achtzig Entwicklerinnen und Entwicklern — Frontend-Ingenieure, QA-Leads, Barrierefreiheitsspezialistinnen und -spezialisten in der Ausbildung — über drei Jahre Unternehmensworkshops und Einzelmentoring. Sie sind keine Forschungsstudie. Sie sind gut genug zum Planen. Zwei Annahmen: gezielte Übung (Monitor aus, echte Aufgaben, nicht „Ich habe NVDA im Hintergrund laufen lassen, während ich programmiert habe“) und eine feste Reader-Kombination (NVDA unter Windows und VoiceOver unter macOS).

„Halbkompetent“ ist das realistische Ziel für die meisten sehenden Entwicklerinnen und Entwickler und in der Praxis alles, was für einen guten Beitrag zu einem barrierefreien Produkt benötigt wird. Echte Kompetenz — das Niveau, auf dem man bei einem Usability-Review vertretungsweise als tägliche Screenreader-Nutzerin oder täglicher Nutzer einspringen könnte — erfordert eher hundertfünfzig Stunden und ein Jahr beiläufiger Übung, und die meisten berufstätigen Entwicklerinnen und Entwickler brauchen das nicht. Das Ziel lautet halbkompetent, die vierzig Stunden sind einzuplanen, und alles darüber hinaus ergibt sich aus der Erledigung des Tagesjobs mit laufendem Reader und der Bereitschaft, sich Zeit zu lassen.

Ein letzter Benchmark, um die Erwartungen ehrlich zu setzen: Die Entwicklerinnen und Entwickler, die unserer Erfahrung nach stagnieren, stagnieren zwischen der zehnten und zwanzigsten Stunde. Die Ursache ist fast immer dieselbe — sie hören auf, den Monitor auszuschalten. Sie reden sich ein, dass sie jetzt „gut genug“ sind, um mit eingeschaltetem Bildschirm, im Hintergrund laufendem Screenreader und visueller Bestätigung immer dann zu testen, wenn die Audiomeldung mehrdeutig ist. Das sind sie nicht. Die sechzehn Stunden zwischen „einsatzbereit“ und „vertraut“ erfordern den ausgeschalteten Monitor, weil das der Abschnitt ist, in dem die Ansagen des Readers zu Informationen statt zu Lärm werden. Ohne diesen Druck fällt das Gehirn auf die visuelle Wahrnehmung zurück und die Stimme des Readers verblasst zur Tapete. Wer merkt, dass man langsamer wird, hat fast immer denselben Grund: den Monitor.

Der Grund, warum „mit einem Screenreader testen“ in der Branche so schwache Ergebnisse liefert, liegt nicht daran, dass das Werkzeug schwer zu erlernen ist — vierzig Stunden sind wirklich keine viel Zeit —, sondern daran, dass das Lernen auf eine bestimmte Art unbequem ist. Den Monitor auszuschalten lässt eine sehende Entwicklerin oder einen sehenden Entwickler auf eine Weise inkompetent wirken, die in unserem Beruf ungewöhnlich ist. Man ist es gewohnt, derjenige oder diejenige zu sein, der oder die Dinge herausfindet; der Screenreader macht einen für einige Stunden am Stück wieder zum Anfänger oder zur Anfängerin. Diese Unbequemlichkeit — nicht die Tastendrücke — ist das eigentliche Hindernis.

Der Weg hindurch ist der oben beschriebene: NVDA und VoiceOver, drei Sitzungen in der ersten Woche mit ausgeschaltetem Monitor, Formulare und Modi in Woche zwei bis vier, Entwickler-Modus-Shortcuts sobald die Nutzer-Modus-Shortcuts Reflexe sind, insgesamt vierzig Stunden bevor man für einen ernsthaften Pre-Release-Sweep eingesetzt werden kann. Nichts davon ist neu. Was die Branche bislang nicht getan hat, ist, es als Arbeit zu behandeln — die Stunden einzuplanen, sie gegen andere Verpflichtungen zu verteidigen und zu akzeptieren, dass die ersten zehn dieser Stunden sich nutzlos anfühlen werden, bis sie es plötzlich nicht mehr tun.

Wer ein Frontend ausliefert: Die Version von Ihnen auf der anderen Seite dieser vierzig Stunden ist eine wesentlich bessere Ingenieurin oder ein wesentlich besserer Ingenieur als die Ausgangsversion — auf Weisen, die sich nicht nur in der Barrierefreiheitsarbeit zeigen, sondern auch im Verständnis von Fokusreihenfolge, von Progressive Enhancement, davon, was der Browser unter der Oberfläche tatsächlich tut. Der Screenreader ist die günstigste verfügbare Lektion über verteilte Systeme für alle, die fürs Web schreiben. Der Preis ist der ausgeschaltete Monitor und ein paar Wochenenden.