Sprachsteuerung: Kompatibilität mit Voice Control und Dragon NaturallySpeaking

1. Wer Sprachsteuerung im Web nutzt und warum

Sprachsteuerung im Browser wird von einer deutlich größeren und vielfältigeren Nutzergruppe verwendet, als viele Entwickler vermuten. Menschen mit dauerhaften motorischen Einschränkungen, etwa nach einer Querschnittlähmung oder bei ALS, nutzen Sprachsteuerung oft als primäres Eingabemedium für den gesamten Computer, nicht nur für Texteingabe. Daneben gibt es eine große Gruppe temporärer Nutzer, etwa Menschen mit einer Sehnenscheidenentzündung (RSI), einem gebrochenen Arm oder juristische und medizinische Fachkräfte, die aus Zeitgründen Diktiersoftware wie Dragon NaturallySpeaking im Berufsalltag einsetzen und dieselbe Software gelegentlich auch zur Web-Navigation nutzen.

Der entscheidende technische Unterschied zu Screenreadern: Sprachsteuerungssoftware liest in erster Linie den sichtbaren Text auf dem Bildschirm, nicht primär den Accessibility Tree. Voice Control unter macOS zeigt bei aktivierten 'Nummern anzeigen' zwar auch Overlay-Nummern für jedes klickbare Element an, der bevorzugte und schnellere Befehl bleibt aber 'Klicke [sichtbarer Text]'. Wenn dieser sichtbare Text fehlt, bleibt für den Nutzer nur der umständliche Weg über Nummern-Overlays, was die Bedienung erheblich verlangsamt und fehleranfälliger macht.

2. Wie Voice Control, Dragon und Windows Speech Recognition technisch navigieren

Alle drei großen Sprachsteuerungssysteme funktionieren nach einem ähnlichen Grundprinzip: Sie scannen die sichtbare Seite nach interaktiven Elementen, extrahieren deren sichtbaren Textinhalt oder den zugänglichen Namen und bauen daraus eine Befehlsliste auf, typischerweise in der Form 'Klicke [Text]' oder 'Click [Text]'. Dragon NaturallySpeaking geht dabei noch einen Schritt weiter und bietet den 'MouseGrid'-Modus als Fallback für Elemente ohne erkennbaren Text, aber dieser Modus ist deutlich langsamer als der direkte Befehl mit dem sichtbaren Label.

Wichtig zu verstehen: Diese Systeme bevorzugen konsistent den sichtbaren Text vor dem aria-label. Enthält ein Button sowohl sichtbaren Text als auch ein abweichendes aria-label, kann das zu einer verwirrenden Situation führen, die als WCAG-Erfolgskriterium 2.5.3 'Label in Name' bekannt ist: Ein Screenreader liest das aria-label vor, während der Sprachsteuerungs-Nutzer versucht, exakt den sichtbaren Text als Befehl zu sagen. Stimmen beide nicht überein, funktioniert der intuitive Sprachbefehl schlicht nicht.

3. Warum Icon-only-Buttons ohne sichtbaren Text scheitern

Ein Warenkorb-Icon, ein Lupe-Icon für die Suche oder ein Herz-Icon für die Wunschliste sind visuell selbsterklärend für sehende Maus-Nutzer, bieten aber keinerlei sichtbaren Text, den ein Sprachsteuerungssystem als Befehlswort extrahieren könnte. Selbst ein technisch korrektes aria-label="Warenkorb" löst das Problem nur teilweise: Es macht den Button für Screenreader zugänglich, aber Voice Control und Dragon zeigen dem Nutzer keinen Hinweis darauf, dass 'Klicke Warenkorb' der richtige Befehl wäre, weil auf dem Bildschirm nirgends das Wort 'Warenkorb' zu sehen ist.

Die Nutzer müssen in diesem Fall entweder erraten, wie das Element wohl benannt sein könnte, oder auf den umständlichen Nummern-Overlay-Modus ausweichen. Beides kostet Zeit und Nerven und macht aus einer einfachen Kaufabsicht eine frustrierende Trial-and-Error-Übung. Genau hier liegt der entscheidende Unterschied zur reinen Screenreader-Kompatibilität: Ein aria-label allein macht ein Interface zwar technisch zugänglich, aber nicht sprachsteuerungsfreundlich.

