Im Jahr 2026 umfasst das Feld fünf wichtige Screenreader — NVDA, JAWS, VoiceOver, TalkBack und Narrator — sowie eine ausgereifte Ebene von Automatisierungstreibern (Playwright AT-driver, AccTree-basierte Inspektoren, Cloud-Aufzeichnungsdienste), die es ermöglicht, einen Teil dieser Arbeit in CI zu verlagern. Keiner davon ersetzt den Einsatz der echten Software gegen das eigene Produkt. Sie ermöglichen es jedoch, offensichtliche Regressionen abzufangen, bevor sie einen menschlichen Tester erreichen.

Dieser Leitfaden behandelt die fünf Screenreader, gegen die getestet werden sollte, eine minimalviable Testmatrix, worauf zu achten ist, die lohnenswerte Automatisierungsebene und eine Einstiegscheckliste für den Release-Prozess.

Fünf Produkte dominieren den Screenreader-Markt im Jahr 2026 — zwei auf dem Windows-Desktop, eines plattformübergreifend bei Apple, eines unter Android und Microsofts integrierter Rückfall. Der ungefähre Marktanteil, das Kostenniveau und die Testtreue jedes einzelnen sind in den Karten unten zusammengefasst; der Text unter jeder Karte ergänzt die Stärken und Besonderheiten.

NVDA — Windows, kostenlos, Open Source. Gepflegt von NV Access. Rund 35–40 % der WebAIM-Umfrageteilnehmer nutzen ihn als primären Screenreader, was ihn zum einzelnen Werkzeug mit dem höchsten Hebel macht. Kostenlos, Open Source, schlanker, lässt sich sauber mit Firefox und Chrome kombinieren. Stärke: strenge ARIA-Unterstützung und ein schneller Entwicklungszyklus. Besonderheit: Die Konfigurationsstandards unterscheiden sich zwischen Versionen; daher sollte die genaue Version und Einstellung, gegen die das Team testet, dokumentiert werden.

JAWS — Windows, kommerziell. Das Flaggschiff von Freedom Scientific. Die Privatlizenz kostet rund 95 $ pro Jahr; Unternehmenslizenzen sind erheblich teurer. Historisch der Enterprise- und US-Bundesbehördenstandard, nach wie vor fest verankert in Behörden, Finanzen und Gesundheitswesen. Stärke: umfangreicher Funktionsumfang und eine lange Kompatibilitäts-Geschichte mit älteren Enterprise-Anwendungen. Besonderheit: Lizenzkosten und die Tendenz, Markup-Fehler zu verbergen, die NVDA aufdeckt.

VoiceOver — macOS und iOS, integriert. Wird mit jedem Apple-Gerät ausgeliefert. Auf Mobilgeräten repräsentiert VoiceOver rund 70 % der weltweiten Screenreader-Nutzenden, was es mit weitem Abstand zum wichtigsten mobilen Testziel macht. Stärke: keine Installation erforderlich, tiefe Betriebssystemintegration, das Gestenmodell ist die de-facto-Konvention für Mobilgeräte. Besonderheit: macOS-VoiceOver und iOS-VoiceOver verhalten sich unterschiedlich; Tests auf einem System decken das andere nicht ab.

TalkBack — Android, integriert. Googles integrierter Android-Screenreader. Die größte mobile Screenreader-Installationsbasis in absoluten Zahlen, obwohl ein beachtlicher Anteil der Android-Nutzenden ihn deaktiviert. Stärke: überall vorinstalliert; lässt sich mit Chrome kombinieren. Besonderheit: Das Verhalten variiert je nach Android-Variante (Samsung One UI, Pixel, MIUI), und die Parität mit VoiceOver ist unvollständig.

Narrator — Windows, integriert. Microsofts mitgelieferter Screenreader. Bei echten Nutzenden ein deutlicher Fünftplatzierter (WebAIM gibt unter 1 % als primäres Werkzeug an), aber er ist in IT-gesperrten Unternehmensumgebungen relevant, in denen NVDA nicht installiert werden kann. Stärke: keine Installation unter Windows erforderlich. Besonderheit: geringere Treue als NVDA oder JAWS; die meisten Nutzenden, die auf einen Screenreader angewiesen sind, haben ihn verlassen.

Die ehrliche Antwort auf „Gegen welche Screenreader sollte getestet werden?“ lautet: gegen so viele, wie das eigene Publikum tatsächlich nutzt, nicht mehr. Die meisten Teams setzen das Budget zu niedrig an und testen am Ende zwei Screenreader schlecht statt einen gut.

Eine Zwei-Zeilen-Baseline (NVDA + Firefox unter Windows, VoiceOver + Safari auf iOS) erfasst die Mehrheit der realen Probleme für ein typisches Verbraucherprodukt. JAWS sollte hinzugefügt werden, sobald eine regulierte Branche ins Spiel kommt. TalkBack sollte ergänzt werden, wenn der Android-Anteil nicht zu vernachlässigen ist. Narrator ist als jährliche Plausibilitätsprüfung zu behandeln, nicht als Gating-Werkzeug. Die gewählte Matrix sollte in die Release-Checkliste aufgenommen werden, damit sie nicht stillschweigend übergangen werden kann.

