Über Nutzererfahrungen mit Screenreadern lässt sich aus dem Code allein nichts ablesen – man muss zuhören. Eine Seite kann jeden automatischen Test bestehen und sich trotzdem anfühlen, als würde man mit verbundenen Augen durch ein unbeschriftetes Lagerhaus tasten. In unseren Audits sitze ich regelmäßig neben Menschen, die das Web täglich per Sprachausgabe bedienen, und die größten Probleme tauchen fast nie in einem Prüfbericht auf. Sie zeigen sich erst, wenn ein echter Nutzer an einer Stelle stockt, an der die Entwickler keine vermutet hätten. In diesem Ratgeber nehme ich Sie mit in diese Perspektive: Wie navigieren Screenreader-Nutzer tatsächlich, wo beginnt der Frust, warum klingt dieselbe Seite auf jedem Programm anders – und warum der wichtigste Test der ist, den keine Software leisten kann.

Wie navigieren Screenreader-Nutzer eine Website wirklich?

Screenreader-Nutzer lesen eine Seite nicht von oben nach unten, sondern springen gezielt zwischen Strukturelementen – allen voran den Überschriften. Die jüngste große Nutzerbefragung von WebAIM zeigt das eindeutig: Auf langen Seiten suchen 71,6 Prozent der Befragten zuerst über die Überschriften nach dem gewünschten Inhalt, weit vor der Suchfunktion (13,6 Prozent), dem reinen Durchlesen (6,4 Prozent) oder der Linkliste (4,8 Prozent). 88,8 Prozent halten eine saubere Überschriftenhierarchie für nützlich. Überschriften sind für diese Nutzer also kein typografisches Detail, sondern das Navigationssystem der Seite.

Je versierter der Nutzer, desto stärker dieser Effekt. Erfahrene Anwender bewegen sich fast ausschließlich strukturell – sie drücken die Taste für die nächste Überschrift, hüpfen von Abschnitt zu Abschnitt und erfassen so in Sekunden, was eine sehende Person mit einem Blick überfliegt. Einsteiger lesen dagegen häufiger linear oder nutzen die Suchfunktion. Das hat eine unbequeme Konsequenz: Wenn Ihre Überschriften nur optisch existieren – also fett formatierter Text statt echter <h2>-Elemente –, nehmen Sie gerade Ihren souveränsten Nutzern ihr wichtigstes Werkzeug. Die zugrunde liegende Anforderung ist Erfolgskriterium 1.3.1 (Info und Beziehungen): Was optisch wie eine Überschrift aussieht, muss auch im Code eine sein, und 2.4.6 (Überschriften und Beschriftungen) verlangt, dass sie den Abschnitt treffend benennt.

Landmarks und Regionen – also ausgezeichnete Bereiche wie Navigation, Hauptinhalt oder Fußzeile – sind das zweite Standbein, aber ein schwächeres: In der Befragung nutzen sie rund 32 Prozent regelmäßig, doch nur etwa drei bis vier Prozent verwenden sie als primäre Methode auf langen Seiten. Die Lehre daraus: Investieren Sie zuerst in eine schlüssige Überschriftenstruktur, dann in Landmarks. Wer die Reihenfolge umdreht, optimiert an der tatsächlichen Nutzung vorbei.

Was ein Screenreader-Nutzer in den ersten Sekunden hört

In den ersten Sekunden nach dem Laden entscheidet sich, ob Orientierung gelingt oder Verwirrung beginnt. Vorgelesen wird zuerst der Seitentitel, dann arbeitet sich der Nutzer in die Seite vor. Fehlt ein aussagekräftiger Titel (Erfolgskriterium 2.4.2, Seite mit Titel versehen), weiß er nicht einmal, wo er gelandet ist – „Startseite | Startseite | Startseite“ über zwölf Browser-Tabs ist ein realer Orientierungsverlust. Und stößt er danach auf eine Wand aus vierzig Navigationslinks, die sich auf jeder Unterseite wiederholt, muss er sie jedes Mal durchhören oder gezielt überspringen.

Genau hier hilft die Sprungmarke zum Hauptinhalt (2.4.1, Blöcke umgehen). Interessanterweise zeigt dieselbe Befragungsreihe seit Jahren, dass Sprungmarken für Tastaturnutzer ohne Screenreader oft wichtiger sind als für Screenreader-Nutzer selbst – denn Letztere springen ohnehin per Überschrift direkt in den Inhalt. Beide Mechanismen gehören dennoch zusammen: eine saubere Überschriftenstruktur für die einen, eine funktionierende Sprungmarke für die anderen. Wer nur an eine Gruppe denkt, lässt die andere stehen.

