Vor einigen Monaten saß ich in einem Audit neben einem blinden Tester, der den Checkout eines etablierten Modehändlers durchlaufen sollte. Optisch war der Shop tadellos, das interne Team stolz auf ein „grünes“ Testergebnis. Mein Tester kam bis zur Zahlungsseite – und dann war Schluss. Ein Pflichtfeld meldete einen Fehler, aber sein Screenreader sagte kein Wort dazu. Er wusste nicht, was falsch war, nicht einmal, dass überhaupt etwas falsch war. Nach drei Minuten hätte ein echter Kunde den Kauf abgebrochen. Genau hier beginnt das Thema, das die meisten Unternehmen unterschätzen: Ein Screenreader liest Ihre Website nicht so, wie Sie sie sehen. Er liest etwas völlig anderes – und wenn Sie verstehen, was, ändern Sie Ihre Prioritäten grundlegend.

Was ist ein Screenreader – und wie funktioniert er technisch?

Ein Screenreader ist eine Software, die digitale Inhalte in synthetische Sprache oder Braille-Ausgabe übersetzt und blinden sowie stark sehbehinderten Menschen die Bedienung von Computern, Smartphones und Websites ermöglicht. Entscheidend ist, woraus er seine Informationen zieht: nicht aus dem sichtbaren Layout, sondern aus dem Accessibility Tree – einer technischen Abbildung Ihrer Seite, die der Browser parallel zum sichtbaren Inhalt aufbaut. Was nicht sauber in diesem Baum landet, existiert für den Nutzer schlicht nicht.

Diesen Punkt halte ich für den wichtigsten des ganzen Artikels, deshalb buchstabiere ich ihn aus. Der Browser erzeugt aus Ihrem HTML zwei parallele Strukturen: den sichtbaren Render-Baum und den Accessibility Tree. Letzterer entsteht aus den HTML-Elementen, ihren nativen Rollen und ergänzenden ARIA-Attributen. Für jedes Bedienelement liefert er drei Informationen, die WCAG-Erfolgskriterium 4.1.2 verbindlich fordert: den Namen (was ist das?), die Rolle (Button, Link, Eingabefeld?) und den Zustand (aktiviert, ausgewählt, ausgeklappt?). Ein optisch als Button gestaltetes <div> ohne diese Angaben sieht für sehende Nutzer wie ein Button aus – für den Screenreader ist es ein bedeutungsloses Stück Text. Genau diese Lücke zwischen Aussehen und Bedeutung ist die Wurzel der meisten Barrieren.

Die Ausgabe erfolgt über zwei Kanäle: eine Sprachsynthese, die den Inhalt vorliest, und optional eine Braillezeile, die Text Zeichen für Zeichen tastbar macht. Viele erfahrene Nutzer kombinieren beides, etwa um Schreibweisen oder Code exakt zu erfassen, die im Sprachfluss untergehen.

Welche Screenreader gibt es? Die Marktlandschaft im Überblick

Drei Screenreader dominieren den Markt und decken laut der jüngsten WebAIM-Nutzerbefragung (1.539 Teilnehmer, Erhebung Ende 2023 bis Anfang 2024) zusammen rund 88 Prozent der Nutzung ab: JAWS, NVDA und VoiceOver. Wer testen will, sollte mit diesen drei beginnen – aber die verbleibenden 12 Prozent, die andere Programme nutzen, sind ein deutliches Argument für sauberen Standard-Code statt für das Optimieren auf ein einzelnes Werkzeug.

NVDA – der heimliche Standard in Europa

Für Ihre deutschsprachige Zielgruppe ist eine Zahl besonders relevant: In Europa ist NVDA der meistgenutzte Screenreader (37,2 Prozent gegenüber 29,7 Prozent für JAWS), während JAWS in Nordamerika klar vorn liegt. NVDA ist kostenlos, quelloffen und wird sehr aktiv weiterentwickelt – mit 97,6 Prozent verzeichnet es die höchste Zufriedenheit. Wer für den DACH-Raum testet und nur ein Werkzeug installiert, sollte NVDA wählen, nicht JAWS.

JAWS – der kommerzielle Platzhirsch