Über „Wird es vorgelesen?“ hinaus ist der eigentliche Test struktureller Natur. Wenn mit NVDA oder VoiceOver gearbeitet wird, prüft man die Seite auf denselben Achsen wie eine blinde Nutzerin oder ein blinder Nutzer:

• Seitenstruktur — Kündigt der Screenreader Überschriften in einer sinnvollen Hierarchie an? Ist die Navigation per Überschriften-Shortcuts (H-Taste in NVDA, Rotor in VoiceOver) möglich, und landet man an den richtigen Stellen? Funktioniert der Skip-Link — Tab, hören, Enter, Fokus springt in den Hauptinhalt?
• Formular-Labels — Jedes Eingabefeld kündigt einen Namen an. Pflichtfelder kündigen „Pflichtfeld“ an. Feldtypen sind korrekt (E-Mail, Telefon, Zahl). Fehlermeldungen sind über aria-describedby verknüpft und werden bei einem Validierungsfehler angekündigt, statt still oberhalb des Formulars zu erscheinen.
• Dynamische Inhalte — Wenn ein Panel umgeschaltet, ein Formular abgeschickt oder ein Filter angewendet wird: Wird ein aria-live-Bereich aktualisiert? Oder sagt der Screenreader nichts, während sich die sichtbare Oberfläche ändert? Lautlose Aktualisierungen sind der häufigste Fehler bei dynamischen Inhalten.
• Fokusverwaltung — Wenn ein Modal geöffnet wird, springt der Fokus hinein und bleibt dort gefangen? Wenn es geschlossen wird, kehrt der Fokus zum auslösenden Element zurück? Die meisten vorgefertigten barrierefreien Komponentenbibliotheken handhaben dies; hausgemachte Komponenten häufig nicht.
• Lesereihenfolge — Wird der Inhalt in der Reihenfolge gelesen, in der er visuell erscheint? Oder hinterlässt CSS order, absolute Positionierung oder Flex-Umsortierung das DOM in einer anderen Reihenfolge als das visuelle Layout?
• Qualität des Alternativtexts — Ist der Alternativtext tatsächlich nützlich, oder lautet er Image_47.png? Sind dekorative Bilder stumm (alt="")? Beschreibt der Alternativtext, was das Bild im Kontext kommuniziert?
• Linktext — „Hier klicken“ und „Mehr lesen“ klingen außerhalb des Kontexts schrecklich. Screenreader-Nutzende navigieren häufig über eine Liste aller Links; wenn jeder Link „Mehr lesen“ heißt, ist diese Liste nutzlos.

Diese Punkte entsprechen WCAG-2.2-Erfolgskriterien — insbesondere 1.3.1, 2.4.3, 3.3.1 und 4.1.3 —, doch der Test ist schneller und ehrlicher mit laufendem Screenreader als mit einer Checkliste allein.

Automatisierte Screenreader-ähnliche Tests haben sich in den letzten zwei Jahren deutlich verbessert. Sie ersetzen noch immer nicht einen Menschen, der NVDA zuhört, aber sie erfassen einen echten Anteil von Regressionen, bevor sie ausgeliefert werden. Drei Ansätze sind es wert, bekannt zu sein.

Playwright AT-driver und Selenium ChromeDriver „force-text“. Sowohl Playwright als auch Selenium können nun einen Browser steuern und auf Ebene des Barrierefreiheitsbaums prüfen, was angekündigt würde — Name, Rolle, Zustand, Wert. Dies ist stärker als getByRole/getByLabel: Diese Locators lesen den AT-Baum, um ein Element zu finden, aber force-text durchläuft den Baum so, wie es ein Screenreader täte. Es entspricht nicht dem Ausführen von NVDA gegen die eigene Seite, erfasst aber Name-, Rolle- und Zustandsregressionen kostengünstig und deterministisch. Die meisten großen Produktteams haben mittlerweile mindestens eine Smoke-Suite von AT-driver-Tests auf kritischen Seiten — Registrierung, Checkout, Kontoeinstellungen.

AccTree-basierte Inspektoren — axe DevTools, axe Linter, eslint-plugin-jsx-a11y. Statische Analyse von Code und DOM. Erfasst fehlende Labels, ungültiges ARIA, Fehlübereinstimmungen bei Label-Inhalten, Kontrastfehler und strukturelle Probleme. Kostengünstig bei jedem Commit ausführbar. Der kostenlose Barrierefreiheits-Scanner auf dieser Website verwendet dieselbe Regelsammlung. Bodenebene: zeigt an, wenn etwas definitiv kaputt ist, nicht wenn etwas subtil falsch ist.

