Generative KI und Screenreader-Prompts: eine Design-Disziplin entsteht

Bildbeschreibung: Ein Smartphone auf einem Holzschreibtisch mit einer KI-Chat-Oberfläche und angeschlossenen Kopfhörern — das visuelle Symbol für screenreader-freundliches KI-Prompt-Design.

Lesezeit: 9 Minuten

In der Barrierefreiheits-Community hat sich in den vergangenen achtzehn Monaten eine neue Design-Disziplin herausgebildet, die noch keinen etablierten Namen hat. Einige Teams nennen sie „AT-aware Prompt Engineering“; andere sprechen von „screenreader-geformten System-Prompts“; Praktizierende, die aus dem Voice-UI-Design kommen, bezeichnen sie eher als „die Sprachausgabeschicht eines LLM“. Unabhängig vom Label ist das Handwerk dasselbe: das Schreiben von System-Prompts und Ausgabe-Gestaltungsregeln, die generative KI-Assistenten — ChatGPT, Claude, Gemini, Copilot, Be My AI — für die rund ca. 253 Millionen Menschen weltweit nützlich machen, die diese Produkte über einen Screenreader erreichen.

Das Problem ist konkret und der Fehlermodus ist laut. Ein auf dem öffentlichen Web trainiertes LLM produziert standardmäßig Prosa, die mit Gedankenstrichen verziert ist, verschachtelte Markdown-Listen enthält, Code-Fences setzt, Überschriften erzeugt, die nur existieren, weil das Modell die Antwort für „strukturiert“ hielt, und dekorative Emoji einfügt. Vorgelesen von NVDA, JAWS, VoiceOver oder TalkBack verwandelt sich diese Ausgabe in einen Strom von „Strich-Strich“-Einschüben, „Punkt-Punkt-Punkt“-Aufzählungen ohne jedes Gespür dafür, wo ein Element endet, „Überschrift Ebene zwei“-Ankündigungen, die einen Satz unterbrechen, und Emoji-Namensstrings („lächelndes Gesicht mit Sonnenbrille“) zwischen jedem zweiten Satzteil. Die Information ist vorhanden. Der Nutzende kann sie nicht extrahieren, ohne dreimal zurückzuspulen. Dieser Beitrag ist ein Überblick darüber, was die Disziplin von Modellbauenden fordert, was die Produkte bislang ausgeliefert haben und welche offenen UX-Probleme noch niemand gelöst hat.

Die neue Disziplin — was sie konkret umfasst

Screenreader-bewusstes Prompt-Design ist keine einzelne Regel. Es ist eine kleine Menge von Einschränkungen, die zusammen eine Ausgabe erzeugen, die ein Synthesizer verständlich aussprechen kann und durch die eine Screenreader-Navigationstaste navigieren kann. Die Einschränkungen lassen sich in vier Kategorien einteilen.

Prägnante Antworten mit semantischer Struktur. Standard-LLM-Ausgaben sind für die gesprochene Wiedergabe zu lang — eine 600-Wörter-Antwort, die im Browser eines sehenden Nutzers gut lesbar ist, wird zu einem vierminütigen Monolog, den ein Screenreader-Nutzender nicht überfliegen kann. Die Disziplin fordert kürzere Antworten, vor allem aber strukturierte kürzere Antworten: eine einleitende Zusammenfassung in einem Satz, bei der gestoppt werden kann, gefolgt von einer Struktur, durch die der Screenreader per Überschrift oder Listenitem navigieren kann.

Gedankenstriche und andere vom Synthesizer falsch ausgesprochene Satzzeichen vermeiden. Der Gedankenstrich, der Halbgeviertstrich, die Parenthese, der Schrägstrich als Konjunktion, der ASCII-Trennstrich — all das wird entweder als Stille, als wörtliches „Strich“ oder als verwirrende Pause ausgegeben, die eine Phrase in der Mitte zerteilt. Die sich unter den großen Modellen herausbildende Konvention lautet: Komma und Punkt bevorzugen; den Doppelpunkt für die eine Stelle verwenden, an der er wirklich notwendig ist; niemals Gedankenstriche in Sprach-Kontext-Antworten; niemals ASCII-Trennlinien zur Abschnittstrennung.