JAWS ist das traditionsreichste und im weltweiten Schnitt meistgenutzte Programm, vor allem in professionellen und behördlichen Umgebungen Nordamerikas. Die Lizenz ist kostspielig, was historisch den Aufstieg des kostenlosen NVDA befeuert hat. Für Tests genügt ein 40-Minuten-Modus, der ohne Lizenz läuft und sich für gezielte Prüfungen neu starten lässt.

VoiceOver – mobil die unangefochtene Nummer eins

Am Desktop wirkt VoiceOver mit unter 10 Prozent fast unbedeutend – auf Mobilgeräten dreht sich das Bild komplett. Über 91 Prozent der Befragten nutzen einen Screenreader auf dem Smartphone, und dort entfallen rund 70 Prozent auf VoiceOver unter iOS. Wer mobile Barrierefreiheit ignoriert, übersieht damit den Kanal, über den die meisten Screenreader-Interaktionen heute stattfinden.

Wie navigieren Screenreader-Nutzer wirklich?

Hier räume ich mit dem hartnäckigsten Missverständnis auf: Screenreader-Nutzer hören eine Seite nicht von oben bis unten ab. Sie scannen – genauso zielgerichtet wie sehende Nutzer, nur über Tastatur und Audio statt über das Auge. Niemand lauscht freiwillig dreißig Navigationslinks, bevor er zum Inhalt kommt. Stattdessen springen erfahrene Nutzer mit Tastaturkürzeln durch die Struktur und bauen sich in Sekunden eine mentale Landkarte der Seite. Und die mit Abstand wichtigste Sprungmarke dabei sind Überschriften.

Die Daten sind eindeutig: 88,8 Prozent der befragten Nutzer empfinden Überschriften-Ebenen als nützlich für die Navigation, und die Nutzung steigt mit der Erfahrung – von 55,4 Prozent bei Anfängern auf 90,7 Prozent bei Experten. Überschriften-Navigation ist seit über einem Jahrzehnt die mit Abstand häufigste Methode, um Informationen auf einer langen Seite zu finden. Wenn Ihre Seite keine sauberen Überschriften hat, nehmen Sie genau diesen Nutzern ihr wichtigstes Werkzeug.

Die Landmark-Falle aus der Praxis. Viele Entwickler-Teams investieren Aufwand in ARIA-Landmarks (role="navigation", role="main" und ähnliche), in der Annahme, das sei die zentrale Navigationshilfe. Die Realität: Zwar nutzen 31,7 Prozent Landmarks gelegentlich, aber nur 3,7 Prozent verwenden sie als primäre Methode, um Inhalte zu finden. Landmarks schaden nicht – aber wer seine Energie dort investiert und gleichzeitig eine kaputte Überschriftenhierarchie liegen lässt, optimiert am Nutzer vorbei. Erst die Überschriften, dann der Feinschliff.

Browse-Modus und Fokus-Modus – der Unterschied, der alles erklärt

Ein technisches Detail, das Sie kennen sollten, weil es viele Bugs erklärt: NVDA und JAWS arbeiten in zwei Modi. Im Browse-Modus (auch Lese- oder Stöbermodus) navigiert der Nutzer mit Einzeltasten durch die Seite – „H“ springt zur nächsten Überschrift, „B“ zum nächsten Button, „F“ zum nächsten Formularfeld. Im Fokus-Modus (Anwendungsmodus) werden Tastendrücke direkt an das Eingabeelement durchgereicht, etwa um Text zu tippen. Der Screenreader wechselt zwischen beiden Modi meist automatisch. Bricht dieser Wechsel – etwa weil ein selbstgebautes Widget seine Rolle falsch deklariert –, landet der Nutzer im falschen Modus, und plötzlich tun Tasten nicht das, was sie sollen. Viele „der Screenreader spinnt“-Meldungen haben hier ihre Ursache.

VoiceOver setzt auf ein anderes Konzept, den Rotor: eine per Geste oder Tastenkombination aufrufbare Auswahl, mit der Nutzer zwischen Navigationsarten umschalten – etwa „nur Überschriften“, „nur Links“ oder „nur Formularfelder“. Auch hier gilt: Funktioniert die Semantik Ihrer Seite, funktioniert der Rotor. Funktioniert sie nicht, sind ganze Inhaltstypen für den Nutzer unauffindbar.

