Website mit Screenreader testen: praxisnaher Einstieg

Wie beginnen Sie einen Screenreader-Test?

Kurzantwort: Lernen Sie zuerst die grundlegende Bedienung des Screenreaders und testen Sie anschließend konkrete Aufgaben statt einzelne Elemente wahllos anzuhören. Prüfen Sie Namen, Rollen, Zustände, Reihenfolge und Rückmeldungen. Ein kurzer Test durch Sehende ist wertvoll, ersetzt aber keine Untersuchung durch erfahrene Screenreader-Nutzer:innen.

Auf einen Blick:

• Einstieg Windows: NVDA mit Firefox oder Chrome.
• Einstieg macOS und iOS: VoiceOver mit Safari.
• Immer dokumentieren: Betriebssystem, Screenreader, Browser samt Versionen und die Testschritte.
• Nicht nur Tab: zusätzlich virtuell über Überschriften, Regionen und Formularelemente navigieren.
• Vier Testaufgaben: Seite verstehen, Navigation benutzen, Formular absenden, dynamische Änderungen verfolgen.
• Grenze: ein eigener Kurztest ersetzt keine Tests mit Menschen, die assistive Technologien täglich nutzen.

Welche Screenreader zählen wirklich?

Die Frage entscheidet, womit Sie testen. Belastbare Zahlen liefert die Screen Reader User Survey #10 von WebAIM: erhoben im Dezember 2023 und Januar 2024, 1.539 gültige Antworten, davon 30,7 % aus Europa und 47,2 % aus Nordamerika.

Die wichtigste Zeile fehlt in dieser Tabelle: 91,3 % der Befragten nutzen einen Screenreader auch auf dem Mobilgerät, und 70,6 % davon auf iOS gegenüber 27,6 % auf Android. Was für native Apps zusätzlich gilt, regelt Kapitel 11 der EN 301 549. Wer nur am Desktop prüft, lässt den Kanal aus, den fast alle zusätzlich verwenden.

Vorbehalte, die WebAIM selbst nennt: Die Stichprobe war nicht kontrolliert und ist möglicherweise nicht repräsentativ für alle Screenreader-Nutzenden. Die Erhebung stammt aus dem Winter 2023/24, und die Mehrheit der Antworten kommt aus Nordamerika – für den deutschsprachigen Markt ist sie ein Anhaltspunkt, keine Marktforschung.

Was wir daraus ableiten: JAWS und NVDA liegen praktisch gleichauf und decken zusammen rund vier Fünftel der primären Nutzung ab. NVDA ist kostenlos, JAWS nicht – deshalb ist NVDA der pragmatische Einstieg, ohne dass JAWS damit unwichtig wäre. VoiceOver braucht man ohnehin, sobald mobil geprüft wird.

Woran Nutzende tatsächlich scheitern

Dieselbe Erhebung lässt die Befragten ihre störendsten Barrieren gewichten. In dieser Reihenfolge:

1. CAPTCHAs
2. Interaktive Elemente wie Menüs, Tabs und Dialoge, die sich unerwartet verhalten
3. Links oder Schaltflächen, deren Beschriftung keinen Sinn ergibt
4. Bildschirmbereiche, die sich unerwartet ändern
5. Fehlende Tastaturbedienbarkeit
6. Bilder ohne oder mit unpassender Alternative

WebAIM merkt an, dass sich Reihenfolge und Schweregrad dieser Liste über vierzehn Jahre kaum verändert haben und CAPTCHA mit deutlichem Abstand vorn liegt.

Für Ihren Testplan heißt das: Fangen Sie oben an. Ein Formular mit CAPTCHA und ein selbstgebautes Dropdown sagen mehr über Ihre Barrierefreiheit aus als zwanzig geprüfte Textabsätze.

Die passende Kombination wählen

Screenreader verhalten sich nicht isoliert, sondern in Kombination mit Browser und Betriebssystem. Für einen reproduzierbaren Einstieg eignen sich verbreitete Kombinationen wie NVDA mit Firefox oder Chrome unter Windows und VoiceOver mit Safari auf macOS oder iOS.

Dokumentieren Sie bei einem Befund immer:

• Betriebssystem und Version,
• Screenreader und Version,
• Browser und Version,
• URL und konkrete Testschritte.

Ein Fehler in nur einer Kombination kann trotzdem relevant sein. Prüfen Sie zunächst, ob das verwendete HTML dem Standard entspricht, bevor Sie browserspezifische Umgehungen einbauen.

Nicht mit dem Screenreader „durch die Seite tabben“

Tab erreicht hauptsächlich interaktive Elemente. Screenreader bieten darüber hinaus eine virtuelle Navigation durch Überschriften, Regionen, Links, Formulare und Fließtext. Testen Sie deshalb mindestens zwei Wege:

1. normale Lesereihenfolge durch den Inhalt,
2. gezielte Navigation über Überschriften, Regionen und Formularelemente.

Die genaue Tastenkombination unterscheidet sich je nach Screenreader. Nutzen Sie dessen offizielle Tastaturhilfe und lernen Sie wenige Befehle sicher, statt viele nur oberflächlich einzusetzen.

Vier zentrale Testaufgaben

Seite verstehen

Lassen Sie Seitentitel, erste Überschrift und Regionen ausgeben. Ist erkennbar, worum es geht? Gibt es genau einen sinnvoll benannten Hauptbereich? Überschriftenstufen müssen eine nachvollziehbare Gliederung bilden; sie sind kein Mittel zur Schriftgestaltung.

Navigation benutzen