Deklarieren, was eine Liste ist, was eine Überschrift ist, was Code ist. Synthetische Sprache hat keine visuelle Hierarchie. Eine Überschrift muss als „Überschrift“ angekündigt werden, eine Liste als „Liste mit N Elementen, Element eins“, Code als „Code“; das Modell muss entweder Strukturen ausgeben, die der Screenreader erkennt (HTML, ordentliches Markdown, das die Rendering-Oberfläche in ARIA umwandelt), oder die Struktur verbal ankündigen („Hier sind drei Optionen. Option eins: …“).

Kein Markdown-Durcheinander. Markdown ist in Ordnung, wenn die Rendering-Oberfläche es in semantisches HTML umwandelt. Markdown ist feindlich, wenn die Oberfläche die rohen Sternchen und Unterstriche anzeigt, weil der Screenreader dann vor jedem fetten Wort „Sternchen Sternchen“ ankündigt. Die Disziplin besteht darin, den Rendering-Kontext zu erkennen — Chat-UI mit Markdown-Rendering versus Terminal versus screenreader-gesteuerte Sprachoberfläche — und die Ausgabe entsprechend zu formen. Dasselbe Modell muss unterschiedliche Oberflächendarstellungen derselben Antwort erzeugen.

Was Screenreader von KI tatsächlich brauchen

Um die oben genannten Einschränkungen konkret zu machen, hilft ein Blick auf das tatsächliche Verhalten der vier Screenreader-/OS-Kombinationen, die das Feld dominieren: JAWS unter Windows, NVDA unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android. Sie sind nicht austauschbar, und ein Prompt, der für einen gute Ausgabe erzeugt, kann bei einem anderen unlesbar sein.

Navigation per Überschrift. Alle vier Reader stellen eine Überschriften-Navigationstaste bereit (H in JAWS und NVDA, Rotor in VoiceOver, der Reading-Control-Umschalter in TalkBack). Damit eine lange KI-Antwort navigierbar ist, muss das Modell echte semantische Überschriften ausgeben — entweder über eine Markdown-Rendering-Pipeline, die in <h2>/<h3> mit korrekter Ebenenverschachtelung konvertiert, oder über die eigene strukturierte Antwort-API der Chat-Oberfläche. Ein Modell, das seine Antwort „strukturiert“, indem es die ersten drei Wörter jedes Absatzes fettet, hat etwas erzeugt, das visuell strukturiert wirkt, für einen Screenreader aber völlig flach ist.

Navigation per Liste. Listen sind in der gesprochenen Ausgabe genau deshalb nützlich, weil der Screenreader die Anzahl ankündigt („Liste mit sieben Elementen“) und die Navigation per Listen-Element-Taste ermöglicht (I in NVDA, L in JAWS). Das funktioniert aber nur, wenn die Liste ein echtes <ul> oder <ol> ist. Eine „Liste“, die durch Ausgabe von Aufzählungszeichen am Anfang jeder Zeile ohne Listencontainer erzeugt wird, wird als normaler Prosatext mit einem unerklärten „schwarzer Kreis“- oder „Aufzählungszeichen“-Einschub auf jeder Zeile gelesen.

Abschnittsweise überspringen. Lange KI-Antworten — Erklärungen, Vergleiche, Code-mit-Kommentar, mehrstufige Anleitungen — benötigen eine Möglichkeit für Screenreader-Nutzende, zum gesuchten Abschnitt zu springen, ohne die Einleitung zu hören. Dies ist das einzige Stück, das sich am schwersten gut gestalten lässt, weil das Modell eine navigierbare Struktur erzeugen muss und die Chat-Oberfläche sie so rendern muss, dass das Betriebssystem sie der assistiven Technologie zugänglich macht, und der Screenreader so konfiguriert sein muss, dass er die Überschriften-Navigationstaste auf dieser Oberfläche nutzt. Alle drei Voraussetzungen scheitern in der Praxis; meist ist es die mittlere.

Aussprachehinweise. Synthetische Stimmen stolpern über Fachbegriffe, Akronyme mit gemischten Buchstaben, URLs, Code-Bezeichner, mathematische Notation und nicht-deutsche Namen. Ein gut gestaltetes Modell wird bei Screenreader-Kontext-Antworten Akronyme beim ersten Auftreten ausschreiben („WCAG, die Web Content Accessibility Guidelines — Richtlinien für barrierefreie Webinhalte“), Initialismen expandieren, die der Synthesizer nicht aussprechen kann, und rohe URLs nicht in fließenden Prosatext einbetten, wo der Synth die Schrägstriche laut liest. Keines der großen Produkte tut dies 2026 durchgängig.

