Sprachsteuerung: Dragon, Voice Control & Voice Access

Sprachsteuerung klickt nicht auf Pixel, sondern auf Namen: Wer „Klicke Warenkorb“ sagt, lässt die Software nach einem Bedienelement suchen, dessen zugänglicher Name zum gesprochenen Wort passt. Deshalb hat diese Technik die vielleicht überraschendste Anforderung an dein HTML – sichtbare Beschriftung und technischer Name müssen zusammenpassen, sonst existiert die Schaltfläche für den Befehl nicht.

Das Wichtigste in Kürze

• Nutzer sind Menschen, die ihre Hände nicht oder nur eingeschränkt einsetzen können – nach Unfällen, bei Muskelerkrankungen, Lähmungen, starkem Tremor oder chronischen Sehnenscheidenproblemen. Dazu kommen alle, die aus Zeit- oder Schmerzgründen diktieren.
• Die drei relevanten Programme: Dragon (Windows, kommerziell), Voice Control (macOS, iOS, iPadOS) und Voice Access (Android) – die beiden letzten sind im System enthalten und kosten nichts.
• Drei Bedienwege decken fast alles ab: beim Namen rufen, Nummern-Overlay einblenden, im Notfall das Bildschirmraster.
• Zentrales Kriterium ist WCAG 2.5.3 „Beschriftung im Namen“ auf Stufe A: Der sichtbare Text muss im zugänglichen Namen enthalten sein.
• Die häufigste Fehlerquelle ist gut gemeintes ARIA: Ein aria-label ersetzt den sichtbaren Text, statt ihn aufzunehmen – danach findet kein Sprachbefehl das Element mehr.
• Ein klickbares <div> ohne Rolle taucht im Nummern-Overlay nicht auf. Sprachsteuerung prüft damit unbestechlich, ob deine interaktiven Elemente echte Elemente sind.
• Praxisbefund aus deutschen Tests: Dragon verlangt in Kombination mit Chrome den vollständigen zugänglichen Namen, nicht nur die sichtbare Beschriftung – identische Namen sind deshalb sicherer als bloß enthaltene.
• Testen kostet nichts: Voice Control am Mac oder Voice Access am Android-Gerät einschalten und die eigenen Kernabläufe per „Klicke …“ durchspielen.

Die Werkzeuge

Wichtig fürs Verständnis: Sprachsteuerung tritt selten allein auf. Viele Nutzer kombinieren sie mit Bildschirmvergrößerung, mit einer Restnutzung der Tastatur oder mit einer Kopfmaus. Wer für motorische Einschränkungen baut, baut deshalb fast immer für mehrere Techniken gleichzeitig.

Wie per Stimme geklickt wird

1. Beim Namen rufen. „Klicke Warenkorb“ – die Software durchsucht den Accessibility Tree nach einem Bedienelement, dessen zugänglicher Name zum gesprochenen Wort passt, und löst es aus. Das ist der schnellste Weg und der, den alle bevorzugen.

2. Nummern-Overlay. Auf Kommando („Zeige Nummern“, „Show numbers“) blendet die Software über jedem erkannten Bedienelement eine Nummer ein – „Klicke 14“. Der Haken: Nummern bekommt nur, was als interaktiv erkennbar ist. Echte Buttons und Links tauchen auf, klickbare <div>s nicht.

3. Raster-Modus. Die Notlösung: Der Bildschirm wird in nummerierte Zonen geteilt, die sich nach jedem Befehl weiter unterteilen, bis der Zeiger auf dem Ziel steht. Drei bis vier Schritte für einen einzigen Klick – mühsam, aber der letzte Ausweg bei Oberflächen, die nichts preisgeben.

Die Falle: wenn aria-label den Namen überschreibt

Am häufigsten scheitert Sprachsteuerung ausgerechnet an gut gemeintem ARIA.

<!-- Falsch: sichtbar steht „Jetzt kaufen“, technisch heißt es „Zur Kasse gehen“.
     „Klicke Jetzt kaufen“ findet nichts. -->
<button aria-label="Zur Kasse gehen">Jetzt kaufen</button>

<!-- Auch falsch: Icon-Button, dessen Name nichts mit dem Symbol zu tun hat -->
<button aria-label="Konfigurationsdialog öffnen">
  <svg><use href="#icon-zahnrad"></use></svg>
</button>

<!-- Richtig: der zugängliche Name ist der sichtbare Text -->
<button>Jetzt kaufen</button>