Öffnen Sie Menüs und folgen Sie mehreren Links. Ein Linkname wie „Mehr erfahren“ kann im Kontext verständlich sein, ist in einer isolierten Linkliste aber oft wenig hilfreich. Aktuelle Navigationseinträge sollten ihren Zustand verständlich vermitteln.

Formular absenden

Navigieren Sie zu jedem Feld und achten Sie auf Name, Typ, Pflichtstatus und Hinweis. Lösen Sie Fehler aus. Werden neue Meldungen angekündigt und sind sie dem richtigen Feld zugeordnet? Der Artikel zu barrierefreien Formularen zeigt die passenden HTML-Muster.

Dynamische Änderungen verfolgen

Bedienen Sie Filter, Akkordeons, Statusmeldungen und Dialoge. Prüfen Sie, ob Zustände wie geöffnet, ausgewählt oder ungültig ausgegeben werden. Eine Live-Region sollte wichtige Änderungen ankündigen, aber nicht jede kleine Aktualisierung unterbrechen.

Semantisches HTML vor ARIA

Problematisch

<div role="heading" aria-level="2">Ergebnisse</div>
<span role="button" tabindex="0">Filter öffnen</span>

Besser

<h2>Ergebnisse</h2>
<button type="button" aria-expanded="false" aria-controls="filters">
  Filter öffnen
</button>

Native Elemente bringen robuste Rollen, Zustände und Tastaturverhalten mit. ARIA kann fehlende Semantik ergänzen, repariert aber keine unpassende Interaktion. Falsch eingesetztes ARIA kann die zugängliche Oberfläche sogar verschlechtern; die Muster dahinter erklärt der Leitfaden zu semantischem HTML und ARIA.

Was ein eigener Kurztest nicht leisten kann

Ein Screenreader ist kein automatisches Prüfwerkzeug, und eine vorgelesene Seite ist nicht automatisch barrierefrei. Erfahrene Nutzer:innen arbeiten schneller, verwenden andere Strategien und stoßen auf Probleme, die Einsteiger übersehen. Außerdem deckt ein Screenreader-Test weder Vergrößerung, Sprachsteuerung, kognitive Anforderungen noch sämtliche Tastaturprobleme ab.

Für wichtige Dienste sollten Tests mit Betroffenen stattfinden, also mit Menschen, die assistive Technologien im Alltag einsetzen. Solche Nutzertests sind fester Bestandteil eines BITV-Tests durch spezialisierte Prüfstellen. Formulieren Sie echte Aufgaben – etwa „Finden Sie den Preis und senden Sie das Kontaktformular ab“ – und beobachten Sie das Ergebnis, ohne die Bedienung vorzugeben.

Kompakte Prüfliste

• Seitentitel und Hauptüberschrift beschreiben die Seite.
• Überschriften und Regionen ermöglichen Orientierung.
• Links und Buttons besitzen verständliche Namen.
• Zustände wie geöffnet, ausgewählt und ungültig werden ausgegeben.
• Formulare vermitteln Label, Hinweise und Fehler.
• Dynamische Änderungen werden angemessen angekündigt.
• Die Lesereihenfolge entspricht der inhaltlichen Reihenfolge.

Die interaktive WCAG-Schnellcheckliste verbindet diesen Test mit Tastatur, Fokus und Zoom. Den Tastatur-Teil vertieft der Leitfaden zu Tastaturbedienung und Fokus.

Häufige Fragen

Welchen Screenreader sollte ich zum Testen verwenden?

Nehmen Sie eine verbreitete Kombination und lernen Sie diese richtig, statt viele oberflächlich zu probieren. Unter Windows ist NVDA mit Firefox oder Chrome ein guter Einstieg, unter macOS und iOS VoiceOver mit Safari. Entscheidend ist, dass Sie Screenreader, Browser und Betriebssystem inklusive Versionen zu jedem Befund dokumentieren, denn das Verhalten entsteht erst aus der Kombination.

Kann ich als sehende Person sinnvoll mit einem Screenreader testen?

Ja, für einen ersten Durchgang. Sie finden damit fehlende Namen, unklare Zustände und kaputte Lesereihenfolgen. Ihr Test ersetzt aber keine Untersuchung durch Menschen, die assistive Technologien täglich nutzen: die arbeiten schneller, verwenden andere Navigationsstrategien und stoßen auf Probleme, die Einsteigern entgehen.

Reicht es, mit Tab durch die Seite zu gehen?

Nein, damit erreichen Sie im Wesentlichen nur interaktive Elemente. Screenreader navigieren zusätzlich virtuell über Überschriften, Regionen, Links und Formularelemente, und genau dort zeigen sich Strukturprobleme. Testen Sie deshalb immer beides: die normale Lesereihenfolge und die gezielte Sprungnavigation.

Ist eine Seite barrierefrei, wenn der Screenreader alles vorliest?

Nein. Dass etwas vorgelesen wird, sagt nichts darüber, ob es verständlich, in sinnvoller Reihenfolge und mit korrekten Rollen und Zuständen ausgegeben wird. Außerdem deckt ein Screenreader-Test weder Vergrößerung noch Sprachsteuerung, kognitive Anforderungen oder alle Tastaturprobleme ab.

Quellen und weiterführende Standards

• WebAIM: Screen Reader User Survey #10: Nutzungsanteile und Rangliste der störendsten Barrieren, erhoben Dezember 2023 bis Januar 2024, n = 1.539.
• W3C WAI: Testing with assistive technologies
• W3C WAI: Page Structure Tutorial
• W3C WAI: Using ARIA

Stand: 12. September 2026.