NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grünes Mikrofon sendet Sprachwellen auf ein Schild mit der Aufschrift Diktieren

Diktieren (Dictation): Spracheingabe statt Tastatur

Diktieren bezeichnet die Eingabe von Text per Stimme. Gesprochene Sprache wird dabei in Echtzeit in geschriebenen Text umgewandelt, ohne Tastatur und ohne Maus.
Für Menschen mit motorischen Einschränkungen, chronischen Schmerzen, Sehbehinderung oder Legasthenie ist Diktieren oft der schnellste Weg zu einem längeren Text. Viele Nutzer kombinieren Diktat mit Voice Recognition für Befehle und mit Text to Speech für die Ausgabe.
Technisch liegt Diktieren zwischen Betriebssystem und Anwendung. Das System hört zu, erkennt Wörter und schreibt sie in das fokussierte Eingabefeld. Deine Website merkt davon meist nichts. Genau deshalb entscheidet die Qualität deines Markups darüber, ob Spracheingabe funktioniert oder scheitert: Ohne Semantic HTML, saubere Labels und funktionierende Keyboard Navigation bleibt der Diktierbefehl wirkungslos.
Inhalt

Diktieren mit NCA: Schnelle Hilfe vom Experten

Wir bauen Frontends, die mit Spracheingabe umgehen können. Unser Stack ist Astro, React und Vue auf Symfony und PHP, getestet mit Cypress und Cypress Cloud. Barrierefreiheit prüfen wir nicht am Ende, sondern in der Pipeline: axe, Lighthouse und echte Tastatur und Sprachtests gehören bei uns zum Build. Roland Golla arbeitet seit über 20 Jahren an Testing und Refactoring und bringt dieses Wissen in jedes Accessibility Projekt.
Passend dazu: Accessibility Webdesign für die Umsetzung, Axe DevTools und Cypress Accessibility Testing für automatisierte Prüfungen, Google Lighthouse Accessibility Audit für die erste Standortbestimmung, JavaScript ablösen für Barrierefreiheit und Performance beim Refactoring alter Komponenten und Frontend Development für den kompletten Umbau.
Barrierefreie Eingaben in deinem Projekt
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Wie Diktieren technisch funktioniert

Ein Diktiersystem besteht aus drei Teilen: Audioaufnahme, Spracherkennung und Textausgabe. Das Mikrofon liefert ein Signal, ein Modell erkennt darin Wörter, und das Ergebnis landet im aktiven Eingabefeld. Moderne Erkennung läuft über neuronale Modelle und arbeitet kontextabhängig. Das System korrigiert ein bereits geschriebenes Wort also nachträglich, wenn der Satz später eine andere Lesart nahelegt.
Der wichtigste Punkt für Entwickler: Das Diktat schreibt in das Feld, das gerade den Fokus hat. Fokusmanagement ist damit kein Randthema, sondern die Grundlage. Verliert dein Modal den Fokus oder setzt ein Skript ihn bei jedem Render neu, landet der diktierte Satz im Nichts.
Im Browser gibt es zusätzlich die Web Speech API. Sie erlaubt Spracheingabe direkt in der Anwendung, unabhängig vom Betriebssystem. Der Support ist uneinheitlich, Chrome und Edge liefern die Erkennung über Server des Herstellers. Für ein produktives Projekt ist das eine Ergänzung, kein Ersatz für die Diktierfunktion des Systems.
Code:
          

const Recognition = window.SpeechRecognition || window.webkitSpeechRecognition;

if (Recognition) {
  const recognition = new Recognition();
  recognition.lang = 'de-DE';
  recognition.interimResults = true;

  recognition.addEventListener('result', (event) => {
    const text = Array.from(event.results)
      .map((result) => result[0].transcript)
      .join('');

    document.querySelector('#notiz').value = text;
  });

  recognition.start();
}

Wichtig bei eigener Spracheingabe: Der Nutzer muss sie starten und stoppen können, der Status muss sichtbar und über ARIA auch für Screenreader lesbar sein. Ein Mikrofon, das ohne Hinweis mithört, ist weder barrierefrei noch datenschutzkonform.

Wer auf Diktieren angewiesen ist

Diktieren ist keine Komfortfunktion für unterwegs. Für viele Menschen ist es die einzige Möglichkeit, überhaupt Text zu erfassen.
  • Motorische Einschränkungen: Nach Schlaganfall, bei Tremor, Lähmung oder Arthritis ersetzt die Stimme Tastatur und Maus, oft zusammen mit alternativen Eingabegeräten.
  • Chronische Schmerzen und RSI: Wer nur begrenzt tippen kann, verteilt die Arbeit zwischen Stimme und Tastatur.
  • Legasthenie und Schreibschwierigkeiten: Sprechen ist oft flüssiger als Schreiben, das Ergebnis ist orthografisch sauberer.
  • Sehbehinderung und Blindheit: Diktat ergänzt den Screenreader, Eingabe per Stimme und Ausgabe per Sprache greifen ineinander.
  • Situative Einschränkungen: Ein gebrochener Arm, ein Kind auf dem Arm, Handschuhe im Winter. Universal Design denkt diese Fälle mit.
