Text-to-Speech vs. Screenreader

Ihre Inhalte haben eine Stimme

Text-to-Speech-Technologie (TTS) wandelt geschriebene Informationen in Audio um. Sie hilft Menschen mit Blindheit, Sehbeeinträchtigungen, Dyslexie und ADHS, Inhalte auf eine für sie passende Weise aufzunehmen. TTS wird außerdem häufig in Schulen, von Sprachlernenden und von Fachleuten genutzt, die lieber mit dem Ohr als mit dem Auge korrekturlesen.

Weil sowohl TTS als auch Screenreader eine synthetische Stimme erzeugen, nehmen viele an, sie seien dasselbe – oder dass das Hinzufügen einer „Vorlesen“-Schaltfläche eine Website für blinde Nutzer barrierefrei mache. Diese Annahme ist falsch, und ihr zu folgen kann zu einer Website führen, die barrierefrei klingt, für viele Menschen aber tatsächlich unbenutzbar ist. Dieser Artikel erklärt, wie jede Technologie funktioniert, wer auf sie angewiesen ist, wo die Grenze zwischen ihnen wirklich verläuft und was es braucht, um korrekt für Screenreader zu entwickeln. Wenn Sie sich nur eines merken, dann dies: Ein Vorlese-Widget ist ein Komfortmerkmal, kein Barrierefreiheitsmerkmal.

Wie funktioniert TTS?

TTS verarbeitet Text in drei groben Stufen:

Textanalyse – Bestimmen von Ton, Grammatik und Struktur, Ausschreiben von Zahlen und Symbolen („5 $“ wird zu „fünf Dollar“) und Segmentieren von Sätzen.
Sprachliche Verarbeitung – Berechnen von Aussprache, Betonung und Akzentuierung, oft mithilfe eines Aussprachewörterbuchs plus Regeln für unbekannte Wörter.
Audiosynthese – Erzeugen von Sprache aus mathematischen Sprachmodellen, zunehmend mithilfe neuronaler Netze, die weit natürlicher klingen als ältere konkatenative Engines.

Moderne Systeme bieten Stimmanpassungen wie Geschwindigkeit, Tonhöhe, Stimmpersona und Sprachauswahl. Entscheidend ist, was TTS als Eingabe erhält: einen Textblock, den jemand bereits ausgewählt, eingefügt oder darauf gerichtet hat. TTS ist im Kern eine content-out-Technologie. Sie spricht aus, was ihr gegeben wird. Sie erkundet keine Oberfläche und hat kein Konzept von Schaltflächen, Formularfeldern oder Seitenstruktur.

Welche Einschränkungen hat die TTS-Technologie?

TTS ist wirklich nützlich, aber nicht perfekt, und ihre Grenzen sind für den folgenden Vergleich wichtig:

Aussprachelücken – Sie kann ungewöhnliche Wörter, Eigennamen, medizinische oder juristische Begriffe und Abkürzungen falsch aussprechen.
Ungleichmäßige Sprachunterstützung – Viele Tools beherrschen verbreitete Sprachen gut, tun sich aber mit selteneren Sprachen und regionalen Dialekten schwer.
Ton und Nuance – TTS hat Schwierigkeiten mit Sarkasmus, Humor und idiomatischen Ausdrücken, sodass Inhalte im falschen Ton vermittelt werden können.
Kein Interaktionsmodell – und das ist der entscheidende Punkt: TTS liest vor; es lässt Sie nichts tun. Sie können mit TTS allein kein Kassenformular ausfüllen, keinen Dialog schließen und sich nicht zwischen Menüpunkten bewegen.

Genau diese letzte Einschränkung ist der Punkt, an dem die Verwechslung mit Screenreadern beginnt.

Was ist der Unterschied zwischen Text-to-Speech und Screenreader-Technologie?

Hier entsteht das verbreitete Missverständnis. Text-to-Speech liest Text vor – das ist seine Hauptfunktion. Ein Screenreader leistet weit mehr: Er ermöglicht Nutzern, einen ganzen Computer oder ein Mobilgerät per Gehör und Tastatur (oder Touch-Gesten) zu bedienen.

Screenreader geben Oberflächenbeschriftungen, Formularfelder, Schaltflächen und Links aus; sie lesen den Alternativtext von Bildern vor, damit Nutzer visuelle Inhalte verstehen; und sie machen den Zustand von Komponenten zugänglich – ob ein Kontrollkästchen aktiviert ist, ein Menü ausgeklappt ist, ein Tab ausgewählt ist oder ein Fehler aufgetreten ist. Sie verwandeln eine visuelle, mausgesteuerte Oberfläche in eine lineare, hörbare und bedienbare.

