Das Symptom
Die Sprachsteuerung läuft, sie hört zu, sie zeigt sogar an, dass sie etwas verstanden hat. Nur passiert nichts. „Auf Weiter tippen“ — nichts. Lauter sprechen — nichts. Langsamer sprechen — nichts. Der Knopf ist da, groß, mit einer Aufschrift, die man vorlesen kann. Beim nächsten Versuch landet der Satz plötzlich als Text im Suchfeld. Und irgendwann fängt man an, deutlicher zu artikulieren als je zuvor im Leben, und kommt sich dabei albern vor.
Die „Layer 8“-Wahrheit
Nicht die Aussprache ist das Problem, sondern der Name. Bedienelemente haben zwei davon: den, der draufsteht, und den, der hinterlegt ist. Die Sprachsteuerung hört auf den hinterlegten. Sichtbar ist der andere. Solange beide übereinstimmen, merkt niemand, dass es zwei sind — und genau deshalb fällt es beim Bauen nicht auf, wenn sie auseinanderlaufen.
Das W3C hat diesen Fall so präzise beschrieben, dass man ihn danach überall wiedererkennt. Stimmen sie überein, so das Verständnisdokument, können Spracheingabe-Benutzer navigieren, indem sie die sichtbaren Textbeschriftungen aussprechen. Stimmen sie nicht überein, scheitert der Versuch — und zwar nicht, weil die Erkennung schlecht wäre, sondern weil die gesprochene sichtbare Beschriftung nicht dem hinterlegten Namen entspricht, der als Sprachbefehl freigeschaltet ist. Das zugehörige Erfolgskriterium 2.5.3 verlangt deshalb, dass der Name den sichtbar dargestellten Text enthält. Es steht auf Stufe A, der untersten. Ein Knopf, der „Weiter“ zeigt und intern „Schritt 3 fortsetzen“ heißt, ist also kein Grenzfall, sondern ein glatter Verstoß.
Der praktische Ausweg ist verblüffend unbekannt: Man muss den echten Namen nicht erraten, man kann ihn sich anzeigen lassen. Apples Handbuch beschreibt es nüchtern — wer nicht sicher ist, wie ein Objekt zu nennen ist, lässt sich neben allen Objekten einen Namen oder eine Zahl einblenden und benutzt danach diese. „Namen anzeigen“, „Zahlen anzeigen“, „Textzahlen anzeigen“. Damit kippt die ganze Sache von Ratespiel auf Ablesen. Und nebenbei erhält man eine Fehlerdiagnose geschenkt: Überall dort, wo die eingeblendete Beschriftung nicht das zeigt, was danebensteht, sieht man den Verstoß mit eigenen Augen.
Für den Rest — Bilder, Karten, selbstgebaute Kacheln ohne jeden Namen — gibt es den zweiten Ausweg, und der arbeitet nicht mehr mit Bedeutung, sondern mit Geometrie. „Raster anzeigen“ legt ein nummeriertes Gitter über den Bildschirm; danach genügt „Tippen“ plus Nummer. Wird es zu ungenau, verfeinert das Nennen einer Rasternummer das Gitter in genau diesem Bereich. Das ist der Notausgang, der auch dann noch offen ist, wenn eine Anwendung sonst gar nichts richtig macht.
Die zweite große Ursache hat mit Namen überhaupt nichts zu tun, sondern mit dem Modus. Der Diktiermodus ist der Standard, und in ihm wird laut Handbuch alles zu Text, was kein Befehl ist. Wer eine Reihe von Anweisungen hintereinander absetzt, sieht deshalb die Hälfte davon im Textfeld landen. Der Befehlsmodus dreht das um: Nicht-Befehle werden ignoriert statt eingetippt. Und der Buchstabiermodus ist die Rettung für Passwörter und Webadressen, wo das wortweise Diktieren zwangsläufig scheitert. Drei Modi, ein Satz Umschaltbefehle — und ein großer Teil des Ärgers erledigt sich damit.
Bleibt die Einordnung, die erklärt, warum manches auch mit perfektem Namen nicht funktioniert. Spracheingabe ist keine eigene Eingabewelt; das W3C zählt sie ausdrücklich zu den Tastaturemulatoren, gemeinsam mit Blas-Saug-Steuerungen, Bildschirmtastaturen und Abtastverfahren. Was sich nur mit der Maus auslösen lässt, lässt sich also auch nicht sagen. Das ist eine unangenehme Nachricht und zugleich eine sehr nützliche: Wenn ein Element weder mit dem Tabulator erreichbar noch per Stimme ansprechbar ist, liegt es nicht an der Aussprache, nicht am Mikrofon und nicht am Raum. Es liegt daran, dass dieses Element für alles außer einen Zeiger nie vorgesehen war.