<!-- Richtig: Icon-Button heißt so, wie man das Symbol benennen würde -->
<button aria-label="Einstellungen">
  <svg aria-hidden="true" focusable="false"><use href="#icon-zahnrad"></use></svg>
</button>

Das Prinzip regelt WCAG 2.5.3 „Beschriftung im Namen“: Der sichtbare Text muss im zugänglichen Namen enthalten sein. Am sichersten ist es, wenn beide identisch sind – und zwar aus einem praktischen Grund.

Randnotiz – „enthalten“ reicht nicht immer. In deutschen Praxistests zeigte sich, dass Dragon zusammen mit Chrome den vollständigen zugänglichen Namen erwartet, nicht nur den sichtbaren Anteil. Bei aria-label="Suche starten" auf einem Button mit dem Text „Suchen“ ist die WCAG formal erfüllt – gesagt werden muss trotzdem „Klicke Suche starten“. Wer sich Diskussionen sparen will, macht sichtbaren Text und Namen gleich.

Wenn ein aria-label unvermeidbar ist, gehört der sichtbare Text an den Anfang: aria-label="Jetzt kaufen – Warenkorb mit 3 Artikeln" funktioniert, umgekehrt nicht.

Wo Sprachsteuerung sonst noch scheitert

Fünfmal „Mehr“ auf einer Seite. Wenn mehrere Elemente denselben Namen tragen, fragt die Software nach oder nummeriert durch – jedes Mal ein zusätzlicher Schritt. Das ist derselbe Grund, aus dem Linktexte ihr Ziel benennen sollen.

Platzhalter statt Label. „Gehe zu E-Mail“ funktioniert nur, wenn das Feld einen zugänglichen Namen hat. Ein grauer Text im Feld ist keiner – siehe Labels und Beschriftungen und 3.3.2.

<!-- Falsch: kein Name, das Feld ist per Sprache nicht ansprechbar -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- Richtig: sichtbares Label, damit „Gehe zu E-Mail-Adresse“ funktioniert -->
<label for="mail">E-Mail-Adresse</label>
<input id="mail" type="email" name="mail" autocomplete="email">

Einzeltasten-Kürzel. Wer diktiert, erzeugt laufend Buchstaben. Reagiert die Seite auf ein einzelnes „s“ mit dem Öffnen der Suche, wird jedes Diktat zum Glücksspiel. Deshalb verlangt 2.1.4, dass solche Kürzel abschaltbar, umbelegbar oder nur bei Fokus aktiv sind.

Text in Grafiken. Was als Bild vorliegt, hat keinen Namen zum Rufen. Eine Schaltfläche als PNG mit eingebranntem „Jetzt buchen“ ist per Stimme unerreichbar – und verstößt nebenbei gegen 1.4.5 Bilder von Text.

Selbstgebaute Auswahlfelder. Ein Dropdown aus <div>s mit JavaScript hat weder Rolle noch Zustand. Voice Control kann es weder anspringen noch aufklappen – das native <select> oder ein korrekt ausgezeichnetes Custom-Control löst das.

So testest du es

1. Voice Control einschalten – macOS: Systemeinstellungen → Bedienungshilfen → Sprachsteuerung. Auf dem iPhone unter Bedienungshilfen → Sprachsteuerung, unter Android heißt es Voice Access.
2. Sag „Zeige Nummern“ auf deiner Startseite. Bekommt jedes Bedienelement eine Nummer? Was ohne Nummer bleibt, ist für die Sprachsteuerung nicht vorhanden.
3. Rufe fünf Elemente beim Namen – so, wie sie beschriftet sind: „Klicke Warenkorb“, „Klicke Kontakt“. Was nicht reagiert, hat einen abweichenden zugänglichen Namen.
4. Bediene ein Formular per Stimme: „Gehe zu E-Mail-Adresse“, diktieren, „Klicke Absenden“. Jedes Feld ohne Label fällt hier sofort auf.
5. Prüfe den Namen im Zweifel technisch: DevTools → Elemente → Barrierefreiheit; dort steht der berechnete Name. Weicht er vom sichtbaren Text ab, ist 2.5.3 in Gefahr.
6. Diktiere einen längeren Text in ein Suchfeld deiner Seite. Passiert dabei etwas Unerwartetes, hast du irgendwo ein Einzeltasten-Kürzel.

Häufiger Fehler in der Praxis