Eine schnelle Möglichkeit, den Unterschied zu spüren: TTS beantwortet die Frage „Was steht in diesem Absatz?“ Ein Screenreader beantwortet „Wo bin ich, was kann ich hier tun und was ist gerade passiert?“ Beim Ersten geht es um das Aufnehmen von Inhalten. Beim Zweiten um das Steuern von Software.

Wie sich ein Screenreader-Nutzer tatsächlich durch eine Seite bewegt

Sehende Nutzer überfliegen eine Seite in Sekunden. Ein Screenreader-Nutzer baut nach und nach ein mentales Modell auf und verlässt sich auf Struktur, um sich effizient zu bewegen. In der Praxis tun sie Folgendes:

Zwischen Überschriften springen, um die Seitengliederung zu verstehen (deshalb ist eine korrekte Überschriftenhierarchie so wichtig).
Eine Liste aller Links oder aller Formularfelder aufrufen, um über Orientierungspunkte zu navigieren, statt von oben nach unten zu lesen.
Landmark-Bereiche (Banner, Navigation, Hauptinhalt, Fußzeile) nutzen, um direkt zum gewünschten Inhalt zu springen.
Sich mit der Tab-Taste durch interaktive Elemente bewegen und erwarten, dass der Fokus an einer sichtbaren und logischen Stelle landet.
Auf Live-Ansagen achten, wenn sich etwas ohne vollständiges Neuladen der Seite ändert.

Nichts davon funktioniert, wenn das zugrunde liegende Markup die Seite nicht ehrlich beschreibt. Eine „Vorlesen“-Funktion bietet keine dieser Navigationshilfen – sie liest lediglich den auf dem Bildschirm vorhandenen Text in visueller Reihenfolge vor, ohne dass man die Bedienelemente betätigen kann.

Wer welche Technologie nutzt und warum das wichtig ist

TTS wird von einem breiten Publikum genutzt, oft situativ: Menschen mit Dyslexie, ADHS oder geringer Sehkraft; Multitasker; Sprachlernende; und alle, die einfach lieber zuhören. Die meisten dieser Nutzer können den Bildschirm noch sehen und eine Maus verwenden.

Zu den Screenreader-Nutzern gehören Menschen, die blind sind oder schwere Sehbeeinträchtigungen haben, sowie manche Menschen mit kognitiven oder motorischen Behinderungen, die auf die Technologie angewiesen sind, um ein Gerät überhaupt zu nutzen. Für sie ist sie keine Komfortschicht auf einer nutzbaren Oberfläche – sie ist die Oberfläche. Die gängigsten Tools sind NVDA und JAWS unter Windows, VoiceOver auf Apple-Geräten und TalkBack unter Android. Jedes interpretiert dieselbe Webseite etwas anders, was einer der Gründe ist, warum das Testen über alle hinweg wichtig ist.

Warum Vorlese-Widgets kein Ersatz für Barrierefreiheit sind

Immer mehr Websites pflanzen eine „Diese Seite anhören“-Schaltfläche oder ein Drittanbieter-Widget an, das Text hervorhebt und vorliest. Diese Tools können manchen Lesern helfen, und es ist nichts dagegen einzuwenden, eines als Komfort anzubieten. Das Problem besteht darin, es als Ersatz für echte Screenreader-Unterstützung zu behandeln. Das ist es aus mehreren konkreten Gründen nicht.

Sie lesen nur; sie bedienen nicht. Ein Vorlese-Widget liest Ihre Preistabelle vor, aber es lässt einen blinden Nutzer nicht einen Tarif auswählen, den Warenkorb öffnen, Zahlungsdaten eingeben und den Kauf abschließen. Echte Aufgaben erfordern bedienbare Steuerelemente, kein Vorlesen.
Sie können Zustand oder Rollen nicht zugänglich machen. Ob eine Schaltfläche gedrückt ist, ein Feld erforderlich ist, ein Abschnitt eingeklappt ist oder gerade eine Fehlermeldung erschienen ist – nichts davon wird durch das Vorlesen sichtbaren Texts vermittelt. Screenreader stützen sich auf Rollen, Namen und Zustände im Markup, um es anzusagen.
Screenreader-Nutzer haben bereits ein Werkzeug. Blinde Nutzer bringen ihren eigenen Screenreader mit, fein abgestimmt auf ihre Vorlieben und ihr Muskelgedächtnis. Ein seitenweites Widget konkurriert damit, stört es manchmal und tut nichts, um das fehlerhafte Markup zu reparieren, an dem ihr Screenreader sich verschluckt.
Sie verschleiern Probleme, statt sie zu beheben. Hat ein Formularfeld keine Beschriftung, überspringt das Widget es genauso wie ein Screenreader – nur ist die fehlende Beschriftung jetzt hinter einer Funktion verborgen, die hilfreich aussieht. Der zugrunde liegende Mangel bleibt bestehen.