Was das für Ihre Entwicklung konkret bedeutet

Aus dem Navigationsverhalten lassen sich klare technische Konsequenzen ableiten. Ich fasse sie als Prioritätenliste zusammen – in der Reihenfolge, in der ich sie in Projekten angehen lasse.

1. Semantisches HTML zuerst. Ein natives <button>, <nav> oder <input> bringt Rolle, Zustand und Tastaturbedienung von Haus aus mit. Der Grundsatz lautet: Keine ARIA ist besser als schlechte ARIA. Jedes Attribut, das Sie manuell setzen, müssen Sie auch manuell korrekt halten.
2. Überschriftenhierarchie ohne Sprünge. Genau ein <h1> pro Seite, darunter eine logische Staffelung über <h2> und <h3>, ohne Ebenen zu überspringen. Das ist kein optisches, sondern ein strukturelles Gerüst – und es zahlt direkt auf WCAG 1.3.1 und 2.4.6 ein. Mehr dazu im Beitrag zur barrierefreien Überschriftenstruktur.
3. Name, Rolle, Zustand für jedes Bedienelement (WCAG 4.1.2). Jeder Schalter, jedes Eingabefeld, jedes Akkordeon muss seinen Zweck und seinen Zustand an den Accessibility Tree melden.
4. Statusänderungen ansagen (WCAG 4.1.3). Dynamische Rückmeldungen – „In den Warenkorb gelegt“, „3 Treffer gefunden“ – müssen über aria-live-Regionen hörbar werden, sonst bleiben sie für Screenreader-Nutzer unsichtbar.
5. Fokus-Management bei dynamischen Inhalten. Öffnet sich ein Modal, muss der Fokus hinein wandern und dort gefangen bleiben; schließt es, muss er kontrolliert zurückkehren. Single-Page-Apps müssen Routenwechsel aktiv ankündigen.

Ein sechster Baustein gehört formal nicht in diese Liste der Pflicht-Semantik, hebt den Komfort aber enorm: ein Sprunglink (Skip-Link) als allererstes fokussierbares Element der Seite. Er erlaubt Tastatur- und Screenreader-Nutzern, wiederkehrende Navigationsblöcke mit einem einzigen Tastendruck zu überspringen und direkt zum Hauptinhalt zu gelangen – die unmittelbare Umsetzung von WCAG 2.4.1 (Blöcke umgehen). Technisch ist es genau das eben beschriebene Muster: ein Link, der optisch weggeklippt ist und erst bei Tastaturfokus sichtbar einblendet.

Wie groß der Unterschied im Code ist, zeigt dieses Minimalbeispiel. Die erste Variante sieht aus wie ein Button, ist aber für den Screenreader stumm und nicht per Tastatur erreichbar. Die zweite erledigt all das ohne ein einziges Zusatzattribut:

<!-- Unsichtbar für Hilfsmittel, nicht fokussierbar -->
<div class="btn" onclick="kaufen()">Jetzt kaufen</div>

<!-- Name, Rolle, Tastaturbedienung – alles nativ enthalten -->
<button type="button" onclick="kaufen()">Jetzt kaufen</button>

Die Distinktion mag trivial wirken, doch sie entscheidet darüber, ob ein Kaufabschluss für einen blinden Nutzer möglich ist. Und sie illustriert, warum sauberes ARIA und semantisches HTML die Grundlage jeder echten Barrierefreiheit bilden – nicht ein nachgelagertes Widget.

Ein verwandter Punkt, der in Audits ständig für Verwirrung sorgt: der Unterschied zwischen optisch verstecken und für Hilfsmittel verstecken. Wer ein Element mit display: none oder visibility: hidden ausblendet, entfernt es zugleich aus dem Accessibility Tree – der Screenreader liest es nicht mehr vor. Wollen Sie umgekehrt einen Text nur für Screenreader bereitstellen, etwa eine zusätzliche Erläuterung zu einem reinen Icon, brauchen Sie eine eigene Hilfsklasse (üblich sind .sr-only oder .visually-hidden), die das Element optisch wegklippt, im Tree aber belässt. Und drittens verbirgt aria-hidden="true" ein Element vor dem Screenreader, lässt es aber sichtbar – richtig für rein dekorative Grafiken, fatal, wenn versehentlich ein fokussierbarer Button darin steckt, der für Tastatur-Nutzer dann ins Leere führt.