Diese Gruppen tauchen in den WCAG nicht als Zielgruppenliste auf, sondern in den Erfolgskriterien. Das Prinzip dahinter heißt Bedienbarkeit und gehört zu den vier Grundprinzipien POUR.

Diktierlösungen im Überblick

Lösung Plattform Besonderheit
Voice Access Windows 11 Diktat und Steuerung der Oberfläche über sichtbare Beschriftungen
Diktierfunktion und Sprachsteuerung macOS und iOS Diktat systemweit, Steuerung über Namen von Bedienelementen
Spracheingabe in Gboard Android Erkennung läuft auf neueren Geräten auch ohne Netz
Dragon Professional Windows Anpassbares Vokabular für Fachsprache, verbreitet in Medizin und Recht
Talon Voice Windows, macOS, Linux Sprachsteuerung für Entwickler, frei konfigurierbare Befehlsgrammatik
Web Speech API Browser Spracheingabe in der Anwendung, Support je nach Browser unterschiedlich

Label in Name: die Regel, an der Spracheingabe scheitert

Wer per Stimme arbeitet, liest den sichtbaren Text vor und sagt zum Beispiel Klick Absenden. Das Werkzeug sucht dann ein Bedienelement, dessen zugänglicher Name diesen Text enthält. Stimmt der sichtbare Text nicht mit dem Namen im Code überein, findet der Befehl nichts.
Genau das regelt WCAG Erfolgskriterium 2.5.3 Label in Name auf Stufe A. Der häufigste Fehler ist ein aria-label, das etwas anderes sagt als der Button.
Code:
          

<!-- Falsch: der Sprachbefehl Klick Absenden findet diesen Button nicht -->
<button aria-label="Formular abschicken">Absenden</button>

<!-- Richtig: sichtbarer Text und zugänglicher Name passen zusammen -->
<button>Absenden</button>

<!-- Richtig, wenn zusätzlicher Kontext nötig ist -->
<button aria-label="Absenden und zur Übersicht">Absenden</button>

Dasselbe gilt für Formularfelder. Ein Platzhalter ist kein Label. Erst ein echtes label Element mit passendem for verbindet Text und Feld so, dass Diktat, Screenreader und Klick auf die Beschriftung funktionieren. Mehr dazu in Accessible Forms und in Barrierefreie Formulare.
Code:
          

<!-- Falsch: nur Platzhalter, kein Name für den Sprachbefehl -->
<input type="text" placeholder="Nachname">

<!-- Richtig -->
<label for="nachname">Nachname</label>
<input type="text" id="nachname" name="nachname" autocomplete="family-name">

Dazu kommt: Icons ohne Text sind für Sprachnutzer unsichtbar. Ein Mülleimer ohne Beschriftung lässt sich nicht ansagen. Wie du das löst, steht in Barrierefreie Icons im Webdesign und in Name, Rolle, Zustand.

Was deine Anwendung diktierfähig macht

Diktieren braucht keine eigene Schnittstelle. Es braucht eine Anwendung, die sich an die Grundregeln hält. Diese Punkte entscheiden in der Praxis:
  • Echte Elemente statt div: button, input, select und a bringen Rolle und Name mit. Ein div mit Klick Handler kann kein Sprachwerkzeug ansteuern.
  • Fokus nicht wegreißen: Kein automatischer Fokuswechsel während der Eingabe, kein Reset bei jedem Render.
  • Eingabe nicht abwürgen: Kein Timeout, das ein Formular nach 60 Sekunden verwirft. Diktieren und Korrigieren dauert länger als Tippen.
  • Validierung nach der Eingabe: Fehlermeldungen bei jedem Zeichen stören die Erkennung und den Nutzer.
  • Tastaturpfad muss stehen: Sprachwerkzeuge nutzen intern die Tastaturschnittstelle. Was mit Tab nicht erreichbar ist, ist auch per Stimme nicht erreichbar.
  • Keine Pflicht zu Gesten: Drag and Drop oder Wischen braucht immer eine einfache Alternative.
  • Kein CAPTCHA als Sperre: Wie du das löst, steht unter CAPTCHA.
Die Punkte klingen banal. In Legacy Projekten sind sie der Grund, warum Spracheingabe nicht läuft. Meist steckt zu viel JavaScript zwischen Nutzer und Formular. Wir gehen solche Stellen Schritt für Schritt an, erst Qualitätssicherung, dann Umbau, nachzulesen unter JavaScript ablösen.