Dieselbe Logik gilt, sogar noch stärker, für sogenannte Barrierefreiheits-Overlays – Skripte, die sofortige Konformität versprechen, indem sie automatisierte Korrekturen und eine Symbolleiste über eine bestehende Website legen. Sie reparieren den zugrunde liegenden Code nicht, geraten häufig in Konflikt mit der eigenen assistiven Technologie der Nutzer und können keine echte Konformität liefern. Der verlässliche Weg ist, die Quelle zu beheben. Eine ausführlichere Erklärung, warum oberflächliche Korrekturen zu kurz greifen, finden Sie in unserem Leitfaden zu echter digitaler Barrierefreiheit.

Ein konkretes Beispiel: der Checkout, der „spricht“

Stellen Sie sich einen Onlineshop vor, der ein Vorlese-Widget hinzugefügt hat und überzeugt ist, die Website sei nun barrierefrei. Eine blinde Kundin kommt mit ihrem eigenen laufenden Screenreader. Die Produktbeschreibung wird gut vorgelesen – dieser Teil ist nur Text. Aber das „In den Warenkorb“-Steuerelement ist ein gestyltes div mit einem Click-Handler statt einer echten Schaltfläche, sodass der Screenreader es nie als Schaltfläche ansagt und die Tastatur es nicht erreichen kann. Der Mengenwähler aktualisiert eine Summe ohne Live-Region, sodass die Änderung lautlos bleibt. Das Gutscheincode-Feld hat Platzhaltertext, aber keine zugeordnete Beschriftung, sodass es nur als „Textfeld bearbeiten“ angesagt wird. Das Versandformular zeigt visuell einen roten Fehler, aber der Fehler ist nicht mit dem Feld verknüpft und wird überhaupt nicht angesagt. Das Vorlese-Widget liest fröhlich den sichtbaren Text vor und ändert nichts davon. Die Kundin kann den Marketingtext hören, aber keinen Kauf abschließen. Diese Lücke – zwischen dem Hören von Inhalten und dem Bedienen eines Produkts – ist der gesamte Unterschied zwischen einem Komfortmerkmal und Barrierefreiheit.

Was die Entwicklung für Screenreader tatsächlich erfordert

Screenreader zu unterstützen heißt nicht, eine Funktion hinzuzufügen – es heißt, Ihre Seiten so zu konstruieren, dass Bedeutung, Struktur und Verhalten für Software verfügbar sind, nicht nur für das menschliche Auge. Die Kernzutaten:

Semantisches, strukturiertes HTML

Verwenden Sie echte Überschriften (h1–h6) in logischer Reihenfolge, native Schaltflächen und Links für die richtigen Zwecke, Listen für Listen und Landmark-Elemente für Seitenbereiche. Semantisches HTML trägt Barrierefreiheitsinformationen kostenlos in sich; eine Wand aus generischen Containern trägt keine.

Textalternativen für Nicht-Text-Inhalte

Jedes bedeutungstragende Bild braucht einen treffenden Alternativtext, und dekorative Bilder sollten so markiert werden, dass sie übersprungen werden. Symbole, die als Schaltflächen fungieren, brauchen zugängliche Namen. Diagramme und Infografiken brauchen ein Textäquivalent, das dieselbe Information vermittelt.

Zugängliche Namen, Rollen und Zustände

Formularfelder brauchen programmatisch zugeordnete Beschriftungen. Benutzerdefinierte Komponenten – Tabs, Akkordeons, Comboboxen, Dialoge – brauchen die korrekten Rollen und Zustände, damit der Screenreader ansagt, was sie sind und wie sie sich verhalten. Wo natives HTML nicht ausreicht, schließt ARIA die Lücke, muss aber präzise eingesetzt werden; fehlerhaftes ARIA ist schlimmer als gar keines.

Tastaturbedienbarkeit und Fokusverwaltung

Alles, was mit der Maus funktioniert, muss mit der Tastatur funktionieren, die Fokusreihenfolge muss logisch sein, der Fokusindikator muss sichtbar sein, und dynamische Änderungen (Öffnen eines Dialogs, Anzeigen eines Fehlers) müssen den Fokus angemessen verschieben oder ansagen. Tastaturunterstützung und Screenreader-Unterstützung sind eng miteinander verwoben.

Ansagen dynamischer Änderungen

Wenn sich Inhalte ohne Neuladen der Seite aktualisieren – eine Formularvalidierungsmeldung, ein Warenkorbzähler, ein Ladezustand –, verwenden Sie Live-Regionen, damit der Screenreader dem Nutzer mitteilt, dass etwas passiert ist. Lautlose Aktualisierungen sind für Menschen, die den Bildschirm nicht sehen können, unsichtbar.

