Damit ein blinder Mensch eine Website nutzen kann, muss sein Screenreader auf die Inhalte zugreifen können – und wie dieser Zugriff technisch funktioniert, verstehen die wenigsten, die Websites bauen. Genau daraus entstehen die meisten Barrieren: nicht aus bösem Willen, sondern aus einem Missverständnis darüber, womit ein Screenreader eigentlich arbeitet. In meinen Audits sehe ich immer wieder Oberflächen, die für sehende Augen perfekt funktionieren und für einen Screenreader praktisch nicht existieren. In diesem Leitfaden erkläre ich Ihnen, wie der Screenreader-Zugriff abläuft, was ein Screenreader vorliest, wie blinde Nutzer wirklich navigieren – und was Sie konkret bereitstellen müssen, damit der Zugriff gelingt. Am Ende werden Sie verstehen, warum eine Seite, die perfekt aussieht, für einen blinden Menschen trotzdem eine verschlossene Tür sein kann – und wie Sie sie öffnen.

Wie funktioniert der Screenreader-Zugriff?

Ein Screenreader greift nicht auf das sichtbare Bild Ihrer Website zu, sondern auf eine technische Repräsentation dahinter. Der Browser erzeugt aus Ihrem Code eine strukturierte Beschreibung der Seite und stellt sie über eine Schnittstelle des Betriebssystems bereit, die Accessibility API. Genau diese Beschreibung liest der Screenreader aus und gibt sie als Sprache oder über eine Braillezeile aus. Das sichtbare Layout und die technische Beschreibung sind also zwei getrennte Dinge, die nur dann zusammenpassen, wenn man es bewusst sicherstellt.

Das hat eine entscheidende Konsequenz: Für den Screenreader existiert nur, was in dieser technischen Beschreibung steht. Ein Element, das visuell wie ein Button aussieht, aber im Code keine Button-Bedeutung trägt, ist für den Screenreader kein Button – im Zweifel gar nichts. Der Screenreader-Zugriff hängt also nicht davon ab, wie etwas aussieht, sondern davon, wie es im Code ausgezeichnet ist. Diese eine Erkenntnis erklärt schon die Hälfte aller Barrieren, die mir in Audits begegnen.

Der Accessibility Tree: die Brücke zwischen Code und Screenreader

Diese technische Beschreibung trägt einen Namen: den Accessibility Tree, also den Barrierefreiheitsbaum. Der Browser erzeugt ihn aus dem DOM – der Struktur Ihrer Seite – angereichert um zusätzliche Informationen aus ARIA-Attributen. Der Baum enthält für jedes relevante Element seine Bedeutung und seine Eigenschaften, gewissermaßen die für assistive Technologien lesbare Essenz Ihrer Seite. Man kann ihn sich als eine zweite, unsichtbare Version Ihrer Website vorstellen – die Version, mit der assistive Technologien tatsächlich arbeiten.

Was nicht im Accessibility Tree landet, bleibt dem Screenreader verborgen. Deshalb ist es so wichtig zu verstehen, dass dieser Baum kein Zufallsprodukt ist, sondern direkt aus Ihrem Code entsteht. Sie können ihn übrigens in den Entwicklerwerkzeugen moderner Browser einsehen und so genau prüfen, was ein Screenreader an einer bestimmten Stelle überhaupt vorfindet. Tiefer in die technische Umsetzung führt unser Ratgeber zur barrierefreien Webentwicklung. Was im Baum fehlt, fehlt auch dem Nutzer.

Name, Rolle, Wert: was der Screenreader vorliest

Wenn ein Screenreader ein Element erreicht, gibt er im Kern drei Dinge aus: seinen Namen, seine Rolle und gegebenenfalls seinen Zustand oder Wert. Das WCAG-Erfolgskriterium 4.1.2 „Name, Rolle, Wert“ macht genau diese drei Informationen zur Pflicht. Bei einem Kontrollkästchen etwa hört der Nutzer den Namen („Newsletter abonnieren“), die Rolle („Kontrollkästchen“) und den Zustand („nicht aktiviert“). Erst diese drei Angaben zusammen ergeben ein Element, das ein blinder Mensch verstehen und bedienen kann. Fällt eine davon weg, bleibt ein Rätsel zurück.