Diktieren testen statt hoffen

Spracheingabe lässt sich nicht vollständig automatisiert prüfen. Ein großer Teil der Fehler ist aber messbar, weil er auf fehlende Namen und kaputte Semantik zurückgeht.
  • Automatisiert in der Pipeline: axe findet Buttons ohne Namen und Labels ohne Bezug. Wir binden das über Cypress und Cypress Cloud in jeden Lauf ein, Details unter Axe DevTools und Cypress.
  • Schneller Überblick: Ein Lighthouse Audit zeigt die grobe Lage, ersetzt aber keinen manuellen Test.
  • Fokusreihenfolge sichtbar machen: Mit taba11y siehst du, wo der Tastaturpfad bricht.
  • Manuell mit echter Stimme: Voice Access oder die Sprachsteuerung von macOS öffnen, Formular per Stimme ausfüllen und absenden. Fünf Minuten, die mehr zeigen als jeder Report.
  • Stichproben festlegen: Welche Seiten geprüft werden, regelt die repräsentative Stichprobentestung.
Wie das methodisch zusammenpasst, steht unter Accessibility Testing, die Werkzeugauswahl unter Accessibility Testing Tools und die formale Prüfung unter Accessibility Audit.

Datenschutz beim Diktieren

Diktieren verarbeitet Sprache, also personenbezogene Daten. Viele Systeme schicken das Audio an Server des Anbieters. In der Arztpraxis, in der Kanzlei oder in der Verwaltung ist das ein Thema für die Datenschutzfolgenabschätzung, nicht für die Produktseite.
Für eigene Produkte gilt bei uns eine klare Linie: Sprachverarbeitung läuft im eigenen Netzwerk. Erkennungsmodelle dieser Größenordnung sind klein genug, um lokal zu laufen, etwa über Ollama auf eigener Hardware. Wer gehostete Inferenz mit Auftragsverarbeitung in Deutschland braucht, findet die bei unserem Infrastrukturpartner Conversis in Duisburg.
Für die eigene Anwendung heißt das konkret: Mikrofonzugriff erst nach Aktion des Nutzers, sichtbarer Status während der Aufnahme, keine dauerhafte Speicherung des Audios und eine klare Angabe, wohin die Daten gehen.

Rechtlicher Rahmen: Spracheingabe ist keine Kür

Das Barrierefreiheitsstärkungsgesetz setzt den European Accessibility Act in deutsches Recht um. Betroffen sind unter anderem Onlineshops, Bankdienste, Ticketverkauf und E Books. Maßstab ist die harmonisierte Norm, die auf den WCAG aufsetzt.
Diktieren steht dort nicht als eigene Anforderung. Die Kriterien, an denen Spracheingabe scheitert, stehen sehr wohl drin: Beschriftungen, Name und Rolle von Bedienelementen, Bedienbarkeit ohne Maus. Wer diese Punkte erfüllt, bekommt Diktierfähigkeit praktisch geschenkt. Was das für Unternehmen bedeutet, steht unter Compliance in der Barrierefreiheit und unter Übergangsfristen für Onlineshops.

Speech recognition tools, although they are voice driven, depend on keyboard accessibility being available.

Léonie Watson, Director TetraLogical, Mitglied im W3C Advisory Board – The Informed Life, Episode 106

Diktieren im NCA Glossar weiterlesen

Spracheingabe hängt an Themen, die im Glossar einzeln beschrieben sind. Wer Diktieren sauber unterstützen will, liest am besten weiter bei Voice Recognition, Text to Speech und Alternative Eingabegeräte.
Die technische Grundlage liefern Semantic HTML, das Document Object Model, ARIA sowie Keyboard Navigation. Für die Struktur von Inhalten helfen Logische Reihenfolge, Lesereihenfolge und Barrierefreie Headlines.
Den größeren Rahmen spannen Digitale Barrierefreiheit, A11Y, Konformität und Robustheit. Verwandte Ausgabewege beschreiben Untertitel, Audiodeskription und Deutsche Gebärdensprache.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Häufige Fragen zu Diktieren

Die wichtigsten Fragen zu Spracheingabe, Diktierfunktionen und ihrer Umsetzung im Web.
Was ist Diktieren 2026 genau?

Diktieren ist die Eingabe von Text per Stimme. Ein Erkennungsmodell wandelt gesprochene Sprache in Zeichen um und schreibt sie in das Feld, das gerade den Fokus hat. Die Funktion steckt heute in jedem großen Betriebssystem und arbeitet mit neuronalen Modellen, die den Satzkontext berücksichtigen und einmal geschriebene Wörter nachträglich korrigieren.

Welche Diktiersysteme sind 2026 verbreitet?

