Wer Barrierefreiheit nur in einem Screenreader testet, hat ungefähr so gründlich getestet, als hätte er seine Website nur in einem Browser geöffnet. Trotzdem höre ich diese Fehlannahme regelmäßig: „Wir haben das gegen den NVDA Screenreader geprüft, alles sauber.“ Das mag stimmen – und trotzdem kann dieselbe Seite in JAWS oder VoiceOver an Stellen scheitern, die in NVDA reibungslos liefen. Die drei marktführenden Screenreader sind keine austauschbaren Varianten desselben Werkzeugs. Sie unterscheiden sich in Bedienkonzept, Interpretation von ARIA, in der Browser-Bindung und in der Aussprache. In diesem Ratgeber zeige ich Ihnen, wo die Unterschiede konkret liegen und warum Sie gegen mehrere Screenreader testen müssen, wenn das Ergebnis aussagekräftig sein soll.
Die drei wichtigsten Screenreader im Schnellüberblick
Drei Werkzeuge dominieren die globale Screenreader-Landschaft. JAWS (Job Access With Speech) ist der kommerzielle Marktführer aus dem Hause Freedom Scientific, ausschließlich für Windows, seit Jahren der Standard in vielen Behörden und Großunternehmen. NVDA (NonVisual Desktop Access) ist das kostenlose, Open-Source-Pendant von NV Access, ebenfalls Windows, in der weltweiten Nutzergemeinde laut WebAIM-Umfragen am häufigsten verwendet. VoiceOver ist Apples in macOS und iOS integrierter Screenreader – auf iPhones der De-facto-Standard für mobile Webnutzung. Jeder dieser drei hat seine eigene Bedienlogik, seinen eigenen bevorzugten Browser und seine eigene Art, dieselbe Komponente vorzulesen.
Wer welchen Screenreader nutzt
Marktanteile in der Welt der Screenreader sind nie exakt messbar, aber regelmäßige Umfragen wie die WebAIM Screen Reader User Survey zeichnen ein stabiles Bild: NVDA und JAWS liegen auf dem Desktop dicht beieinander, gemeinsam dominieren sie den Windows-Bereich. JAWS hat traditionell die Oberhand in professionellen Umgebungen mit Schulungsstrukturen, NVDA wird häufiger von jüngeren Nutzern, Entwicklern und international gewählt. Auf iOS gibt es dagegen praktisch nur eine Antwort: VoiceOver, weil es vorinstalliert und nicht ersetzbar ist. Auf macOS-Desktops ist die Lage ähnlich. Die Schlussfolgerung für Ihre Test-Strategie: Wer mehrheitlich Windows-Geschäftskunden bedient, muss JAWS und NVDA testen. Wer mobile Verbraucher hat, kommt um VoiceOver auf iOS nicht herum. Wer beides hat, braucht alle drei.
Die wichtigsten Unterschiede in der Praxis
Hier zeigt sich, warum die Annahme „ein Screenreader-Test ist ein Screenreader-Test“ in die Irre führt. Die folgenden Unterschiede begegnen mir in Audits regelmäßig – und sie entscheiden, ob ein Komponententest aussagekräftig ist oder nicht.
Plattform und bevorzugte Browser
Jeder Screenreader hat einen Browser, mit dem er offiziell am besten zusammenarbeitet. JAWS funktioniert mit Chrome, Firefox und Edge – Chrome ist die häufigste Kombination im Unternehmensumfeld. Der NVDA Screenreader läuft am stabilsten mit Firefox und Chromium-basierten Browsern. VoiceOver auf macOS und iOS ist offiziell für Safari ausgelegt und liefert dort das beste Ergebnis. Eine Komponente, die in NVDA mit Firefox einwandfrei funktioniert, kann in VoiceOver mit Safari deutlich anders klingen oder anders bedienbar sein – nicht, weil eine Seite kaputt ist, sondern weil die Kombination eine andere ist.
Tastenkürzel und Navigationskonzepte
Die Bedienkonzepte sind grundverschieden. JAWS arbeitet mit einer Trennung zwischen PC-Cursor und virtuellem Cursor, der NVDA Screenreader unterscheidet zwischen Lese- und Fokus-Modus, VoiceOver setzt auf den sogenannten Rotor – eine Drehauswahl, mit der Nutzer entscheiden, welche Elementsorte sie navigieren wollen. Die Tastenkürzel zum Springen durch Überschriften, Links oder Landmarks sind in jedem Werkzeug anders. Was das praktisch bedeutet: Ein Nutzer, der mit JAWS aufgewachsen ist, bedient eine Seite anders als ein NVDA-Nutzer, der wieder anders bedient als ein VoiceOver-Nutzer. Eine Seite, die für die eine Bedienlogik gut funktioniert, kann für die andere unbequem sein.
Wie ARIA und Live-Regionen interpretiert werden
Der spannendste Bereich für Entwickler. Nicht jeder Screenreader liest jedes ARIA-Attribut gleich. aria-describedby wird bei manchen Komponenten von einem Werkzeug zuverlässig vorgelesen, von einem anderen nur unter bestimmten Bedingungen. Live-Regionen mit aria-live="polite" kündigen Updates in jedem Screenreader leicht unterschiedlich an – manchmal verzögert, manchmal verschluckt, je nach Implementierung und Browser-Pairing. Custom-Widgets, etwa eine Tab-Komponente mit ARIA-Tabs-Pattern, können in JAWS perfekt bedienbar sein und in VoiceOver problematisch wirken. Wer komplexe Komponenten baut, muss in allen drei Werkzeugen prüfen, ob die Bedienung wirklich klappt. Welche ARIA-Anti-Patterns dabei am häufigsten zuschlagen, habe ich in ARIA-Label richtig einsetzen: Der Praxis-Guide für Entwickler beschrieben.
Mobile gegen Desktop: die VoiceOver-Sonderrolle
VoiceOver auf iOS unterscheidet sich nicht nur von JAWS und NVDA, sondern auch von VoiceOver auf macOS. Die Bedienung erfolgt nicht über eine Tastatur, sondern über Touch-Gesten – ein Wischen nach rechts geht zum nächsten Element, ein Doppeltippen aktiviert. Diese ganz andere Eingabelogik bedeutet, dass eine Seite, die mit Tastatur perfekt navigierbar ist, auf dem iPhone trotzdem hakeln kann – etwa wenn fokussierbare Elemente zu dicht beieinanderliegen oder dynamische Updates auf dem kleinen Bildschirm den Fokus verlieren. Wer mobile Nutzer hat, kommt um einen Test direkt auf dem iPhone nicht herum.
Sprachausgabe und Aussprache
Auch unterhalb der Bedienlogik gibt es Unterschiede. Die TTS-Engines variieren: JAWS nutzt häufig Vocalizer- oder Eloquence-Stimmen, NVDA verwendet standardmäßig eSpeak NG und unterstützt Windows-System-Stimmen, VoiceOver verwendet Apples eigene Stimmen. Sie sprechen Wörter anders aus, machen unterschiedliche Pausen, betonen Zeichensetzung unterschiedlich. Auch Inline-Auszeichnungen werden uneinheitlich behandelt – manche Screenreader kündigen <strong> oder <em> explizit an, andere ignorieren die visuelle Hervorhebung komplett. Was beim einen wie ein wichtiger Hinweis klingt, geht beim anderen unter.
Warum Sie gegen mehrere Screenreader testen müssen
Diese Unterschiede sind keine Bug-Reports an die Hersteller. Sie sind die Realität des Marktes – jeder Screenreader hat seine Tradition, seine Stärken, seine Nutzergruppe. Wer nur gegen einen testet, deckt deshalb nicht „alle Screenreader-Nutzer“ ab, sondern eine spezifische Teilgruppe. Auf Windows finden Sie eine Komponente, die in NVDA bedienbar ist, in JAWS aber an einer falschen Fokus-Reihenfolge scheitert. Auf iOS klappt etwas, das auf dem Desktop bestens funktionierte, plötzlich nicht mehr, weil Touch-Gesten die Spielregeln ändern. Und im Mehrfach-Test fallen Inkonsistenzen auf, die in der einzelnen Prüfung verborgen blieben.
Die Konsequenz für Audits: Eine ehrliche Aussage zur Barrierefreiheit braucht den Test gegen die wichtigsten Screenreader-Browser-Pärchen. Eine Aussage „getestet mit Screenreader X“ hilft Nutzern von Screenreader Y nicht weiter. Und sie schützt Sie auch nicht im Verfahren, wenn die Beschwerde eines JAWS-Nutzers kommt, während Sie nur gegen NVDA geprüft haben.
Die empfohlene Mindest-Test-Matrix
| Kombination | Wann verwenden |
|---|---|
| JAWS + Chrome (Windows) | Wenn Sie professionelle, häufig Windows-basierte B2B-Nutzer haben |
| NVDA + Firefox (Windows) | Für die größte aktive Screenreader-Nutzergemeinde, internationale Nutzer |
| VoiceOver + Safari (macOS) | Wenn Ihre Zielgruppe Apple-Geräte am Desktop nutzt |
| VoiceOver + Safari (iOS) | Für jeden, der mobile Endkunden bedient – Pflicht für E-Commerce |
| TalkBack + Chrome (Android) | Bei relevantem Android-Anteil im mobilen Traffic |
Für die meisten Websites im DACH-Raum ist die Kombination aus NVDA mit Firefox, JAWS mit Chrome und VoiceOver mit Safari (auf macOS und iOS) der pragmatische Mindeststandard. Wer alle drei abdeckt, hat in der Praxis 90 Prozent der realen Nutzungssituationen geprüft.
Was Sie als Entwickler selbst tun können
Sie müssen kein zertifizierter AT-Nutzer sein, um ein Grundverständnis zu entwickeln. Installieren Sie NVDA – das ist kostenlos und in zehn Minuten eingerichtet. Aktivieren Sie auf einem Mac VoiceOver mit Command+F5, auf dem iPhone die Bedienungshilfen in den Einstellungen. Dann tabben Sie eine halbe Stunde durch Ihre eigene Anwendung, mit geschlossenen Augen oder weggedrehtem Bildschirm. Sie werden Dinge hören, die Sie nie bemerkt hätten, und ein Gespür dafür entwickeln, wo Ihre Bauten gut sitzen und wo sie hakeln. Das ersetzt keinen professionellen Test, aber es macht Sie zum deutlich besseren Entwickler. Eine Grundlage, was ein Screenreader überhaupt ist und wie er Inhalte verarbeitet, finden Sie in Was ist ein Screenreader? Funktion, Bedeutung und Auswirkung auf Ihre Website.
Wenn Sie nicht selbst testen wollen
Die ehrliche Antwort, warum die meisten Unternehmen das nicht selbst dauerhaft leisten: Es ist aufwendig, mit allen drei Werkzeugen routiniert zu sein. Dazu braucht es Jahre der Übung – und selbst dann bedient ein gelegentlicher Tester einen Screenreader nicht wie ein täglicher Nutzer. Genau hier setzt unser Tiefen-Audit Access Ready an. Wir prüfen Ihre Website mit echten Nutzern assistiver Technologien, die JAWS, den NVDA Screenreader und VoiceOver täglich verwenden, und dokumentieren das Erlebnis in allen relevanten Kombinationen. Sie bekommen damit nicht den Eindruck eines Sehenden, der einen Screenreader bedient, sondern die Wahrnehmung der Menschen, für die das Werkzeug seit Jahren der Alltag ist. Welche Grenzen ein rein automatischer Test hier hat und warum er nie alles findet, lesen Sie in Warum automatische Tests nur einen Teil finden: Die Grenzen von KI-Scannern.