<!-- Problematisch: aria-label vorhanden, aber kein sichtbarer Text.
     Voice-Control-Nutzer sehen nirgends das Wort "Warenkorb". -->
<button type="button" aria-label="Warenkorb">
  <svg class="h-5 w-5"><!-- Cart-Icon --></svg>
</button>

<!-- Besser: sichtbarer Text vorhanden, per sr-only nur bei Platzmangel
     zusätzlich verstärkt, niemals ersetzt -->
<button type="button">
  <svg class="h-5 w-5" aria-hidden="true"><!-- Cart-Icon --></svg>
  <span>Warenkorb</span>
</button>

4. WCAG 2.5.3 Label in Name: die konkrete Regel dahinter

WCAG 2.5.3 verlangt auf Stufe A, dass der zugängliche Name eines Elements, also der Name, der Screenreadern und Sprachsteuerungssoftware zur Verfügung steht, den sichtbaren Text enthält. Konkret bedeutet das: Ein Button mit sichtbarem Text 'Weiter' darf kein aria-label="Zum nächsten Schritt" tragen, weil der zugängliche Name dann nicht mehr den sichtbaren Text 'Weiter' enthält und ein Sprachsteuerungsnutzer, der 'Klicke Weiter' sagt, ins Leere läuft.

Erlaubt ist es hingegen, den sichtbaren Text um zusätzlichen Kontext zu ergänzen, solange der sichtbare Text als Teilstring erhalten bleibt, etwa aria-label="Weiter zu Schritt 2: Versand" für einen Button mit sichtbarem Text 'Weiter'. Der zugängliche Name beginnt oder enthält weiterhin exakt das Wort, das auf dem Bildschirm zu sehen ist, wodurch sowohl der Sprachbefehl als auch die zusätzliche Screenreader-Information funktionieren.

<!-- WCAG 2.5.3 verletzt: sichtbarer Text "Weiter" ist kein Teilstring
     des accessible name "Zum nächsten Schritt" -->
<button aria-label="Zum nächsten Schritt">Weiter</button>

<!-- WCAG 2.5.3 erfüllt: sichtbarer Text bleibt Teilstring des Namens -->
<button aria-label="Weiter zu Schritt 2: Versand">Weiter</button>

5. Typische Verstöße in Magento- und Hyvä-Frontends

In vielen Hyvä-Themes tauchen Label-in-Name-Verstöße an vorhersagbaren Stellen auf: Mini-Cart-Icon, Such-Icon, Wishlist-Herz, Mengen-Plus/Minus-Buttons und Paginierungspfeile werden häufig ausschließlich mit aria-label versehen, ohne begleitenden sichtbaren Text, weil das visuelle Design kompakt bleiben soll. Auch bei 'Weiter'- und 'Zurück'-Buttons im Checkout-Wizard kommt es vor, dass ein generisches aria-label wie 'Nächster Schritt im Checkout' verwendet wird, obwohl der sichtbare Button-Text schlicht 'Weiter' lautet.

Der Fix erfordert selten eine Design-Änderung. In den meisten Fällen reicht es, neben dem Icon einen kurzen sichtbaren Textlabel zu ergänzen, der bei Bedarf responsiv ausgeblendet wird, oder das aria-label so zu formulieren, dass es den sichtbaren Text als Präfix oder vollständig enthält statt ihn zu ersetzen.

<!-- Checkout-Wizard: sichtbarer Text bleibt Teil des accessible name -->
<button type="button" aria-label="Weiter zur Zahlungsart">
  Weiter
</button>

<!-- Mengen-Selector: Plus-Button mit sichtbarem Symbol UND Text -->
<button type="button" aria-label="Menge um 1 erhöhen">
  <span aria-hidden="true">+</span>
</button>

6. Sichtbare Labels responsiv verstecken, ohne sie aus dem DOM zu entfernen

Ein häufiges Missverständnis: Entwickler nutzen bei knappem Platz auf Mobilgeräten oft display: none, um Textlabels auszublenden und nur das Icon zu zeigen. Das entfernt den Text jedoch vollständig aus dem Accessibility Tree, wodurch der zugängliche Name verloren geht und die Situation wieder wie ein reiner Icon-only-Button wirkt, obwohl im Markup noch Text vorhanden ist.

