Tests & Tools

Screenreader im Überblick: NVDA, JAWS und VoiceOver

Ein Screenreader wandelt Bildschirminhalte in synthetisierte Sprache oder Braille-Ausgabe um und ermöglicht es blinden und sehbehinderten Nutzern, eine Seite zu navigieren und zu verstehen, ohne sie visuell zu sehen. Die drei am weitesten verbreiteten Screenreader verhalten sich unterschiedlich genug – bei Tastaturkürzeln, bei der Interpretation von ARIA, bei Standardeinstellungen –, dass manuelle Barrierefreiheitstests idealerweise mehr als nur einen abdecken.

NVDA (NonVisual Desktop Access)

Kostenlos und quelloffen, nur für Windows, und der am weitesten verbreitete Screenreader sowohl für echte Nutzer als auch speziell für Barrierefreiheitstests – sein kostenloser Preis und die aktive Weiterentwicklung machen ihn zu einer natürlichen Standardwahl für Teams, die eigene manuelle Tests durchführen. Wird meist mit Firefox oder Chrome unter Windows kombiniert.

JAWS (Job Access With Speech)

Ein kommerzieller, kostenpflichtiger Screenreader für Windows, historisch Marktführer in Unternehmens- und Behördenkontexten, mit langer Erfolgsbilanz und umfangreichem Funktionsumfang. Da er kommerziell ist und eine kostenpflichtige Lizenz erfordert, wird er seltener für beiläufige oder Ad-hoc-Tests verwendet als NVDA, bleibt aber wichtig, speziell für Produkte zu testen, die Unternehmens-, Behörden- oder andere stark JAWS-nutzende Zielgruppen bedienen.

VoiceOver

Apples integrierter Screenreader, kostenlos auf macOS und iOS enthalten – der Standard- (und für viele Nutzer der einzige) Screenreader im Apple-Ökosystem. Tests mit VoiceOver sind besonders wichtig für jedes Produkt mit nennenswerter iOS-/Safari-Nutzung, da sich das Interaktionsmodell von VoiceOver (insbesondere seine Touch-Gesten auf iOS) erheblich vom desktop-tastaturgesteuerten Modell von NVDA und JAWS unterscheidet.

Warum Testen mit nur einem Screenreader nicht ausreicht

Jeder Screenreader hat seine eigenen Besonderheiten bei der Interpretation von ARIA-Attributen, der Ansage dynamischer Inhaltsänderungen (wie Live-Regionen) und dem Umgang mit Randfällen in benutzerdefinierten Widgets – eine Komponente, die in NVDA einwandfrei funktioniert, kann sich in VoiceOver anders verhalten oder sogar nicht funktionieren, und umgekehrt. Dies ist ein wesentlicher Grund, warum WCAG-Konformität nicht allein durch automatisiertes Scannen vollständig verifiziert werden kann: Ein Scanner prüft die Markup-Korrektheit gegen die Spezifikation, aber echtes Screenreader-Verhalten weicht manchmal auf Weisen von der Spezifikation ab, die nur tatsächliche manuelle Tests aufdecken.

Ein praktischer Mindest-Testansatz

Für die meisten Teams ohne dedizierte Barrierefreiheitsspezialisten ist eine vernünftige Grundlage: primäre Nutzerabläufe in NVDA + Chrome oder Firefox testen (deckt die häufigste kostenlose/Windows-Kombination ab) und in VoiceOver + Safari, wenn das Produkt nennenswerte Mac-/iOS-Nutzung hat. Dies ist keine erschöpfende Screenreader-Abdeckung, erfasst aber die Mehrheit der realen, screenreader-spezifischen Probleme, die automatisiertes Scannen und reine Tastaturtests allein übersehen würden.

Häufige Fragen

Was ist ein Screenreader?

Software, die Bildschirminhalte in synthetische Sprache oder Braille umwandelt und blinden sowie sehbehinderten Menschen ermöglicht, eine Seite ohne visuelle Wahrnehmung zu nutzen.

Mit welchen Screenreadern sollte man testen?

NVDA (kostenlos, quelloffen, Windows – am gebräuchlichsten für Tests), JAWS (kommerzieller Marktführer in Behörden und Konzernen) und VoiceOver (in macOS und iOS integriert).

Warum mit mehr als einem Screenreader testen?

Jeder interpretiert ARIA, dynamische Inhalte und eigene Widgets anders. Eine Komponente, die in NVDA funktioniert, kann in VoiceOver scheitern – ein einzelner Test übersieht also reale Probleme.