Wie die Produkte damit umgehen

Mitte 2026 haben die großen generativen KI-Produkte sichtbar unterschiedliche Positionen zur screenreader-bewussten Ausgabe eingenommen. Keines hat es perfekt gelöst. Der Fortschritt ist schneller als vor zwölf Monaten, aber die Lücke zwischen dem Besten und dem Schlechtesten ist immer noch groß.

ChatGPT (OpenAI). Der Web-Client wird nun mit einem „Prägnant“-Modus-Umschalter ausgeliefert, der Standardantworten verkürzt und Markdown-Dekoration reduziert. Der 2024 eingeführte und 2025 wesentlich verbesserte Sprachmodus ist dem Nächsten, was ein großes Produkt einer screenreader-nativen Oberfläche bisher gebracht hat, am nächsten — weil er den visuellen Chat vollständig umgeht und eine gesprochene Antwort mit Stop-, Wiederhole- und „Nochmal sagen“-Geste liefert. Das Custom-Instructions-Feld erlaubt es Screenreader-Nutzenden, ihre Präferenzen einmal zu deklarieren und sitzungsübergreifend anzuwenden — das ist der nutzerseitige Workaround, auf den sich die Community eingependelt hat. Verbleibende Lücken: GPT-Modelle neigen standardmäßig zu gedankenstrichreicher Prosa, sofern nicht explizit angewiesen, und die im Markdown ausgegebene Überschriftenebene wird in der Chat-Oberfläche nicht immer korrekt in ARIA umgewandelt.

Claude (Anthropic). Claudes System-Prompt-Disziplin hat sich den oben beschriebenen Konventionen am weitesten angenähert. Das Modell ist 2026 im Vergleich zur GPT-Linie deutlich weniger gedankenstrichanfällig, gibt standardmäßig kürzere Antworten aus und reagiert gut auf System-Prompt-Anweisungen wie „Du sprichst mit einer Person, die einen Screenreader verwendet; verwende keine Gedankenstriche, bevorzuge kurze Absätze und verwende echte Überschriften oder nummerierte Listen, wenn Struktur benötigt wird.“ Die Claude.ai-Chat-Oberfläche rendert Markdown zu semantischem HTML mit korrekten Überschriftenebenen, was die Überschriften-Navigationstaste funktionsfähig macht. Sprachausgabe über Drittanbieter-Integrationen existiert, ist aber weniger ausgereift als ChatGPTs First-Party-Sprachmodus.

Gemini (Google). Die enge Integration mit TalkBack unter Android ist Geminis struktureller Vorteil; das Modell kann über Androids Barrierefreiheitsdienste an den Screenreader auf Betriebssystemebene übergeben werden, wie es die iOS- und Web-Konkurrenten nicht können. Der „Hey Google, frag Gemini…“-Flow auf barrierefreien Android-Geräten ist für einige Nutzende die natürlichste verfügbare KI-plus-Screenreader-Erfahrung. Verbleibende Lücken: die Web-Oberfläche überdekoriert weiterhin Antworten, die Überschriftenhierarchie in Geminis Web-Antworten ist inkonsistent, und das Modell neigt stärker zu dekorativen Emoji als seine Mitbewerber.

Be My AI (Be My Eyes + OpenAI). Dies ist das am stärksten eingegrenzte der vier Produkte — ein visueller Beschreibungsassistent, der GPT-4-Klasse-Vision-Modelle einsetzt, um Bilder und Umgebungen für blinde und sehschwache Nutzende zu beschreiben. Es ist auch das einzige Produkt auf dieser Liste, das von Beginn an für einen Screenreader-Nutzenden als primäres Publikum entwickelt wurde. Das Prompt-Design von Be My AI ist die klarste Demonstration des Feldes, wie AT-bewusste Ausgabe in der Praxis aussieht: Beschreibungen beginnen mit einer einzigen Zusammenfassung in einem Satz, bei der gestoppt werden kann, liefern auf Anfrage strukturierte Details und vermeiden räumliche Sprache („links“, „oben“), die sehenden Kontext für die Interpretation erfordert. Das Produkt ist 2026 nach wie vor die nächste Annäherung des Feldes an eine Referenzimplementierung in einem ausgelieferten Produkt.

