Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.
- Erstellt:
- Aktualisiert:
- Autor:
- Roland Golla
Was ist Voice Recognition?
Voice Recognition, auf Deutsch Spracherkennung oder Sprachsteuerung, ermöglicht es, Computer, Smartphones und Websites allein per Stimme zu bedienen. Nutzer sagen Befehle wie Klicke Anmelden, Scrolle nach unten oder Zeige Nummern, und das System führt sie aus.
Für Menschen mit motorischen Einschränkungen ist Sprachsteuerung oft der einzige Weg, digitale Angebote selbstständig zu nutzen. Dazu gehören Menschen mit Lähmungen, Muskelerkrankungen, Arthritis oder Verletzungen an Händen und Armen.
Wichtig ist die Abgrenzung zum Diktieren. Beim Diktieren wird Sprache zu Text. Bei der Sprachsteuerung wird Sprache zu Bedienung. Beide nutzen Spracherkennung, stellen aber unterschiedliche Anforderungen an eine Website.
Sprachsteuerung testen und reparieren mit NCA
Sprachsteuerung scheitert im Web selten an der Technik, sondern fast immer an fehlenden oder falschen Namen im Code. Genau darauf achten wir in Code Reviews, und wir bauen Bedienelemente konsequent aus nativen Elementen, die Sprachsteuerungen von Haus aus verstehen.
Wir bedienen eure Oberfläche selbst mit Voice Control und Voice Access und schauen, ob sich jedes Bedienelement über seinen sichtbaren Text ansprechen lässt. Wo nicht, korrigieren wir die Namen nach dem Prinzip Name, Rolle, Zustand, ersetzen Nachbauten durch semantisches HTML und räumen fehlerhaftes ARIA auf. Formulare bekommen sichtbare Labels nach dem Muster barrierefreier Formulare. Damit neue Buttons nicht wieder abweichen, läuft Label in Name danach als Test mit axe DevTools und Cypress in eurer Pipeline. Der Test mit Sprachsteuerung ist fester Teil unseres Accessibility Audit.
Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.
Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.
So funktioniert Sprachsteuerung im Web
Sprachsteuerung arbeitet mit dem, was auf dem Bildschirm sichtbar ist und was im Accessibility Tree steht. Nutzer haben drei Wege, ein Element zu erreichen:
- Per Name: Der Nutzer sagt den sichtbaren Text, etwa Klicke In den Warenkorb. Das System sucht ein Bedienelement mit genau diesem Namen.
- Per Nummer: Mit Zeige Nummern blendet das System neben jedem klickbaren Element eine Zahl ein. Der Nutzer sagt Klicke 12.
- Per Raster: Mit Zeige Raster wird der Bildschirm in Felder geteilt, die schrittweise verfeinert werden. Das ist der langsame Notfallweg.
Der schnelle und natürliche Weg ist der erste. Er funktioniert aber nur, wenn das Element einen zugänglichen Namen hat, der zum sichtbaren Text passt. Fehlt der Name oder weicht er ab, müssen Nutzer auf Nummern oder Raster ausweichen. Das kostet Zeit und Kraft.
Label in Name und vier weitere Kriterien
Mehrere Erfolgskriterien sorgen dafür, dass Websites per Stimme bedienbar sind. Das wichtigste ist das unscheinbare Kriterium 2.5.3.
- 2.5.3 Beschriftung im Namen (A): Der zugängliche Name eines Elements muss den sichtbaren Text enthalten, idealerweise am Anfang. Steht auf dem Button Suchen, darf das
aria-labelnicht Produktsuche starten lauten. - 2.1.1 Tastatur (A): Sprachsteuerung nutzt oft dieselben Wege wie die Tastatur. Was per Tastatur bedienbar ist, ist meist auch per Stimme erreichbar.
- 2.1.4 Tastaturkurzbefehle (A): Kürzel aus einzelnen Buchstaben müssen abschaltbar sein. Sonst lösen gesprochene Wörter versehentlich Aktionen aus.
- 4.1.2 Name, Rolle, Wert (A): Jedes Bedienelement braucht eine erkennbare Rolle und einen Namen.
- 2.5.8 Zielgröße, Minimum (AA): Neu in WCAG 2.2. Größere Ziele helfen auch bei der Bedienung per Nummern und Raster.
Sprachsteuerung im Überblick: Systeme 2026
Für Tests braucht ihr keine Spezialsoftware. Jedes große Betriebssystem bringt eine Sprachsteuerung mit. Die Tabelle zeigt, womit ihr am schnellsten startet.
Sprachsteuerungen im Vergleich
Sprachsteuerung im Code unterstützen: Beispiele
Label in Name einhalten. Der sichtbare Text muss im zugänglichen Namen stehen. Am einfachsten gelingt das, wenn ihr gar kein aria-label setzt und den sichtbaren Text wirken lasst.
<!-- Falsch: Nutzer sagt "Klicke Senden", nichts passiert -->
<button aria-label="Formular abschicken">Senden</button>
<!-- Richtig: sichtbarer Text ist der Name -->
<button type="submit">Senden</button>
<!-- Richtig: Ergänzung am Ende ist erlaubt -->
<button aria-label="Senden der Anfrage">Senden</button>
Icon Buttons beschriften. Ein Button nur mit Icon hat keinen sichtbaren Text. Nutzer raten dann, wie er heißt. Besser ist sichtbarer Text, mindestens aber ein eindeutiger Name.
<!-- Besser: Icon plus sichtbarer Text -->
<button type="button">
<svg aria-hidden="true">...</svg>
Suchen
</button>
Label in Name automatisch prüfen. Mit Cypress könnt ihr testen, ob das aria-label eines Buttons mit dem sichtbaren Text beginnt.
describe('Label in Name', () => {
it('aria-label beginnt mit dem sichtbaren Text', () => {
cy.visit('/')
cy.get('button[aria-label], a[aria-label]').each(($el) => {
const visible = $el.text().trim().toLowerCase()
const label = $el.attr('aria-label').toLowerCase()
if (visible) {
expect(label.startsWith(visible), label).to.be.true
}
})
})
})
Warum Befehle per Stimme ins Leere laufen
- aria-label weicht vom sichtbaren Text ab. Der häufigste Fehler. Nutzer sagen, was sie sehen, und nichts passiert.
- Icon Buttons ohne Namen. Ein Mülleimer Symbol ohne Beschriftung. Heißt es Löschen, Entfernen oder Papierkorb?
- Klickbare div Elemente. Ohne Rolle erkennt die Sprachsteuerung sie oft nicht als bedienbar und blendet keine Nummer ein.
- Gleiche Namen für verschiedene Aktionen. Zehn Links mit dem Text Mehr zwingen Nutzer in die Nummern Auswahl.
- Einbuchstabige Kürzel. Eine Web App, die auf die Taste S reagiert, kann durch gesprochene Wörter ungewollt Aktionen auslösen.
- Hover Menüs. Untermenüs, die sich nur beim Überfahren mit der Maus öffnen, sind per Stimme kaum erreichbar.
Accessibility features can benefit more than the original community they were designed to support.
Diktieren wandelt Sprache in Text. Wie Spracheingabe funktioniert, was WCAG 2.5.3 Label in Name fordert und wie Teams ihre Anwendung diktierfähig machen.
Mehr erfahrenEinmal per Stimme bedienen und alles verstehen
Der beste Test kostet nichts: Voice Control auf dem Mac oder Voice Access unter Windows einschalten und versuchen, ein Formular nur per Stimme abzuschicken. Wer das einmal gemacht hat, schreibt nie wieder ein aria-label, das vom sichtbaren Text abweicht.
Sprachsteuerung profitiert von denselben Grundlagen wie andere Hilfsmittel. Eine saubere Tastaturnavigation ist die Basis. Barrierefreie Formulare mit sichtbaren Labels helfen Sprach und Screenreader Nutzern gleichermaßen. Korrekt eingesetztes ARIA ergänzt, wo HTML nicht reicht.
Die Gegenrichtung zur Spracheingabe ist Text to Speech. Grundlage für beides ist die Operabilität aus den vier POUR Prinzipien. Und wer weiterdenkt, landet bei der Agent Readiness: KI Agenten finden Buttons genauso über ihre Namen wie Sprachsteuerungen.
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 Voice Recognition
Voice Control, Label in Name und Tastenkürzel: die häufigsten Fragen zur Bedienung per Stimme.
Voice Recognition ist die Erkennung gesprochener Sprache durch Computer. In der Barrierefreiheit meint der Begriff meist die Sprachsteuerung, mit der Menschen Geräte und Websites per Stimme bedienen. 2026 bringen macOS, iOS, Windows 11 und Android eine solche Steuerung bereits mit, ohne Zusatzsoftware.
Vor allem Menschen mit motorischen Einschränkungen, die Maus und Tastatur nicht oder nur mühsam bedienen können. Dazu gehören Menschen mit Lähmungen, Muskelerkrankungen, Arthritis oder Verletzungen. Auch Menschen mit vorübergehenden Einschränkungen und Nutzer, die gerade keine Hand frei haben, greifen auf Sprachsteuerung zurück.
Am wichtigsten ist 2.5.3 Beschriftung im Namen: Der zugängliche Name muss den sichtbaren Text enthalten. Dazu kommen 2.1.1 Tastatur, 2.1.4 Tastaturkurzbefehle, 4.1.2 Name, Rolle, Wert und das neue 2.5.8 Zielgröße aus WCAG 2.2. Alle liegen auf Stufe A oder AA.
Beim Diktieren wird gesprochene Sprache in Text umgewandelt, etwa in ein Formularfeld oder eine Mail. Bei der Sprachsteuerung wird Sprache in Bedienung umgewandelt, also Klicks, Scrollen und Navigation. Beide nutzen Spracherkennung, stellen aber unterschiedliche Anforderungen. Diktieren braucht gute Eingabefelder, Sprachsteuerung braucht gute Namen.
Schaltet Voice Control auf dem Mac oder Voice Access unter Windows 11 ein. Versucht dann, die wichtigsten Aufgaben nur per Stimme zu erledigen: Navigation, Suche, Formular abschicken. Achtet darauf, ob ihr Elemente über ihren sichtbaren Text ansprechen könnt oder auf Nummern ausweichen müsst.
Label in Name ist das WCAG Kriterium 2.5.3. Es verlangt, dass der sichtbare Text eines Bedienelements auch in seinem zugänglichen Namen steht. Steht auf einem Button Senden, muss sein Name das Wort Senden enthalten, am besten am Anfang. Sonst funktioniert der Befehl Klicke Senden nicht.
Ja, aber vorsichtig. Wenn ein Element sichtbaren Text hat, sollte das aria-label diesen Text am Anfang enthalten oder ganz weggelassen werden. Ein abweichendes aria-label überschreibt den sichtbaren Text für Sprachsteuerung und Screenreader. Für reine Icon Buttons ohne Text ist aria-label dagegen sinnvoll.
Ein Button nur mit Icon hat keinen sichtbaren Namen. Nutzer müssen raten, wie er heißt, etwa Löschen, Entfernen oder Papierkorb. Selbst mit aria-label wissen sie nicht, welches Wort sie sagen sollen. Besser ist ein Icon mit sichtbarem Text oder zumindest ein Tooltip, der den Namen zeigt.
Manche Web Apps reagieren auf einzelne Tasten wie S für Speichern. Sprachsteuerung und Diktieren senden aber Buchstaben als Tastenanschläge. Ein gesprochener Satz kann so ungewollt Aktionen auslösen. WCAG 2.1.4 verlangt deshalb, dass solche Kürzel abschaltbar, umbelegbar oder nur bei Fokus aktiv sind.
Nur, wenn sie korrekt gebaut sind. Custom Komponenten brauchen eine passende Rolle, einen zugänglichen Namen und Tastaturbedienung. Fehlt die Rolle, erkennt die Sprachsteuerung das Element oft nicht als bedienbar. Native HTML Elemente wie button, a und input funktionieren dagegen ohne Zusatzaufwand.
Die eingebauten Sprachsteuerungen von Apple und Microsoft arbeiten in vielen Fällen auf dem Gerät, ohne Sprache in die Cloud zu senden. Das hängt aber von System, Sprache und Einstellung ab. Für Website Betreiber ist wichtig: Die Sprachsteuerung läuft beim Nutzer, eure Seite empfängt keine Audiodaten.
Teilweise. axe core prüft das Kriterium für viele Fälle automatisch. Zusätzlich lässt sich mit Cypress testen, ob das aria-label eines Elements mit seinem sichtbaren Text beginnt. Ein kurzer manueller Test mit echter Sprachsteuerung bleibt trotzdem sinnvoll, weil er auch unklare Namen und fehlende Rollen aufdeckt.