Wo der Frust beginnt: die häufigsten Barrieren

Der größte Frust entsteht nicht an exotischen Sonderfällen, sondern an immer denselben Klassikern. Bemerkenswert ist, dass die Rangfolge der ärgerlichsten Probleme über alle zehn WebAIM-Befragungen der letzten vierzehn Jahre nahezu konstant geblieben ist – ganz vorne stehen seit jeher CAPTCHAs, mehrdeutige Links und mangelnde Tastaturbedienbarkeit. Diese Beständigkeit ist eine schlechte Nachricht: Wir scheitern als Branche seit über einem Jahrzehnt an denselben Dingen. Aus unseren Audits kommen die folgenden Stolperstellen am häufigsten dazu:

• Unbeschriftete Bedienelemente. Der Nutzer hört „Schaltfläche“ – und hat keine Ahnung, ob sie löscht, kauft oder abschickt. Icon-Buttons ohne zugänglichen Namen sind der Klassiker (Erfolgskriterium 4.1.2, Name, Rolle, Wert).
• Mehrdeutige Links. Viele Nutzer rufen eine Liste aller Links auf, um sich zu orientieren. Stehen dort fünfzehnmal „Mehr“ oder „Hier klicken“, ist die Liste wertlos (2.4.4, Linkzweck im Kontext).
• Bilder ohne oder mit falschem Alternativtext. Ein dekoratives Bild, das vorgelesen wird, oder eine aussagekräftige Grafik, die schweigt – beides stört (1.1.1, Nicht-Text-Inhalt).
• Lesereihenfolge ≠ Anzeigereihenfolge. Per CSS lässt sich der optische Aufbau umstellen, der Screenreader folgt aber der Reihenfolge im Code. Stimmen beide nicht überein, ergibt der Inhalt akustisch keinen Sinn (1.3.2, Bedeutungstragende Reihenfolge).
• Fokusfallen in Dialogen. Ein Pop-up, das den Fokus nicht festhält, lässt den Nutzer „hinter“ dem Dialog weiterlesen oder gar nicht mehr heraus (2.1.2, Keine Tastaturfalle; 2.4.3, Fokus-Reihenfolge).
• Stumme dynamische Änderungen. Der Warenkorb aktualisiert sich, eine Fehlermeldung erscheint – aber nichts wird angesagt. Der Nutzer erfährt es schlicht nicht (4.1.3, Statusmeldungen, umgesetzt über aria-live).
• Nicht zugeordnete Formularfehler. Der Nutzer hört „ungültig“, aber nicht, welches Feld und warum (3.3.1, Fehlererkennung). Wie man Fehlermeldungen sauber anbindet, vertiefe ich im Ratgeber zu barrierefreien Formularen.

Aus der Praxis: In einem Audit für einen Online-Shop wollte eine erfahrene NVDA-Nutzerin einen Artikel in den Warenkorb legen. Der „In den Warenkorb“-Button war als reines Icon umgesetzt und wurde nur als „Schaltfläche“ angesagt. Sie probierte ihn aus, der Artikel landete im Korb – aber es kam keine Rückmeldung, weil die Mini-Warenkorb-Anzeige ohne Live-Region aktualisiert wurde. Aus ihrer Sicht war völlig offen, ob etwas passiert war. Sie klickte den Button dreimal. Im Checkout lagen dann drei Exemplare. Kein automatischer Test hätte diese Kette aus zwei kleinen Fehlern als das erkannt, was sie war: ein direkter Conversion-Killer.

Was gute Nutzererfahrungen mit Screenreadern ausmacht

Gute Nutzererfahrungen mit Screenreadern fühlen sich nicht „besonders“ an, sondern schlicht effizient und vorhersehbar – der Nutzer kommt in seinem eigenen Tempo ans Ziel, ohne Überraschungen, Sackgassen oder Stellen, an denen er raten muss. Das klingt selbstverständlich, ist in der Realität aber die Ausnahme: Die meisten Oberflächen zwingen ihn zu Umwegen, die eine sehende Person gar nicht bemerkt. Und dieses Tempo ist hoch: Geübte Anwender hören Sprachausgabe oft bei 300 Wörtern pro Minute und mehr, deutlich schneller, als die meisten Sehenden mithören könnten. Jede überflüssige Ansage und jeder unnötige Umweg kostet sie deshalb überproportional. Gute Zugänglichkeit bedeutet hier weniger das Hinzufügen von „Features“ als das Vermeiden von Reibung.