All diese Erwartungen sind in den Erfolgskriterien von WCAG 2.2 kodifiziert, die das technische Rückgrat des European Accessibility Act und des ADA in der Anwendung auf das Web bilden. Wenn Sie die praktischen Details wünschen, führt unser Leitfaden zum Screenreader-Testen Schritt für Schritt durch, wie Sie jedes dieser Verhaltensweisen mit echten Tools überprüfen.

Warum „bei mir wird es gut vorgelesen“ in die Irre führt

Ein sehender Entwickler kann eine Vorlese-Funktion einschalten, saubere Sätze hören und schließen, die Seite sei barrierefrei. Die Falle ist, dass das Vorlesen die sichtbare Lesereihenfolge und den sichtbaren Text wiedergibt, die beide für jemanden, der auf den Bildschirm schaut, bereits Sinn ergeben. Es sagt nichts darüber aus, ob ein benutzerdefiniertes Dropdown seine Optionen ansagt, ob der Fokus in einem geöffneten Dialog gefangen ist, ob eine reine Symbol-Schaltfläche einen Namen hat oder ob die Tab-Reihenfolge mit dem visuellen Layout übereinstimmt. Genau das sind die Dinge, die für Screenreader-Nutzer brechen, und genau die Dinge, die eine Vorlese-Demo nicht aufdecken kann. Der einzige Weg, es zu wissen, ist, so zu testen, wie es die tatsächlichen Nutzer tun.

Wie man auf beides testet – und warum Automatisierung allein nicht ausreicht

Sie können nicht bestätigen, dass eine Seite für Screenreader-Nutzer funktioniert, indem Sie einer Vorlese-Schaltfläche zuhören. Sie bestätigen es, indem Sie Struktur, Namen, Rollen, Zustände, Tastaturbedienung und die tatsächliche Screenreader-Erfahrung über mehrere Tools und Plattformen hinweg prüfen.

Ein solider Prozess kombiniert drei Ebenen:

Automatisiertes Scannen, um die zahlreichen, maschinell erkennbaren Probleme aufzuspüren – fehlender Alternativtext, leere Beschriftungen, defekte ARIA-Verweise, Kontrastfehler. Unsere Software zum Barrierefreiheits-Scanning und ein kostenloser Barrierefreiheits-Scan sind ein schneller Weg, um Ihren Ausgangspunkt zu bestimmen.
Manuelle Expertenprüfung, um alles zu bewerten, was die Automatisierung nicht beurteilen kann: ob ein Name aussagekräftig ist, ob die Fokusreihenfolge Sinn ergibt, ob ein benutzerdefiniertes Widget wirklich bedienbar ist. Die Begründung für diese Ebene behandelt unser Leitfaden zu manuellen Barrierefreiheits-Audits.
Tests mit echter assistiver Technologie und echten Nutzern. Nichts ersetzt das Steuern der Seite mit NVDA, JAWS, VoiceOver und TalkBack – und idealerweise das Beobachten von Menschen, die diese Tools täglich verwenden. Unsere Audits durch Menschen mit Behinderungen bringen genau diese gelebte Expertise ein.

Automatisierte Tools erkennen in der Regel nur einen Teil der Erfolgskriterien von WCAG 2.2; der Rest erfordert menschliches Urteilsvermögen. Einen bestandenen automatisierten Scan als Beweis für Barrierefreiheit zu behandeln, ist dieselbe Art von Fehler wie ein Vorlese-Widget als Screenreader-Unterstützung zu behandeln.

Wo QualiBooth ins Spiel kommt

QualiBooth testet Ihre Website gegen sowohl TTS- als auch Screenreader-Anwendungsfälle, damit Ihre Inhalte für Nutzer zugänglich sind, die sich auf eine der beiden Technologien verlassen – und damit die Menschen, die auf einen Screenreader angewiesen sind, Ihre Inhalte nicht nur hören, sondern Ihr Produkt tatsächlich bedienen können. Unser Barrierefreiheits-Toolkit und die Agora-Plattform verbinden Scannen mit strukturierter manueller Prüfung, und unser Team für Barrierefreiheits-Beratung hilft Ihnen, das zu beheben, was die Tests aufdecken, und die Anforderungen von WCAG 2.2, EAA und ADA zu erfüllen.

Das Fazit ist einfach. Ihren Inhalten eine Stimme zu geben, ist eine nette Geste. Ihre Inhalte navigierbar, bedienbar und korrekt für einen Screenreader angesagt zu machen, ist Barrierefreiheit – und nur eines davon erfüllt das Gesetz und die Menschen, die es schützt.