Am weitesten verbreitet sind Voice Access unter Windows, die Diktierfunktion und Sprachsteuerung von macOS und iOS sowie die Spracheingabe in Gboard unter Android. In Medizin und Recht ist Dragon Professional mit anpassbarem Fachvokabular etabliert. Entwickler nutzen häufig Talon Voice, weil sich dort eigene Befehlsgrammatiken bauen lassen.

Muss meine Website 2026 Diktieren unterstützen?

Eine eigene Diktierfunktion verlangt kein Gesetz. Das Barrierefreiheitsstärkungsgesetz fordert aber Kriterien, ohne die Spracheingabe nicht funktioniert: eindeutige Beschriftungen, korrekte Namen und Rollen von Bedienelementen und vollständige Bedienbarkeit ohne Maus. Wer diese Punkte erfüllt, unterstützt Diktieren automatisch, ohne eine einzige Zeile Spracherkennung zu schreiben.

Wie teste ich Diktierfähigkeit 2026?

Automatisiert findet axe fehlende Namen und kaputte Label Bezüge, eingebunden in Cypress läuft das bei jedem Build mit. Den Rest macht ein manueller Test: Sprachsteuerung des Systems einschalten, ein Formular per Stimme ausfüllen und absenden. Fünf Minuten Handarbeit zeigen mehr Probleme als jeder automatisierte Report.

Läuft Spracherkennung 2026 auch ohne Cloud?

Ja. Erkennungsmodelle für Diktat sind klein genug für eigene Hardware und laufen zum Beispiel über Ollama im eigenen Netzwerk. Android und iOS erkennen auf neueren Geräten ebenfalls offline. Für Daten mit Personenbezug ist das der saubere Weg, weil kein Audio an fremde Server geht.

Was ist der Unterschied zwischen Diktieren und Voice Recognition?

Diktieren erzeugt Text, Voice Recognition steuert die Oberfläche. Beim Diktat wird alles Gesprochene geschrieben, bei der Sprachsteuerung löst ein Befehl eine Aktion aus, etwa das Klicken eines Buttons. In der Praxis stecken beide Modi im selben Werkzeug, und Nutzer wechseln ständig zwischen ihnen.

Warum findet der Sprachbefehl meinen Button nicht?

Meistens weicht der zugängliche Name vom sichtbaren Text ab. Ein aria-label mit anderem Wortlaut überschreibt die Beschriftung, und das Sprachwerkzeug sucht ins Leere. WCAG 2.5.3 Label in Name verlangt, dass der sichtbare Text im Namen enthalten ist. Icons ganz ohne Text sind aus demselben Grund nicht ansprechbar.

Reicht ein Platzhalter als Beschriftung für ein Feld?

Nein. Ein Platzhalter verschwindet bei der Eingabe, liefert keinen verlässlichen Namen und erzeugt oft zu schwachen Kontrast. Für Diktat und Screenreader braucht es ein echtes label Element mit passendem for Attribut. Der sichtbare Text ist gleichzeitig das Wort, mit dem Sprachnutzer das Feld ansteuern.

Kann Diktieren die Tastatur vollständig ersetzen?

Für viele Menschen ja, im Alltag arbeiten die meisten aber gemischt. Lange Fließtexte entstehen schneller per Stimme, präzise Korrekturen und Tabellenarbeit gehen oft über Tastatur oder alternative Eingabegeräte. Wichtig ist, dass die Anwendung beide Wege unterstützt und keinen davon erzwingt.

Wie genau ist Spracherkennung heute?

In ruhiger Umgebung und bei klarer Aussprache liegt die Erkennung nah an manueller Transkription. Schwieriger wird es bei starkem Dialekt, Hintergrundgeräuschen, mehreren Sprechern oder Fachbegriffen. Anpassbares Vokabular und Training auf die eigene Stimme heben die Trefferquote deutlich, ein Korrekturschritt bleibt trotzdem sinnvoll.

Funktioniert Diktieren in allen Sprachen?

Die großen Systeme decken Deutsch, Englisch und viele weitere Sprachen gut ab. Bei kleineren Sprachen und bei Dialekten nimmt die Qualität ab. Für mehrsprachige Anwendungen zählt zusätzlich ein korrektes lang Attribut im HTML, damit Erkennung und Sprachausgabe die richtige Sprache verwenden.

Wie aufwendig ist es, eine bestehende Anwendung diktierfähig zu machen?

Das hängt vom Zustand des Frontends ab. Saubere Formulare brauchen oft nur wenige Korrekturen an Labels und Namen. Steckt viel JavaScript zwischen Nutzer und Eingabe, wird daraus ein Refactoring mit Qualitätssicherung davor. NCA schätzt den Aufwand nach einem kostenlosen Kennenlernen und rechnet minutengenau ab.