In der Praxis erkenne ich eine gelungene Umsetzung an fünf Merkmalen. Erstens an einer effizienten Struktur: eine einzige <h1>, darunter logisch verschachtelte Überschriften ohne übersprungene Ebenen, sodass die Elementliste ein echtes Inhaltsverzeichnis ergibt. Zweitens an aussagekräftigen Namen – jeder Link und jede Schaltfläche ergibt auch isoliert Sinn, ohne den umgebenden Text. Drittens an vorhersehbarem Fokus: Öffnet sich ein Dialog, wandert der Fokus hinein; schließt er sich, kehrt er zum auslösenden Element zurück, und er bleibt durchgehend sichtbar und logisch.

Viertens an maßvoll angesagten Änderungen: Aktualisiert sich der Warenkorb oder erscheint ein Filterergebnis, wird das über eine Live-Region gemeldet – aber sparsam, damit die Seite nicht pausenlos dazwischenredet. Und fünftens, oft unterschätzt, an Zurückhaltung beim Einsatz von ARIA. Die erste Regel im Umgang mit ARIA lautet: Kein ARIA ist besser als schlechtes ARIA. Ein echtes <button>-Element schlägt jedes mit role=“button“ nachgebaute <div>, weil es Tastaturverhalten, Fokus und Ansage von Haus aus mitbringt. Über-deklarierte Oberflächen, die alles dreifach ankündigen, sind für Nutzer genauso ermüdend wie unter-gebaute. Mehr ARIA ist eben nicht mehr Barrierefreiheit – worauf es ankommt, vertiefe ich im Ratgeber zu ARIA in Webanwendungen.

Über all dem steht Konsistenz: Wenn dasselbe Muster auf jeder Seite gleich funktioniert, baut der Nutzer ein verlässliches mentales Modell auf und muss nicht jede Komponente neu entschlüsseln. Genau diese Qualitäten lassen sich nicht abhaken, sondern nur im Erleben beurteilen – was zur entscheidenden Frage führt, warum dieselbe gut gemeinte Umsetzung auf verschiedenen Programmen so unterschiedlich ankommt.

Warum dieselbe Seite auf jedem Screenreader anders klingt

Dieselbe Seite verhält sich auf NVDA, JAWS und VoiceOver unterschiedlich – ein Test auf nur einem Programm ist deshalb keine Garantie. In der aktuellen Befragung ist NVDA mit 65,6 Prozent inzwischen das meistgenutzte Programm und hat JAWS (60,5 Prozent) überholt; auf Mobilgeräten dominiert VoiceOver. Jedes dieser Programme interpretiert ARIA-Attribute, Tabellen und dynamische Inhalte leicht anders, kombiniert mit unterschiedlichen Browsern und Betriebssystemen. Eine Komponente, die auf NVDA unter Firefox sauber klingt, kann auf VoiceOver unter Safari verstummen.

Für die Praxis heißt das: Wer ernsthaft prüfen will, prüft auf mehreren Kombinationen – und nicht nur mit der eigenen, sehenden Wahrnehmung. Welche Programme es gibt und wie sie sich technisch unterscheiden, erkläre ich im Überblick zu den gängigen Screenreadern; wie man Inhalte grundsätzlich für sie aufbereitet, im Ratgeber zum Screenreader-Zugriff auf Inhalte. Verwandt ist die taktile Ausgabe über eine Braillezeile, die taubblinde Nutzer zwingend brauchen und die wieder eigene Anforderungen stellt.

Der unsichtbare Umsatzverlust

Die teuerste Folge schlechter Screenreader-Erfahrung bekommen Sie nie zu Gesicht: Betroffene beschweren sich kaum, sie gehen einfach. Laut Befragung kontaktieren 67 Prozent der Nutzer einen Seitenbetreiber bei Barrieren nie oder nur selten. Ein sehender Kunde, der im Checkout hängt, schreibt vielleicht eine wütende Mail; ein Screenreader-Nutzer, der an der unbeschrifteten Schaltfläche scheitert, schließt den Tab und kauft beim Wettbewerber. Dieser Abbruch erscheint in keiner Statistik als das, was er ist – er sieht aus wie eine ganz normale Absprungrate.