Fehlt eine dieser Informationen, wird der Zugriff lückenhaft. Ein Button ohne zugänglichen Namen wird als „Schaltfläche“ angesagt, ohne dass der Nutzer erfährt, was sie tut. Ein selbstgebautes Bedienelement ohne hinterlegte Rolle ergibt für den Screenreader keinen Sinn. Genau hier entscheidet sich der Screenreader-Zugriff im Detail: an der Frage, ob jedes Element seinen Namen, seine Rolle und seinen Zustand verständlich preisgibt. Was hier fehlt, lässt sich später nur mühsam reparieren – deshalb lohnt es sich, von Anfang an darauf zu achten.

Aus der Praxis: Ein Kunde hatte seine Schaltflächen aus gestylten div-Elementen mit einem Klick-Handler gebaut – optisch tadellose Buttons. Im Screenreader-Test war das Ergebnis ernüchternd: kein Name, keine Rolle. Der Screenreader meldete an diesen Stellen schlicht nichts Brauchbares, die zentralen Aktionen der Seite waren für einen blinden Nutzer unsichtbar. Ein echtes button-Element hätte Name und Rolle automatisch mitgeliefert. Die schönste Optik nützt nichts, wenn der Accessibility Tree leer bleibt.

Der Screenreader-Zugriff auf Bilder und Tabellen

Zwei Inhaltstypen verdienen beim Screenreader-Zugriff besondere Beachtung. Bilder sind für einen Screenreader zunächst stumm – erst ein Alternativtext (WCAG-Kriterium 1.1.1) macht ihren Inhalt zugänglich. Dabei gilt: Ein rein dekoratives Bild sollte als solches markiert und übersprungen werden, ein informatives Bild dagegen braucht eine Beschreibung, die seine Aussage transportiert, statt bloß „Bild“ zu melden. Der Unterschied zwischen dekorativ und informativ ist dabei eine inhaltliche Entscheidung, keine technische.

Tabellen sind der zweite Stolperstein. Ein Screenreader liest sie zellenweise und ist darauf angewiesen, dass Kopfzeilen korrekt ausgezeichnet sind – Teil der strukturellen Anforderung aus Kriterium 1.3.1. Nur dann kann er bei jeder Zelle die zugehörige Spalten- und Zeilenüberschrift mit ansagen – etwa „Umsatz, drittes Quartal, 12.000 Euro“. Fehlt diese Auszeichnung, hört der Nutzer eine zusammenhanglose Zahlenkette. Werden Tabellen gar nur zu Layoutzwecken missbraucht, gerät der Screenreader-Zugriff vollends durcheinander. Komplexe Datentabellen gehören deshalb zu den anspruchsvollsten Elementen für den Zugriff überhaupt.

Browse-Modus und Fokus-Modus: die zwei Betriebsarten

Ein Konzept, das fast niemand außerhalb der Szene kennt, ist für den Screenreader-Zugriff zentral: Gängige Screenreader für Windows wie NVDA und JAWS arbeiten in zwei Modi. Im Lese- oder Browse-Modus bewegt sich der Nutzer mit den Pfeiltasten frei durch den Seiteninhalt und nutzt Schnellnavigation, ähnlich wie man einen Text liest. Dazu legt der Screenreader eine eigene, lineare Repräsentation der Seite an – einen virtuellen Puffer. Dieser Puffer ist der Grund, warum ein Screenreader-Nutzer eine Seite ganz anders erlebt als jemand, der einfach mit der Maus scrollt.

Sobald der Nutzer aber in ein Formularfeld gelangt, schaltet der Screenreader in den Fokus- oder Formular-Modus, in dem die Tastatureingaben direkt an das Eingabefeld gehen, damit man tatsächlich tippen kann. Dieses Umschalten geschieht idealerweise automatisch und unbemerkt. Bei schlecht gebauten Bedienelementen aber bleibt der Screenreader im falschen Modus hängen – und dann tut die Tastatur plötzlich etwas ganz anderes, als der Nutzer erwartet. VoiceOver auf dem Mac arbeitet etwas anders, etwa über den sogenannten Rotor, folgt aber demselben Grundgedanken. Wer Bedienelemente baut, muss diese Modi mitdenken, sonst entsteht genau die Verwirrung, die den Zugriff blockiert.