Die korrekte Lösung nutzt visuelles Verstecken statt vollständiges Entfernen, etwa über eine sr-only-Klasse, die den Text nur für sehende Nutzer ausblendet, ihn aber im Accessibility Tree und damit für Sprachsteuerung und Screenreader erhält. Wichtig ist dabei: Sprachsteuerung greift auf den sichtbaren Text zu, nicht direkt auf den Accessibility Tree, daher hilft sr-only in erster Linie Screenreadern. Für echte Sprachsteuerungs-Kompatibilität auf mobilen Breakpoints sollte der Text nach Möglichkeit sichtbar bleiben, etwa verkleinert statt komplett versteckt, oder zumindest über ein Tooltip-Pattern mit title-Attribut ergänzt werden.

/* Text bleibt im Accessibility Tree, ist aber visuell versteckt --
   hilft Screenreadern, aber NICHT Voice-Control-Nutzern, die den
   sichtbaren Bildschirminhalt scannen */
.sr-only {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

7. Formularfelder: sichtbare Labels statt reinem Placeholder

Dasselbe Grundproblem betrifft Formularfelder, die nur mit einem Placeholder-Text statt einem echten label-Element versehen sind. Ein Sprachsteuerungsnutzer, der 'Klicke E-Mail-Adresse' sagt, um in ein Feld zu springen, findet keinen Treffer, wenn der Placeholder 'ihre.email@beispiel.de' lautet statt eines echten Labels 'E-Mail-Adresse'. Placeholder-Text verschwindet zudem beim Fokussieren, was ohnehin ein bekanntes UX-Problem ist, unabhängig von Sprachsteuerung.

Ein sichtbares label-Element, korrekt per for-Attribut oder Verschachtelung mit dem Eingabefeld verknüpft, löst beide Probleme gleichzeitig: Es bleibt dauerhaft sichtbar und bietet Sprachsteuerungssoftware einen klaren, stabilen Befehlstext, der nicht verschwindet, sobald der Nutzer beginnt zu tippen oder zu diktieren.

8. Kompatibilität mit Sprachsteuerung testen

Auf macOS lässt sich Voice Control unter Systemeinstellungen, Bedienungshilfen aktivieren und direkt gegen die eigene Seite testen, ohne zusätzliche Software zu installieren. Der einfachste Testablauf: Alle wichtigen Interaktionen der Seite, Warenkorb öffnen, Suche starten, Produkt zur Wunschliste hinzufügen, ausschließlich per Sprachbefehl mit dem sichtbaren Text durchführen, ohne auf den Nummern-Overlay-Modus auszuweichen.

Für Windows-Umgebungen bietet die eingebaute Windows Speech Recognition eine kostenlose Testmöglichkeit, während Dragon NaturallySpeaking als kommerzielle Software vor allem in professionellen Kontexten wie Kanzleien oder Arztpraxen verbreitet ist und ein vollständiger Test damit meist nur stichprobenartig möglich ist. Automatisierte Tools wie axe-core prüfen WCAG 2.5.3 zuverlässig als eigene Regel und sollten in jede CI-Pipeline als erste Verteidigungslinie eingebaut werden, bevor ein manueller Voice-Control-Test erfolgt.

9. Praktische Checkliste für Sprachsteuerungs-Kompatibilität

Fünf Punkte lassen sich in jedem Code-Review prüfen: Erstens, enthält jedes interaktive Element sichtbaren Text oder einen zugänglichen Namen, der den sichtbaren Text als Teilstring enthält. Zweitens, werden Icon-only-Buttons nach Möglichkeit um sichtbaren Text ergänzt statt ausschließlich mit aria-label versehen. Drittens, wird display: none niemals genutzt, um aus Platzgründen Text zu verstecken, der eigentlich Teil des accessible name bleiben soll.

Viertens, nutzen Formularfelder echte label-Elemente statt ausschließlich Placeholder-Text. Fünftens, wird bei jeder neuen interaktiven Komponente ein automatisierter axe-core-Check gegen die Regel 'label-content-name-mismatch' ausgeführt, die genau WCAG 2.5.3 abdeckt und Verstöße bereits vor dem manuellen Test aufdeckt.

10. Zusammenfassung

11. FAQ: Sprachsteuerung-Kompatibilität: Das Wichtigste auf einen Blick