Live-Screenreader-Aufzeichnung — Assistiv Labs, BrowserStack Accessibility. Cloud-Dienste, die echte NVDA-, JAWS- oder VoiceOver-Sitzungen gegen die eigene URL ausführen und das Ansehen und Anhören ermöglichen, ohne lokale Installation. Am nächsten an „Tests auf dem echten Gerät“ ohne eigene Hardware. Nützlich für Stichproben, für Teams mit dem falschen Betriebssystem und für das Teilen von Aufzeichnungen mit Stakeholdern, die sonst nie hören würden, wie eine fehlerhafte Seite klingt.

Das Muster, auf das sich die meisten Teams bis 2026 eingependelt haben: AccTree-basiertes Linting bei jedem PR, AT-driver-Tests auf einem repräsentativen Seitensatz in CI, echte Screenreader-Tests manuell in Sprint-Takt und ein manuelles Audit durch Tester mit Behinderungen quartalsweise oder jährlich. Die Automatisierungsebene ist der Mindeststandard; die manuelle Ebene ist der Ort, an dem die tatsächliche Nutzungserfahrung gemessen wird.

Diese Checkliste kann in die Release-Checkliste oder das QA-Template eingefügt werden:

NVDA unter Windows. Er ist kostenlos, Open Source, wird von NV Access aktiv gepflegt und wird von rund 35–40 % der WebAIM-Umfrageteilnehmer als primärer Screenreader genutzt. Wer nur ein Hilfstechnologieprodukt zum Testen installiert, sollte NVDA mit Firefox oder Chrome auf einem Windows-Rechner oder einer VM wählen.

Zwei gründlich getestete Screenreader sind besser als fünf schlecht getestete. Das realistische Minimum ist NVDA unter Windows für den Desktop und VoiceOver auf iOS für Mobilgeräte — zusammen decken sie den größten Anteil echter Nutzende ab. JAWS sollte hinzugefügt werden, wenn die Zielgruppe im Behörden-, Finanz- oder Gesundheitsbereich liegt, und TalkBack auf Android, wenn der mobile Datenverkehr schwerpunktmäßig Android-Geräte betrifft.

Nein. Automatisierte Werkzeuge erfassen rund 30–40 % der WCAG-Probleme — fehlende alt-Attribute, ungültiges ARIA, fehlende Labels. Sie können nicht beurteilen, ob Alternativtext nützlich ist, ob dynamische Inhalte tatsächlich angekündigt werden oder ob die Fokusverwaltung sich richtig anfühlt. Automatisierung ist als Mindeststandard zu nutzen, nicht als Obergrenze, und sollte mit regelmäßigen manuellen Tests am echten Screenreader kombiniert werden.

Für lokale Tests ja — VoiceOver läuft nur auf macOS und iOS. Wenn das Team ausschließlich Windows nutzt, bieten Cloud-Dienste wie Assistiv Labs und BrowserStack Accessibility Remote-VoiceOver-Sitzungen gegen die eigene URL an. Für gelegentliche Überprüfungen ist das ausreichend; für ernsthafte iOS-Arbeit empfiehlt sich ein Mac oder ein iPhone.

Beide sind Windows-Screenreader und funktionieren mit allen gängigen Browsern. NVDA ist kostenlos, Open Source, schlanker und tendenziell etwas strenger hinsichtlich ARIA-Konformität. JAWS ist kommerziell (rund 95 $ pro Jahr für eine Privatlizenz), funktionsreicher, hat eine längere Geschichte in Unternehmens- und US-Bundesbehörden-Einsätzen und ist manchmal nachsichtiger gegenüber unvollständigem Markup. Wenn eine Seite in NVDA funktioniert, funktioniert sie in der Regel auch in JAWS — das Umgekehrte gilt nicht immer.

Automatisierungsprüfungen (axe, eslint-plugin-jsx-a11y, AT-driver-Tests) sollten bei jedem Pull Request ausgeführt werden. Manuelle Screenreader-Durchläufe auf wichtigen Nutzungspfaden gehören in die Release-Checkliste — typischerweise jeden Sprint oder jedes Release. Ein vollständiges manuelles Audit durch Tester mit Behinderungen ist je nach Produktveränderungsrate quartalsweise oder jährlich sinnvoll.

Wer noch keinen automatisierten Durchlauf durchgeführt hat, sollte mit dem kostenlosen Barrierefreiheits-Scanner beginnen — er gibt in Sekunden statt Stunden Aufschluss über die offensichtlichen Probleme, die ein Screenreader ebenfalls finden würde. Sobald dieser Mindeststandard gesetzt ist, empfiehlt sich die Planung eines manuellen Audits durch Tester mit Behinderungen für die für das Unternehmen wichtigsten Nutzungspfade. Und wenn Barrierefreiheit ein kontinuierliches Problem statt eines einmaligen Projekts ist, vergleicht der Monitoring-Käuferratgeber die Werkzeuge, die die Produktion zwischen manuellen Audits auf Regressionen überwachen.