Die übergreifende Beobachtung ist, dass die vier Produkte bei den einfachen Teilen Fortschritte erzielt haben — kürzere Antworten, weniger Gedankenstriche, ein Custom-Instructions-Feld — und bei den schwierigen Teilen kaum begonnen haben. Die schwierigen Teile folgen.

Offene UX-Probleme, die noch niemand gelöst hat

Die screenreader-bewusste Prompt-Design-Literatur konvergiert auf vier offene UX-Probleme, bei denen die richtige Antwort noch nicht bekannt ist. Keines davon ist ein Modell-Fähigkeitsproblem; alle sind Interaktionsdesign-Probleme, die zwischen dem LLM, der Chat-Oberfläche, dem Betriebssystem und dem Screenreader liegen.

Unterbrechbarkeit. Sehende Nutzende können eine LLM-Antwort in ca. zwei Sekunden überfliegen und entscheiden, ob sie sie lesen. Screenreader-Nutzende können das nicht. Wenn die Antwort falsch oder am Thema vorbei ist, müssen sie genug davon hören, um das zu wissen, und dann unterbrechen. Sprachmodi haben einen Stop-Knopf. Textmodi generell nicht — die Antwort wird gestreamt und der Screenreader kündigt sie beim Eintreffen als neuen Inhalt an, ohne dass es einen sauberen Weg gibt zu sagen „Höre auf zu generieren, das ist nicht, was ich gefragt habe.“ Die Be-My-AI-App handhabt das am besten; die Web-Chat-Clients am schlechtesten.

Letzte Antwort wiederholen mit wählbarer Granularität. Einen Screenreader zu bitten, die letzte Antwort erneut zu lesen, ist einfach, wenn die Antwort kurz ist. Es ist nicht nutzbar, wenn die Antwort sechs Absätze umfasst und die Nutzenden nur den dritten Absatz nochmals hören möchten. Die Interaktion, nach der die Community fragt, ist „letztes Listen-Element wiederholen“, „letzten Überschriftenabschnitt wiederholen“, „letzten Code-Block wiederholen“. Das erfordert, dass die Chat-Oberfläche die Struktur so an den Screenreader übergibt, dass dessen eigene Wiederholen-Befehle sie adressieren können. 2026 tut das keines der großen Produkte; Nutzende müssen die eigene zeilenweise Navigation des Screenreaders verwenden, was mühsam ist.

Abschnittsweise Navigation in der gesprochenen Ausgabe. Sprachmodi haben keine Überschriften-Navigationstaste. Nutzende hören eine vierminütige Antwort linear, ohne Möglichkeit, vom „Überblick“-Abschnitt zum „Details“-Abschnitt zu springen, ohne zeitlich zurückzuspulen. Die Interaktionsdesigns, die prototypisiert werden — eine gesprochene „Abschnittsliste“, durch die mit Pfeiltasten navigiert werden kann; ein „Gehe zu Abschnitt drei“-Sprachbefehl; ein „Nur Überschriften“-Modus — sind noch früh. Die „Mehr Details zu den Farben“-Folgefrage der Be-My-AI-App ist die nächste funktionierende Version davon in einem ausgelieferten Produkt.

Die AT-Übergabe-Frage — wann spricht die KI versus wann liest sie Inhalte laut vor? Dies ist die tiefste Design-Frage. Wenn Screenreader-Nutzende auf einer Webseite einen KI-Assistenten öffnen, wer spricht — die eigene Stimme der KI (TTS-Schicht) oder der installierte Screenreader der Nutzenden, der die Textausgabe der KI liest? Die beiden Stimmen haben unterschiedliche Einstellungen, unterschiedliche Sprechgeschwindigkeiten, unterschiedliche Aussprachehinweise, unterschiedliche Stop-und-Wiederholen-Gesten. Wenn zwei Systeme gleichzeitig versuchen, denselben Inhalt zu sprechen, entsteht nichts Brauchbares. Die sich herausbildende Konvention lautet: Sprachmodusgespräche nutzen die eigene TTS der KI und unterdrücken ausdrücklich den Screenreader; Textmodusgespräche geben semantisches HTML aus und überlassen das Sprechen dem Screenreader. Aber die Grenze zwischen den beiden Modi ist nicht immer klar — Bildbeschreibung, Code-Generierung, mathematische Notation und multimodale Antworten liegen alle unangenehm zwischen Sprache und Text — und genau an dieser Grenze leben die meisten aktuellen UX-Probleme.