Der Designer benennt, der Entwickler beschriftet. Im Design heißt die Schaltfläche „Jetzt kaufen“, im Ticket steht „Checkout-Button“, im Code landet aria-label="Checkout". Niemand hat etwas falsch gemacht, und trotzdem findet kein Sprachbefehl das Element. Ich würd den sichtbaren Text deshalb als verbindlich behandeln – er ist der Name, alles andere ist Ergänzung.

Icon-Buttons nach Funktion statt nach Aussehen benannt. Das Zahnrad heißt „Einstellungen“, nicht „Konfigurationsdialog öffnen“. Nutzer sprechen aus, was sie sehen, nicht was das Team intern nennt.

title statt Label. Das title-Attribut liefert zwar manchmal einen Namen, ist aber auf Touch unsichtbar, für Tastaturnutzer schwer erreichbar und in der Namensberechnung ganz hinten. Es ersetzt kein Label.

Zu lange Namen. aria-label="Weitere Informationen zu unserem Angebot für Geschäftskunden anzeigen" muss vollständig gesprochen werden. Kurz und eindeutig schlägt ausführlich.

Nur mit Screenreader getestet. Ein Screenreader liest den Namen vor und ist damit zufrieden. Sprachsteuerung muss ihn treffen – das ist die härtere Prüfung, und sie deckt Abweichungen auf, die beim Zuhören niemandem auffallen.

Häufige Fragen

Betrifft mich das auch ohne „Klicke“-Nutzer – Stichwort Siri und Alexa?

Ja. Sprachassistenten, die Webinhalte vorlesen oder Aktionen ausführen, hängen an derselben Maschinenlesbarkeit: saubere Struktur, eindeutige Namen, strukturierte Daten. Die Arbeit zahlt doppelt – einmal für Barrierefreiheit, einmal für die Auffindbarkeit in KI-Antworten.

Wie teste ich Sprachsteuerung ohne Dragon-Lizenz?

Mit Bordmitteln. Voice Control gibt es auf jedem Mac und iPhone, Voice Access auf jedem aktuellen Android-Gerät – beide kosten nichts und decken die beiden wichtigen Mechanismen ab, Namensbefehl und Nummern-Overlay. Fünf Minuten reichen, um zu sehen, wo Namen und Beschriftungen auseinanderlaufen.

Muss der zugängliche Name exakt dem sichtbaren Text entsprechen?

Die WCAG verlangt nur, dass der sichtbare Text im Namen enthalten ist – und zwar möglichst am Anfang. In der Praxis ist Gleichheit sicherer, weil manche Kombinationen aus Programm und Browser den vollständigen Namen erwarten. Wenn du ergänzen musst, dann hinten anhängen, nie voranstellen.

Gilt 2.5.3 auch für Bilder und Überschriften?

Nein, das Kriterium betrifft nur Bedienelemente mit sichtbarem Text – Schaltflächen, Links, Formularfelder, Tabs. Ein Bild braucht einen Alt-Text, aber keinen Namensabgleich, weil man es nicht anklickt.

Was ist mit Elementen, die nur ein Symbol zeigen?

Die brauchen einen Namen, den man erraten kann. Faustregel: Wie würde jemand das Symbol laut nennen? Lupe → „Suche“, Papierkorb → „Löschen“, Zahnrad → „Einstellungen“. Noch besser ist eine sichtbare Beschriftung neben dem Symbol – die hilft zusätzlich allen, die Symbole nicht sicher deuten (Kognition und Neurodiversität).

Verwandte Themen

• Motorische Einschränkungen – wer aus welchen Gründen zur Stimme greift
• Tastatur- und Switch-Bedienung – die Schnittstelle, auf der auch Sprachsteuerung aufsetzt
• Screenreader im Überblick – derselbe Accessibility Tree, anderes Ziel
• Buttons vs. Links – warum ein <div> im Nummern-Overlay fehlt
• Labels und Beschriftungen – Formularfelder ansprechbar machen
• Erste Regel von ARIA – natives HTML löst das meiste von selbst

Quellen

• Understanding SC 2.5.3 Label in Name (W3C – Anforderung, Beispiele und Ausnahmen)
• Sprachsteuerung auf dem Mac verwenden (Apple – Befehle, Nummern- und Rastermodus)
• Erste Schritte mit Voice Access (Google – Sprachbefehle unter Android)
• Digitale Barrierefreiheit und Spracheingabe (fronta11y – Praxistest mit Dragon und Chrome)
• Accessible Name and Description Computation (W3C – Rangfolge bei der Namensermittlung)