Screenreader-Grundlagen

Ein Screenreader liest nicht den Bildschirm, sondern den Accessibility Tree – eine Datenstruktur, die der Browser parallel zum sichtbaren Layout aus deinem HTML ableitet und über eine Schnittstelle des Betriebssystems bereitstellt. Was dort nicht ankommt, kann kein Screenreader ansagen, egal wie deutlich es auf dem Bildschirm zu sehen ist.

Das Wichtigste in Kürze

• Die Kette lautet: HTML → DOM → Accessibility Tree → Plattform-Schnittstelle → Screenreader → Sprache oder Braille. CSS hat auf diesem Weg keine Haltestelle.
• Jedes Element trägt drei Angaben: Name, Rolle und Zustand. Aus ihnen entsteht die Ansage „Nachricht senden, Schalter, nicht verfügbar“.
• Nutzer lesen nicht von oben nach unten, sondern springen: zur nächsten Überschrift, zur nächsten Landmarke, durch die Liste aller Links. Diese Sprungziele liefert dein Markup – oder eben nicht.
• Zwei Modi: Im Lesemodus gehen Tastendrücke an den Screenreader (Schnelltasten wie H oder D), im Formularmodus ins Eingabefeld. NVDA und JAWS schalten automatisch um.
• Unsichtbar ist nicht gleich unsichtbar. display: none entfernt ein Element aus dem Baum, opacity: 0 und Off-Screen-Positionierung nicht. aria-hidden="true" entfernt es aus dem Baum, lässt es aber sichtbar und fokussierbar – eine der gefährlichsten Kombinationen überhaupt.
• Ein Screenreader ist kein Prüfwerkzeug. Er liest auch kaputte Seiten vor. Die Testfrage lautet nie „wird etwas vorgelesen?“, sondern „komme ich damit ans Ziel?“.
• Ein Screenreader-Test deckt etwa ein Dutzend Erfolgskriterien ab – Kontraste, Reflow und sichtbaren Fokus findet er nicht.

Abgrenzung – diese Seite erklärt die Technik. Hier geht es um den Mechanismus: Accessibility Tree, Lese- und Formularmodus, was eine Ansage überhaupt auslöst. Welche Programme es gibt und welches du installieren solltest, steht in der Übersicht Screenreader: NVDA, JAWS & VoiceOver. Das Nutzungsverhalten mit Zahlen steht unter Wie Screenreader-Nutzer surfen.

Was ein Screenreader tatsächlich ausliest

Der Irrtum steckt schon im Namen. Ein Screenreader liest keinen Screen. Er fragt Betriebssystem und Browser nach einer Datenstruktur ab, die parallel zum sichtbaren Layout entsteht: dem Accessibility Tree. Der ist eine gefilterte Fassung des DOM – er enthält nur, was für Hilfsmittel relevant ist, und zu jedem Eintrag drei Angaben:

Daraus folgt die Regel, die den größten Teil aller Screenreader-Probleme erklärt: Optik erzeugt keine Semantik. Ein <div>, das per CSS wie ein Button aussieht, ist im Accessibility Tree ein Textknoten – ohne Rolle, ohne Tastaturfokus, ohne Ansage.

<!-- Falsch: NVDA sagt nur „Nachricht senden“ – ohne Rolle, ohne Tastaturzugang -->
<div class="btn" onclick="sendForm()">Nachricht senden</div>

<!-- Richtig: „Nachricht senden, Schalter“ – ohne eine Zeile JavaScript -->
<button type="submit">Nachricht senden</button>

Wie der Name eines Elements zustande kommt, regelt 4.1.2 Name, Rolle, Wert – das Kriterium, an dem in Audits die meisten selbstgebauten Bedienelemente scheitern.

Was im Baum landet – und was nicht

Die Unterschiede gehen beim Debuggen ständig durcheinander, deshalb hier nebeneinander, was die gängigen Techniken tatsächlich bewirken:

Die vorletzte Zeile ist die gefährliche. aria-hidden="true" an einem Container, der fokussierbare Elemente enthält, erzeugt genau den Zustand, den kein Nutzer auflösen kann: Der Fokus landet auf einem Element, das der Screenreader nicht kennt – er sagt nichts, und die Person weiß nicht, wo sie ist. In der Browser-Konsole lässt sich das prüfen:

// Alle fokussierbaren Elemente in aria-hidden-Bereichen finden
document.querySelectorAll('[aria-hidden="true"] a, [aria-hidden="true"] button, ' +
  '[aria-hidden="true"] input, [aria-hidden="true"] [tabindex]')

Kommt dort etwas zurück, ist das ein Befund gegen 4.1.2 und meist auch gegen 2.4.3 Fokus-Reihenfolge.

Wie eine Seite erfasst wird