Wie es weitergeht

Die Disziplin befindet sich etwa dort, wo Web-Barrierefreiheit ca. 2002 war — jenseits der „Ist das ein echtes Problem?“-Phase, jenseits der „Wer ist verantwortlich?“-Phase, in der „Was sind die tatsächlichen Regeln?“-Phase. Für 2026 und 2027 sind drei Entwicklungen wahrscheinlich.

Erstens werden die Modellbauenden ihre internen Screenreader-Prompts kodifizieren und veröffentlichen, so wie Anthropic Claudes System-Prompts in VPAT-ähnlichen Barrierefreiheitserklärungen veröffentlicht und OpenAI begonnen hat, die Verhaltensstandards von GPT zu dokumentieren. Die Community fordert das Äquivalent einer Model Card — eine „Screenreader-Output-Karte“ —, die die Konventionen benennt, die ein gegebenes Modell durch Training oder System-Prompting verfolgt.

Zweitens werden die Chat-Oberflächen — Web-Clients, Mobile-Apps, IDE-Integrationen — ordentliche semantische HTML-Rendering-Pipelines und ordentliche ARIA-Exposition für den Chat-Verlauf erhalten, mit den Navigationstasten, die auf den Screenreader des Betriebssystems abgebildet sind. Dies ist unspektakuläre Arbeit, und es ist die Arbeit, die den Unterschied für die täglichen Nutzenden am stärksten ausmachen wird.

Drittens werden die Screenreader-Anbieter selbst — Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack) — beginnen, KI-bewusste Funktionen auszuliefern: native Überschriften-Navigation innerhalb KI-Chat-Oberflächen, eine standardisierte „Generierung stoppen“-Geste, intelligentere Wiederholen-Befehle, die die LLM-Antwortstruktur kennen. Das Open-Source-Add-on-Ökosystem von NVDA bringt bereits frühe Versionen davon hervor. Die proprietären Reader sind langsamer, aber die Richtung ist dieselbe.

Die tiefere Beobachtung ist, dass screenreader-bewusstes Prompt-Design aufgehört hat, ein Nischenanliegen einiger weniger blinder Entwickler zu sein, und zur Grundvoraussetzung für jedes KI-Produktteam geworden ist, das in regulierten Märkten ausliefern will. Der European Accessibility Act (EAA) gilt für „interaktive Selbstbedienungsterminals“ und „Verbraucher-Terminal-Equipment mit interaktiver Rechenfähigkeit“ — eine Kategorie, die einen großen KI-Assistenten auf einem Smartphone mit an Sicherheit grenzender Wahrscheinlichkeit erfasst. Die AT-bewusste Ausgabeschicht ist keine Funktion mehr; sie ist vergaberechtlich bindend. Die Teams, die die Regeln jetzt herausarbeiten, werden die Produkte ausliefern, die ab dem 28. Juni 2025 und danach bestehen. Die Teams, die es als Nachgedanken behandeln, werden in der nächsten Runde von EAA-Durchsetzungsfällen auftauchen.

Abschließende Gedanken

Das Handwerk ist klein, die Einsätze sind hoch, und die Regeln werden noch geschrieben. Wer mit LLMs entwickelt und noch kein Gespräch mit einer Screenreader-Nutzerin oder einem Screenreader-Nutzer darüber geführt hat, wie sich das eigene Produkt bei deren Nutzung tatsächlich anhört, hat damit als Nächstes anzufangen. Das meiste, was mit KI für Screenreader-Nutzende 2026 nicht funktioniert, ist kein Modell-Fähigkeitsproblem; es ist ein Prompt-und-Oberflächen-Designproblem, das jedes Produktteam in einem Sprint beheben kann, wenn es sich dazu entscheidet.

Die Community ist großzügig mit ihrer Zeit, ihrem Testen und ihrer Geduld gewesen. Sie verliert diese Geduld auch schneller als früher, weil die Produkte inzwischen massentauglich sind und die Entschuldigung „Wir arbeiten noch daran“ aufgebraucht ist. Die Disziplin ist da. Die Konventionen konvergieren. Die nächsten achtzehn Monate werden die Teams, die zugehört haben, von denen trennen, die es nicht getan haben.