Die teuersten Screenreader-Fallen aus unseren Audits

In hunderten Prüfungen kehren bestimmte Fehler immer wieder. Drei davon kosten Unternehmen besonders häufig echte Conversions – und sie haben gemeinsam, dass kein automatischer Test sie zuverlässig findet.

Fall 1 – Die stumme Bestätigung. Bei dem eingangs erwähnten Modehändler war die Ursache schnell gefunden: Die Fehlermeldung im Bezahlformular wurde rein visuell eingeblendet, ohne aria-live und ohne Verknüpfung zum Eingabefeld über aria-describedby. Sehende Kunden sahen den roten Hinweis sofort, der Screenreader schwieg. Wir haben die Meldung in eine Live-Region gelegt und programmatisch mit dem Feld verbunden – eine Korrektur von wenigen Zeilen, die einen kompletten Conversion-Blocker auflöste.

Fall 2 – ARIA-Overkill. Ein SaaS-Anbieter hatte gut gemeint jedes Element mit aria-label versehen. Das Problem: Mehrere Labels überschrieben den sichtbaren Text mit veralteten oder schlicht falschen Bezeichnungen. Ein Button, der sichtbar „Speichern“ hieß, wurde vom Screenreader als „Senden“ angesagt. Ein automatisches Tool meldete hier grün – ein Label war ja vorhanden. Erst der echte Nutzer bemerkte den Widerspruch. Die Lehre: Falsche Semantik ist gefährlicher als fehlende, weil sie ein trügerisches Gefühl von Konformität erzeugt.

Fall 3 – Das Modal ohne Rückweg. Bei einem Buchungsportal öffnete ein Dialog korrekt, fing den Tastaturfokus aber nicht ein. Der Nutzer „tabte“ aus dem sichtbaren Dialog heraus in die dahinterliegende, eigentlich inaktive Seite und verlor jede Orientierung. Solche Fokusfallen erlebt man als Sehender nie – für Tastatur- und Screenreader-Nutzer sind sie eine Sackgasse. Die saubere Lösung umfasst Fokus-Trapping, eine sinnvolle Rückkehr beim Schließen und das Ausblenden des Hintergrunds für Hilfsmittel.

So prüfen Sie Ihre Seite selbst – ein 10-Minuten-Test mit NVDA

Sie müssen kein Experte sein, um die gröbsten Schnitzer selbst zu finden. NVDA ist kostenlos, in wenigen Minuten installiert, und mit einer Handvoll Tastenkürzeln decken Sie einen erstaunlichen Teil der typischen Probleme auf. Hier ist die Vorgehensweise, die ich auch internen Teams für den ersten Eindruck mitgebe.

Laden Sie NVDA von der Seite des gemeinnützigen Herstellers NV Access, starten Sie es und öffnen Sie Ihre Website in Chrome oder Firefox. Diese Tasten brauchen Sie für den Anfang:

• H – springt von Überschrift zu Überschrift. Hören Sie die Gliederung ab: Ergibt sie ohne den sichtbaren Inhalt eine sinnvolle Struktur?
• B – springt zwischen Schaltflächen. Werden alle Buttons mit aussagekräftigem Namen angesagt, oder hören Sie nur „Schaltfläche“?
• F – springt zu Formularfeldern. Hat jedes Feld ein vorgelesenes Label?
• K – springt zwischen Links. Ergeben die Linktexte aus dem Kontext gerissen noch Sinn, oder häuft sich „hier klicken“ und „mehr“?
• Einfügen + F7 – öffnet die Elementliste mit allen Überschriften, Links und Landmarks auf einen Blick. Das ist die schnellste Röntgenaufnahme Ihrer Seitenstruktur.