Aus der Praxis: Ein selbstgebautes Auswahlmenü sah modern aus, war aber nicht als solches ausgezeichnet. Im Test blieb der Screenreader im Lese-Modus, statt in den Bedien-Modus zu wechseln. Die Folge: Die Pfeiltasten blätterten durch den umgebenden Text, statt die Optionen des Menüs zu durchlaufen. Der Nutzer konnte das Menü schlicht nicht bedienen. Erst die korrekte Auszeichnung als Bedienelement sorgte dafür, dass der Screenreader-Zugriff im richtigen Modus funktionierte.

Schnellnavigation: wie Screenreader-Nutzer wirklich navigieren

Ein verbreiteter Irrtum lautet, blinde Nutzer ließen sich eine Seite stur von oben bis unten vorlesen. In Wahrheit navigieren erfahrene Screenreader-Nutzer hocheffizient per Schnellnavigation: Mit einzelnen Tastenkürzeln springen sie von Überschrift zu Überschrift, von Link zu Link, zwischen Formularfeldern oder Seitenregionen. Eine Taste für die nächste Überschrift, eine andere für die nächste Region – so verschaffen sie sich in Sekunden einen Überblick. Dieses Springen ist für geübte Nutzer so selbstverständlich wie für Sehende der schnelle Blick über eine Seite. Lineares Vorlesen ist für sie die Ausnahme, nicht die Regel.

Diese Navigation funktioniert aber nur, wenn die Seite die nötige Struktur bereitstellt. Sind Überschriften echte Überschriften, gibt es Sprungmarken und Regionen, sind Links sinnvoll benannt? Dann wird die Seite für einen Screenreader-Nutzer so schnell erfassbar wie für einen sehenden Menschen, der sie überfliegt. Fehlt diese Struktur, bleibt nur das mühsame lineare Durchhören. Wie wichtig dabei eine saubere Auszeichnung ist, zeigt unser Ratgeber zum richtigen Einsatz von ARIA. Eine gute Überschriftenstruktur ist damit nicht nur eine Frage der Optik, sondern das Rückgrat der Navigation für blinde Nutzer.

Was den Screenreader-Zugriff ermöglicht

Die gute Nachricht: Die Grundlage für einen guten Screenreader-Zugriff ist kein Hexenwerk, sondern solides Handwerk. An erster Stelle steht semantisches HTML – also echte Überschriften, Schaltflächen, Listen, Formularelemente und Sprungmarken. Diese Elemente liefern Rollen und oft auch Namen automatisch an den Accessibility Tree, ganz ohne Zusatzaufwand. Viel Barrierefreiheit bekommt man so geschenkt, wenn man von Anfang an die richtigen Bausteine verwendet.

Darauf bauen die weiteren Bausteine auf: ARIA-Attribute dort, wo HTML allein nicht ausreicht, aussagekräftige Beschriftungen für Formularfelder, Alternativtexte für Bilder, eine sinnvolle Reihenfolge im Code und Live-Regions für dynamische Aktualisierungen. Die folgende Übersicht stellt die entscheidenden Stellschrauben einander gegenüber. Die Logik dahinter ist immer dieselbe: Bedeutung gehört in den Code, nicht nur in die Optik.

Was den Screenreader-Zugriff verhindert

Spiegelbildlich lassen sich die typischen Blockaden benennen. Die häufigste ist die sogenannte div-Suppe: Seiten, die fast vollständig aus bedeutungslosen Behälter-Elementen bestehen, ohne echte Semantik. Für das Auge sieht das gut aus, für den Accessibility Tree bleibt es weitgehend leer. Hinzu kommen unbeschriftete Formularfelder und Icons, bei denen der Screenreader nichts Sinnvolles ansagen kann.

Weitere Klassiker sind eine Lese-Reihenfolge, die durch CSS von der eigentlichen Code-Reihenfolge abweicht, Inhalte, die nur visuell und nicht im Code existieren, sowie dynamische Aktualisierungen, die ohne Ankündigung im Hintergrund passieren – etwa eine Fehlermeldung, die erscheint, ohne dass der Screenreader sie meldet. Jede dieser Blockaden kann den Screenreader-Zugriff an einer entscheidenden Stelle zum Erliegen bringen. Das Tückische daran: Keine dieser Blockaden ist im normalen, sehenden Gebrauch sichtbar.