Der zweite verbreitete Irrtum: dass alles stur von oben nach unten vorgelesen wird. In Wirklichkeit navigieren die Nutzenden – und zwar über die Struktur, die dein Markup vorgibt:

• nach Überschriften springen; die Überschriften-Hierarchie wird zum Inhaltsverzeichnis
• zu Landmarks wie <nav>, <main>, <footer> springen (siehe Landmarks & Outline)
• sich alle Links oder Formularfelder als Liste ausgeben lassen
• Element für Element durchgehen

Im Umkehrschluss: Ohne sinnvolle Überschriften, ohne Landmarks, ohne verknüpfte Labels fehlen genau die Sprungmarken, von denen diese Navigation lebt. Eine „Div-Suppe“ ist für einen Screenreader eine glatte, orientierungslose Fläche. Wie sich das im Alltag anfühlt, beschreibt Wie Screenreader-Nutzer surfen.

Lese- und Formularmodus

Das Detail, das beim ersten eigenen Test am meisten verwirrt: Screenreader kennen unter Windows zwei Betriebsarten.

Im Lesemodus (Browse Mode) blättert man frei durch die Inhalte; Schnelltasten wie H, K und D gehen an den Screenreader. Sobald der Fokus in ein Eingabefeld kommt, schaltet er in den Formularmodus (Focus Mode), in dem Tastendrücke ins Feld gehen – sonst könnte man kein Wort mit einem h tippen.

Der Wechsel passiert bei NVDA und JAWS automatisch, ausgelöst durch die Rolle des fokussierten Elements. Genau deshalb funktionieren selbstgebaute Widgets hier nicht: Wer eine Auswahlliste als <div> mit Klick-Handler baut, bekommt keinen Moduswechsel – die Pfeiltasten scrollen weiter das Dokument, und die Liste wirkt kaputt. Die richtige Auszeichnung steht unter Rollen, States & Properties.

VoiceOver kennt diese Trennung so nicht. Am Mac und am iPhone steuert stattdessen eine Interaktionsebene, was Tastendrücke und Gesten bewirken – ein Unterschied, der beim Vergleich beider Programme regelmäßig für Verwirrung sorgt.

Sprache ist nur die eine Hälfte

„Screenreader“ klingt nach Stimme, aber ein erheblicher Teil der Nutzung ist lautlos. Laut dem WebAIM-Screenreader-Survey lassen sich rund 38 % der Befragten die Ausgabe zusätzlich über eine Braillezeile geben – also über eine Zeile aus Stiftmustern, die denselben Accessibility Tree in tastbare Zeichen übersetzt.

Für die eigene Arbeit ändert das an den Anforderungen nichts, aber es verschiebt zwei Bewertungen:

Reihenfolge zählt mehr als Betonung. Eine Braillezeile zeigt typischerweise 40 Zeichen auf einmal – ungefähr eine halbe Zeile Text. Wer sich so durch eine Seite arbeitet, liest in sehr kleinen Ausschnitten. Ein Bedienelement, dessen Name erst drei Ausschnitte später kommt, ist praktisch nicht auffindbar. Deshalb ist 2.5.3 Beschriftung im Namen kein Randthema.

Klangliche Tricks funktionieren nicht. Was über Tonhöhe, Pause oder Sprechtempo transportiert würde, fällt taktil ersatzlos weg. Bedeutung muss deshalb in der Struktur stecken – in Rolle, Zustand und Beziehung –, nicht in der Art der Ansage. Wie das technisch funktioniert, beschreibt die Seite zur Braillezeile.

Was ein Screenreader-Test belegen kann

Das ist der Punkt, den ich in Projekten am häufigsten klarstellen muss, meist erst, nachdem jemand ein grünes Prüfergebnis vorgelegt hat. Ich sag’s daher gleich hier: Ein Screenreader-Durchlauf ist eine starke Stichprobe – aber er deckt einen klar umrissenen Ausschnitt der WCAG ab:

Die rechte Spalte ist der Grund, warum ein Screenreader-Test nie allein steht. Wo er in den Gesamtablauf gehört, steht unter Barrierefreiheit selbst testen.

Die fünf Anleitungen im Einzelnen

Welches Programm du nimmst, hängt vom vorhandenen Gerät ab – die Prüffragen sind überall dieselben, nur die Griffe unterscheiden sich:

• Mit NVDA testen – Windows, kostenlos, der Einstieg, den ich jedem Team empfehle
• Mit JAWS testen – Windows, kostenpflichtig, aber mit 40-Minuten-Demomodus testbar; der Standard in Behörden und großen Unternehmen
• Mit VoiceOver am Mac testen – vorinstalliert, Tastenbefehle und Rotor
• Mit VoiceOver auf iPhone und iPad testen – Gestenbedienung; deckt Zielgröße, Gesten und Ausrichtung ab
• Mit TalkBack testen – Android, die andere Hälfte des mobilen Marktes

