/docs · HearLab · Practical

Live Caption auf Android: was es leistet und was nicht

Googles Live Caption ist die weltweit meistgenutzte Barrierefreiheitsfunktion. So funktioniert sie wirklich und das deckt sie nicht ab.

Live Caption von Android ist eine systemweite Funktion, die auf dem Gerät abgespielte Audio transkribiert. Sie arbeitet offline mit Spracherkennung direkt auf dem Gerät (eine quantisierte Version von Googles ASR-Modellen). Sie wird täglich von Dutzenden Millionen Menschen genutzt und ist wahrscheinlich das wirkungsvollste Barrierefreiheits-Release des letzten Jahrzehnts.

Sie wird auch häufig missverstanden. Hier folgt die Sicht der praktizierenden Entwicklerin auf das, was sie leistet, was sie nicht leistet und was das bedeutet, wenn du Werkzeuge zur Hörunterstützung baust.

Was Live Caption erfasst

Audio, die über die Media- oder VoiceCall-Streams von Android geleitet wird.
Audio von Systemtönen, Browser-Tabs, Video-Apps und den meisten Musik-Apps.
In Echtzeit, auf dem Gerät, ohne Netzwerk-Umweg.

Das ist ein weites Netz. YouTube schauen, telefonieren, einen Podcast hören, ein TikTok mit Ton öffnen: all das wird automatisch untertitelt.

Was sie nicht erfasst

Das Mikrofon. Live Caption ignoriert das Mikrofon. Es geht darum, was dein Telefon abspielt, nicht darum, was um dich herum passiert.
Räumliche Audio-Hinweise. Sie transkribiert Wörter. Musik, Raumklang, Umgebungsgeräusche: all das wird weggelassen oder schlicht beschriftet (“[Musik]”, “[Applaus]”).
Sprachen außerhalb der unterstützten Auswahl. Die Liste der unterstützten Sprachen ist gewachsen, bildet aber nach wie vor nur einen Bruchteil der weltweit gesprochenen Sprachen ab.
Die Identität von Sprechenden in Gruppenanrufen. Sie transkribiert, aber sie diarisiert nicht. Du siehst kein “Alex:” oder “Mia:”, du siehst nur Text.

Die Mikrofon-Lücke ist die entscheidende. Wenn du die Welt um dich herum untertiteln willst (ein Restaurant, ein Meeting), brauchst du einen separaten Ablauf, meist eine Drittanbieter-App mit ausdrücklicher Mikrofonberechtigung, manchmal mit Cloud-ASR für mehr Genauigkeit.

Was das für HearLab bedeutet

Der Untertitelmodus von HearLab ist ausdrücklich ein Mikrofon-Untertitelmodus. Wir versuchen nicht, Live Caption zu ersetzen. Google hat das für die Medienwiedergabe besser gelöst, als wir es je könnten. Wir versuchen das zu leisten, was Live Caption nicht leistet: den Raum um die Nutzerin herum zu untertiteln.

Diese Entscheidung hat Konsequenzen:

Wir brauchen die Mikrofonberechtigung, was bedeutet, dass wir die ausdrückliche Zustimmung der Nutzerin und eine klare UX darum herum benötigen.
Cloud-ASR steht zur Debatte. Modelle auf dem Gerät können viel, aber Cloud-ASR (Whisper, Deepgram, Googles STT API) ist für verrauschte Audio aus der realen Welt nach wie vor spürbar besser.
Das Privacy-Framing zählt. Eine App mit aktivem Mikrofon, die Audio in eine Cloud schickt, muss sehr klar machen, was sie tut, wann und wie lange. Standardmäßig deaktiviert und eine ausdrückliche Aufnahme-UI sind nicht verhandelbar.

Was Live Caption gut macht und wovon wir lernen sollten

Latenz: Das Modell auf dem Gerät liefert in unter einer Sekunde einen ersten Textentwurf. Alles, was langsamer ist, zerstört die Illusion von “Untertiteln”.
Elegant unsicher sein: Bei geringer Konfidenz zeigt Live Caption hellere, kleinere Schrift. Die Nutzerin erkennt, dass es eine Vermutung ist. Wir machen es in HearLab genauso: vorläufige Ergebnisse werden kursiv dargestellt, finalisierte Ergebnisse in der normalen Schriftstärke.
Inline-Korrektur: Wenn mehr Kontext eintrifft, können sich frühere Wörter aktualisieren. Das erfordert eine UI, die Nutzerinnen nicht dafür bestraft, “live” mitzulesen. Der Cursor bleibt ungefähr dort, wo das Auge ist, nicht dort, wo der Text neu gerendert wird.

Einen Untertitelmodus im Browser bauen

Für die HearLab-Companion-Demo verwenden wir die Web Speech API (SpeechRecognition). Das ist im Wesentlichen Googles Cloud-ASR, über Chrome/Edge zugänglich gemacht, mit einem gewissen On-Device-Fallback in Safari. Es ist der richtige Ausgangspunkt zum Prototyping, weil:

Es sich in einer Zeile einrichten lässt.
Es vorläufige und finale Ergebnisse von Haus aus verarbeitet.
Es den kontinuierlichen Modus unterstützt.

Es ist der falsche Endpunkt für die Produktion, weil:

Es ein kostenloser, vom Browser vermittelter Pfad ohne SLA ist.
Der Lebenszyklus fragil ist: der Erkenner stoppt auf manchen Plattformen nach wenigen Minuten geräuschlos.
Du keine Kontrolle darüber hast, welches Modell verwendet wird.

Für einen produktiven HearLab-Companion ist Whisper (auf einem Backend laufend) oder Deepgram die richtige Wahl. Die Web Speech API bringt uns durch die Prototypphase, ohne dass wir Infrastrukturentscheidungen treffen müssen, bevor sie nötig sind.