Eine besonders heimtückische Falle verdient eine eigene Erwähnung: ein Element, das per aria-hidden=“true“ vor dem Screenreader versteckt wurde, aber weiterhin mit der Tastatur fokussierbar ist. Der Tastaturnutzer landet beim Tabben auf einem Element, zu dem der Screenreader schweigt – ein stummer Sprung ins Leere, der bei jedem Durchgang für Verwirrung sorgt. Wer Inhalte mit aria-hidden ausblendet, muss sie deshalb zugleich aus der Tab-Reihenfolge nehmen, etwa mit tabindex=“-1″, sonst entsteht genau dieser Geisterfokus.

Aus der Praxis: Auf einer Kontaktseite stand ein wichtiger Hinweis zur Bearbeitungszeit dank CSS optisch ganz oben, im Code aber ganz unten – nach dem Absende-Button. Sehende Nutzer lasen ihn zuerst, der Screenreader zuletzt, also erst nach dem Absenden. Der Hinweis kam für blinde Nutzer schlicht zu spät. Wir haben die Code-Reihenfolge an die visuelle Logik angeglichen, woraufhin der Screenreader-Zugriff den Hinweis an der richtigen Stelle vorlas.

Dynamische Inhalte: der Screenreader-Zugriff im modernen Web

Moderne Websites laden Inhalte nach, ohne die Seite neu aufzubauen – ein Filter aktualisiert die Ergebnisliste, eine Meldung erscheint, ein Warenkorb-Zähler springt hoch. Für sehende Nutzer ist das selbstverständlich. Für den Screenreader-Zugriff sind diese stillen Änderungen eine Herausforderung, denn was sich ändert, ohne dass der Fokus dorthin springt, bemerkt ein Screenreader von sich aus nicht. Was der Bildschirm zeigt und was der Screenreader meldet, kann hier weit auseinanderfallen.

Die Lösung sind sogenannte Live-Regions: Bereiche, die per ARIA-Attribut als „lebendig“ markiert sind, sodass der Screenreader Änderungen darin automatisch ansagt. Das WCAG-Kriterium 4.1.3 „Statusmeldungen“ verlangt genau das für wichtige Rückmeldungen. Hinzu kommt das Fokus-Management: Öffnet sich etwa ein Dialog, muss der Fokus dorthin wandern, damit der Screenreader-Zugriff dem Geschehen folgt. Gerade in Single-Page-Anwendungen, in denen sich Inhalte austauschen, ohne dass eine neue Seite lädt, entscheidet dieses bewusste Lenken über Erfolg oder Scheitern des Zugriffs.

Tastaturzugriff: die Voraussetzung für alles

Ein Punkt wird beim Thema Screenreader oft übersehen: Screenreader-Nutzer bedienen den Computer in aller Regel über die Tastatur, nicht über die Maus. Der Screenreader-Zugriff steht und fällt deshalb mit der vollständigen Tastaturbedienbarkeit, die das WCAG-Kriterium 2.1.1 verlangt. Was sich nur mit der Maus erreichen lässt, ist für einen Screenreader-Nutzer nicht erreichbar. Die Tastatur ist für viele Nutzer das eigentliche Bedienwerkzeug, nicht eine Notlösung. Wird das ignoriert, schließt man diese Nutzer faktisch aus.

Das betrifft jede interaktive Stelle: Menüs, Schaltflächen, Formulare, Dialoge. Sie alle müssen sich mit Tabulator, Pfeiltasten und Eingabetaste ansteuern und bedienen lassen, und der sichtbare Fokus muss dabei klar nachvollziehbar sein. Tastaturzugriff und Screenreader-Zugriff sind zwei Seiten derselben Medaille – ohne das eine funktioniert das andere nicht. Ein Test des Zugriffs beginnt deshalb immer mit der Frage, ob sich überhaupt alles per Tastatur erreichen lässt.

Wie Sie den Screenreader-Zugriff selbst testen