Wer nur eines schafft: NVDA am Desktop, VoiceOver oder TalkBack mobil. Wer zwei schafft, nimmt eines pro Plattform – dieselbe Seite verhält sich unter Windows und iOS unterschiedlich genug, dass sich der zweite Durchlauf lohnt.

Stichprobe, nicht Stellvertretung. Ein eigener Test deckt viel auf, macht dich aber nicht zur erfahrenen Nutzerin. Für belastbare Aussagen sind Tests mit Menschen, die täglich damit arbeiten, durch nichts zu ersetzen.

Häufiger Fehler in der Praxis

„Es wird ja vorgelesen.“ Ein Screenreader interpretiert, er warnt nicht. Er liest auch eine Seite vor, deren Bedienelemente unerreichbar sind. Die Prüffrage muss aufgabenbezogen sein: „Bestelle dieses Produkt“, nicht „klingt das okay?“.

Mit Blick auf den Bildschirm testen. Solange das Auge mitliest, ergänzt es alles, was die Ansage nicht liefert. Bildschirm ausschalten oder den Bildschirmvorhang nutzen.

aria-label an generischen Elementen. Ein aria-label braucht eine Rolle, an der es hängen kann. An einem <div> ohne role wird es je nach Programm ignoriert – das ist kein Bug, sondern die Spezifikation.

Icon-Fonts ohne aria-hidden. Zeichen aus ::before landen im Baum und werden als Buchstabensalat vorgelesen. Deko-Icons brauchen aria-hidden="true", informative brauchen einen Textnamen.

Nur mit einem Browser testen. Der Accessibility Tree wird vom Browser gebaut. Ein Befund gehört deshalb immer mit Paarangabe gemeldet: „NVDA 2024.4 + Firefox 133“, nicht „der Screenreader sagt“.

Häufige Fragen

Muss ich mehrere Screenreader testen?

Für den Anfang nicht. Ein kostenloser – NVDA unter Windows oder VoiceOver auf Apple-Geräten – findet die meisten Probleme. Unterschiede zwischen den Programmen sind eher etwas für tiefere Audits; welche Programme wie verbreitet sind, ordnet der Screenreader-Überblick ein.

Ich finde die Bedienung verwirrend – mache ich etwas falsch?

Wahrscheinlich nicht. Screenreader haben eine Lernkurve, und die ersten Minuten fühlen sich für Sehende immer ungewohnt an. Meistens steckt der Moduswechsel dahinter: Die Taste H springt im Lesemodus zur nächsten Überschrift und schreibt im Formularmodus ein h ins Feld.

Kann ich den Accessibility Tree direkt ansehen?

Ja, und das ist oft schneller als der Screenreader selbst. Die Entwicklerwerkzeuge von Chrome und Firefox haben einen Reiter „Barrierefreiheit“, der Name, Rolle und Zustand jedes Elements zeigt – inklusive der Rangfolge, aus der der Name berechnet wurde.

Worin unterscheiden sich DOM und Accessibility Tree?

Der Accessibility Tree ist eine gefilterte, angereicherte Fassung des DOM. Gefiltert, weil rein visuelle Container ohne Rolle darin gar nicht erst auftauchen. Angereichert, weil der Browser Name, Rolle und Zustand erst berechnet – aus Elementtyp, Attributen, verknüpften Labels und ARIA. Zwei Seiten mit identischem DOM können deshalb völlig verschiedene Bäume haben.

Was hilft der Screenreader-Nutzung am meisten?

Sauberes, semantisches HTML: echte Überschriften, Landmarks, Listen, verknüpfte Labels, echte Buttons. Fast alles, was diese Website behandelt, zahlt darauf ein – und die Mühe wird hier unmittelbar hörbar.

Verwandte Themen

• Screenreader im Überblick – welche Programme es gibt und wie verbreitet sie sind
• Wie Screenreader-Nutzer surfen – die Navigationsstrategien dahinter
• Mit NVDA testen, JAWS, VoiceOver am Mac, VoiceOver mobil und TalkBack – die fünf Anleitungen
• Landmarks & Outline – das Gerüst, das die Sprungtasten überhaupt erst füllt
• Erste Regel von ARIA – warum natives HTML im Baum am zuverlässigsten ankommt
• Barrierefreiheit selbst testen – die Reihenfolge aller Prüfschritte

Quellen

• Accessible Name and Description Computation (W3C – Rangfolge bei der Ermittlung des Namens)
• How People with Disabilities Use the Web: Tools and Techniques (W3C WAI)
• Accessibility Tree (MDN – Aufbau und Filterung gegenüber dem DOM)
• NVDA User Guide (NV Access – Lese- und Fokusmodus, Schnelltasten)
• Screen Reader User Survey #10 (WebAIM – 38 % nutzen zusätzlich eine Braillezeile)