Gleichzeitig steigt der Anspruch. 85,9 Prozent der Befragten sagen, bessere Websites würden die Zugänglichkeit am stärksten verbessern – die Erwartung an Anbieter wächst Jahr für Jahr. Wer hier vorangeht, gewinnt eine loyale, oft unterschätzte Kundengruppe; wer zurückbleibt, verliert sie geräuschlos. Es geht dabei nicht um Mitleid, sondern um zahlende Kunden, die an einer überwindbaren Hürde verloren gehen.

Warum „konform“ nicht „nutzbar“ heißt – und was echte Nutzer aufdecken

Ein bestandener Test belegt, dass die maschinell prüfbaren Regeln eingehalten sind – nicht, dass die Seite sich gut bedienen lässt. Genau diese Lücke zwischen technischer Konformität und gelebter Nutzbarkeit ist der Grund, warum wir bei IFDB auf echte Menschen setzen. Automatische Werkzeuge und selbst sorgfältige Entwickler prüfen gegen Regeln; ein erfahrener Screenreader-Nutzer erlebt die Seite. Diese drei Prüfebenen decken jeweils anderes auf:

Unser Tiefen-Audit Access Ready kombiniert genau das: Software und manuelle Prüfung für die Breite, ein Panel aus echten Nutzern assistiver Technologien für die Tiefe. Wir versprechen dabei bewusst keine „100 Prozent“, sondern belastbare Barrierearmut – denn ein ehrliches Ergebnis ist mehr wert als ein grünes Häkchen, das im Alltag der Nutzer zerbricht. Diesen Human-in-the-loop-Ansatz kann ein reines Skript-Tool strukturell nicht nachbilden.

So hören Sie Ihre Seite mit den Ohren eines Nutzers

Einen ersten, ehrlichen Eindruck bekommen Sie ohne fremde Hilfe – und dieser eine Test verändert oft die ganze Diskussion im Team.

Aus der Praxis – der Linklisten-Test: Installieren Sie den kostenlosen Screenreader NVDA und öffnen Sie auf einer Ihrer Seiten mit NVDA + F7 die Elementliste. Schalten Sie auf „Links“ um und lesen Sie ausschließlich die Linktexte – losgelöst vom umgebenden Text, so wie der Nutzer sie hört. Können Sie bei jedem Eintrag sagen, wohin er führt? Bei den meisten Seiten lautet die Antwort nein: Da stehen fünf „Mehr erfahren“, drei „Hier“ und ein nacktes „PDF“. Wiederholen Sie das Ganze mit der Ansicht „Überschriften“ – ergibt die reine Überschriftenliste ein sinnvolles Inhaltsverzeichnis Ihrer Seite? Diese zwei Minuten zeigen Ihnen schwarz auf weiß, wie Ihre wichtigsten Navigationswege bei einem Screenreader-Nutzer ankommen. Es ersetzt kein vollständiges Audit, aber es macht das Problem im Team sofort greifbar.

Wer tiefer einsteigen will, sollte zusätzlich die Tastaturbedienung ohne Maus durchspielen und auf dynamische Inhalte achten – Bereiche, in denen ARIA und Live-Regionen ins Spiel kommen, die ich im Ratgeber zu ARIA in Webanwendungen behandle. Maßstab für all das ist und bleibt die WCAG 2.2 auf Stufe AA.

Echte Teilhabe entscheidet sich im Erleben

Ob Ihre Website wirklich funktioniert, beantwortet kein Prüfbericht, sondern der Mensch, der sie täglich per Sprachausgabe bedient. Genau deshalb stellen wir echte Nutzer in den Mittelpunkt unseres Vorgehens – sie finden, was Scanner und Entwickler systematisch übersehen. Andere Anbieter liefern Ihnen einen Report und lassen Sie mit der Interpretation allein; wir zeigen Ihnen, wie sich Ihre Seite anfühlt, und schließen die Lücke zwischen konform und nutzbar.

Den schnellen Einstieg bietet der kostenlose Access Score, der die technisch erkennbaren Lücken Ihrer Website in Minuten aufdeckt. Die belastbare Beurteilung mit echten Screenreader-Nutzern – und das rechtlich tragfähige Zertifikat dazu – liefert das Tiefen-Audit Access Ready. So wird aus „Wir haben die Tests bestanden“ ein „Unsere Kunden kommen tatsächlich durch“.