Sie müssen kein Experte sein, um ein Gefühl für den Screenreader-Zugriff zu bekommen. Auf Windows ist NVDA kostenlos verfügbar, auf dem Mac ist VoiceOver bereits eingebaut. Schalten Sie den Screenreader ein, legen Sie die Maus beiseite und versuchen Sie, Ihre wichtigste Aufgabe – etwa einen Kauf oder eine Kontaktanfrage – allein mit der Tastatur und dem Gehör zu erledigen. Genau so, wie es ein blinder Nutzer Tag für Tag tun würde.

Sie merken bei diesem Selbsttest sofort, wo der Screenreader nichts ansagt, wo Sie sich verirren oder wo eine Aktion ins Leere läuft. Wichtig ist allerdings die ehrliche Einordnung: Ein Selbsttest durch eine sehende Person, die den Screenreader gerade erst kennenlernt, ersetzt nicht das Urteil eines erfahrenen Nutzers. Er ist ein wertvoller erster Eindruck, kein vollständiger Beleg – aber er öffnet die Augen für das, was blinde Nutzer täglich erleben. Schon dieser eine Versuch verändert oft die Haltung im ganzen Team gegenüber dem Thema.

Warum nur echte Nutzer den Zugriff wirklich beurteilen können

Aus alldem folgt eine unbequeme Wahrheit: Ob der Screenreader-Zugriff wirklich funktioniert, lässt sich nicht allein mit Software feststellen. Ein automatischer Test kann prüfen, ob ein Element einen Namen hat oder eine Rolle trägt. Er kann aber nicht beurteilen, ob der Name sinnvoll ist, ob das Umschalten zwischen den Modi reibungslos klappt oder ob die Schnellnavigation in der Praxis zu einem verständlichen Erlebnis führt. Genau diese Erlebnisqualität ist aber das, worauf es am Ende ankommt – ein bestandener Scan sagt darüber wenig aus.

Genau hier setzt unser Tiefen-Audit Access Ready an. Wir prüfen Ihr Angebot nicht nur mit Software, sondern mit einem Panel aus echten Nutzern assistiver Technologien, die mit JAWS, NVDA und VoiceOver arbeiten. Sie erleben den Screenreader-Zugriff so, wie Ihre Nutzer ihn erleben – inklusive der Modi-Wechsel, der Navigation und der Frage, ob am Ende alles verständlich ist. Wo ein reiner Scan nur in den Accessibility Tree schaut, zeigt Access Ready Ihnen, ob die Nutzung tatsächlich gelingt. Am Ende steht das rechtlich belastbare IFDB-Zertifikat als Nachweis Ihrer geprüften Barrierefreiheit. Das ist der Unterschied zwischen „technisch wohl in Ordnung“ und „nachweislich für echte Nutzer nutzbar“.

So stellen Sie echten Screenreader-Zugriff sicher

Mein Rat zum Vorgehen: Bauen Sie von Anfang an auf semantisches HTML, prüfen Sie den Accessibility Tree Ihrer wichtigsten Seiten, stellen Sie für jedes Element Name, Rolle und Zustand sicher, und testen Sie die vollständige Tastaturbedienbarkeit. Und verlassen Sie sich am Ende nicht auf Vermutungen, sondern auf den Test mit echten Screenreader-Nutzern. Dieser Weg – Semantik, Prüfung, echter Test – führt zuverlässiger zum Ziel als jedes nachträgliche Flickwerk.

Den schnellen Einstieg bietet unser kostenloser Access Score, ein WCAG-Test Ihrer Website, der erste technische Lücken aufdeckt. Die belastbare Beurteilung des echten Screenreader-Zugriffs liefert unser zertifiziertes Tiefen-Audit Access Ready mit echten Nutzern. Wie das Ganze ins größere Bild der digitalen Barrierefreiheit passt, lesen Sie in unserem Überblick. Welche Screenreader es überhaupt gibt und wie sie sich unterscheiden, erklärt zudem unser Ratgeber zu den gängigen Screenreadern. Echter Screenreader-Zugriff ist kein Zufall – er ist das Ergebnis bewusster, handwerklich sauberer Arbeit. Wer den Zugriff ernst nimmt, baut Websites, die am Ende mehr Menschen tatsächlich erreichen.