Der eigentliche Test besteht aus drei Fragen, die Sie mit ausgeschaltetem Monitor – oder mit geschlossenen Augen – beantworten sollten: Erstens, baut sich aus den Überschriften eine logische Landkarte der Seite auf? Zweitens, erreichen Sie jeden interaktiven Bereich allein mit der Tabulatortaste, ohne in einer Schleife oder Sackgasse zu landen? Drittens, wird jede Rückmeldung – ein hinzugefügter Warenkorb-Artikel, eine Fehlermeldung – tatsächlich vorgelesen? Wenn auch nur eine dieser Fragen ein Nein ergibt, haben Sie eine Barriere gefunden, die echte Nutzer täglich erleben.

Seien Sie sich der Grenzen dieses Tests bewusst: Er ersetzt kein professionelles Audit. Sie bedienen NVDA als Sehender und unbeholfen, Sie kennen die Seite bereits, und Sie übersehen subtile Probleme, die nur jemand bemerkt, der täglich mit der Technologie arbeitet. Aber als erster Realitätsabgleich ist diese Übung Gold wert – und sie verändert garantiert, wie Ihr Team über die eigene Website denkt.

Warum echte Nutzer mehr finden als jeder Scanner

Alle drei Fälle eint ein Muster: Ein automatischer Test prüft, ob ein Code-Muster vorhanden ist – nicht, ob die Erfahrung funktioniert. Ein Scanner sieht ein aria-label und hakt es ab. Ob das Label inhaltlich richtig ist, ob die Bestätigung tatsächlich angesagt wird, ob der Fokus im Modal bleibt, lässt sich nur beurteilen, indem ein Mensch die Seite mit einem echten Screenreader durchläuft. Genau diese 60 bis 70 Prozent der prüfrelevanten Kriterien entziehen sich der Automatisierung – eine Grenze, die ich im Vergleich der Test-Tools mit konkreten Beispielen belege. Die Lücke zwischen vorhandenem Code und gelebter Bedienbarkeit schließt nur ein Mensch mit echtem Screenreader – das ist die Grundlage unseres Audits Access Ready.

Bemerkenswert ist, wie klar die Betroffenen das selbst sehen: Befragt, was die digitale Teilhabe stärker verbessern würde – bessere Websites oder bessere Hilfsmittel –, nennen 85,9 Prozent die Websites. Die Verantwortung liegt also nicht bei der Technik der Nutzer, sondern bei denen, die digitale Angebote bauen. Und sie verweist auf eine gesetzliche Dimension: Seit Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz genau diese Zugänglichkeit von einem großen Teil der Privatwirtschaft.

Vom Verständnis zum belastbaren Nachweis

Wenn Sie eines aus diesem Artikel mitnehmen, dann dieses: Die einzige verlässliche Methode, um zu wissen, ob Ihre Website für Screenreader-Nutzer funktioniert, ist, sie von echten Nutzern dieser Technologien prüfen zu lassen. Deshalb kombinieren wir bei Access Ready ein technisches Tiefen-Audit mit JAWS, NVDA und VoiceOver mit einem Panel echter Nutzer assistiver Technologien – Menschen, die Ihren Bestellprozess tatsächlich durchlaufen, nicht simulieren. Nach Behebung der Mängel erhalten Sie ein rechtlich belastbares Zertifikat, das Ihre Sorgfaltspflicht nachweisbar macht.

Ich verspreche Ihnen dabei keine perfekte Bedienbarkeit für jeden denkbaren Fall – diese Zusage wäre unseriös. Was wir liefern, ist nachweisbare, dokumentierte Barrierearmut auf dem Stand der Technik, geprüft an der Realität statt am Code-Muster. Wenn Sie wissen wollen, wie Ihr digitales Angebot sich für einen blinden Menschen tatsächlich anfühlt, ist ein Audit mit echten Nutzern assistiver Technologien der direkte und ehrliche Weg dorthin. Den schnellen ersten Anhaltspunkt liefert Ihnen vorab unser kostenloser Access Score – ein automatisierter WCAG-Test, der die maschinell prüfbaren Schwächen Ihrer Seite in Minuten sichtbar macht. Für den belastbaren Nachweis folgt darauf Access Ready: Wo andere Anbieter Ihnen ein Overlay-Widget verkaufen und Sie mit dem Haftungsrisiko allein lassen, bekommen Sie ein an der Realität geprüftes, dokumentiertes Ergebnis.