Eine Website wird üblicherweise auf drei Wegen geprüft: mit der Maus, mit der Tastatur und mit einem Screenreader. Ein vierter Bedienweg fällt dabei regelmäßig durch das Raster. Wer den Rechner mit der Stimme steuert, spricht den Text aus, der auf dem Bildschirm steht — „Klick In den Warenkorb“. Ob dieser Befehl ankommt, entscheidet aber nicht der sichtbare Text, sondern der zugängliche Name des Bedienelements. Weichen beide voneinander ab, läuft der Befehl ins Leere, obwohl dieselbe Schaltfläche mit der Tastatur erreichbar ist und ein Screenreader sie sauber ankündigt. Das Erfolgskriterium 2.5.3 Label in Name der WCAG 2.2 (W3C) schließt genau diese Lücke, und zwar auf Stufe A. Dieser Beitrag zeigt, wie Sprachbedienung technisch funktioniert, wo der zugängliche Name typischerweise abweicht und wie sich der Bedienweg mit den Bordmitteln des Browsers prüfen lässt.
Das Wichtigste in Kürze
- Sprachsteuerung nutzt den sichtbaren Text als Kommando. Deckt der zugängliche Name diesen Text nicht ab, ist das Element per Stimme nicht ansteuerbar — auch dann, wenn Tastaturbedienung und Screenreader-Ausgabe in Ordnung sind.
- Erfolgskriterium 2.5.3 Label in Name (W3C) steht auf Stufe A, der untersten Konformitätsstufe der WCAG 2.2. Es gehört damit in den Pflichtteil jedes WCAG-Audits.
- Die harmonisierte Norm übernimmt das Kriterium wörtlich in Klausel 9.2.5.3 (EN 301 549). Über die BFSG-Anforderungen wird daraus eine Pflicht für Wirtschaftsakteure.
- Die häufigsten Ursachen sind ein aria-label, das den sichtbaren Text ersetzt statt ihn zu enthalten, Symbolschaltflächen ohne Textbezug und Beschriftungen, die nur als Grafik vorliegen.
- Der Bedienweg lässt sich ohne Spezialsoftware prüfen: sichtbaren Text und zugänglichen Namen im Zugänglichkeitsbaum des Browsers gegenüberstellen und jede Abweichung notieren.
Ein vierter Bedienweg, der selten mitgeprüft wird
Die Ausgangslage ist bekannt: Auf 95,9 Prozent (WebAIM Million) der untersuchten Startseiten fanden sich im Februar 2026 maschinell erkennbare Verstöße gegen die WCAG, im Schnitt 56,1 (WebAIM Million) Fehler je Seite. Die Erhebung wertet die Startseiten der eine Million meistbesuchten Websites automatisiert aus und erfasst damit nur einen Teil der tatsächlichen Barrieren — alles, was eine menschliche Bewertung braucht, taucht dort gar nicht erst auf. Für die Sprachbedienung ist sie trotzdem aufschlussreich, denn die häufigsten Befunde betreffen genau die Elemente, an denen ein Sprachbefehl ansetzt: Schaltflächen ohne Text, Formularfelder ohne Beschriftung und Links ohne verwertbaren Namen. Wer diese drei Gruppen in Ordnung bringt, verbessert nicht nur die Bilanz eines Prüfwerkzeugs, sondern macht die Seite überhaupt erst ansprechbar.
Wie viele Menschen diesen Bedienweg brauchen, lässt sich nur annähern. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen (Statistisches Bundesamt) Menschen mit einer schweren Behinderung; bei 10 Prozent (Statistisches Bundesamt) von ihnen waren Arme oder Beine in ihrer Funktion eingeschränkt. Weltweit geht die Weltgesundheitsorganisation von 1,3 Milliarden (WHO) Menschen mit einer erheblichen Behinderung aus, das entspricht 16 Prozent (WHO) der Weltbevölkerung. Sprachsteuerung ist dabei nicht an eine Diagnose gebunden: Sie hilft nach einer Handverletzung, bei einer Sehnenscheidenentzündung, bei Tremor und in Situationen, in denen beide Hände anderweitig gebraucht werden. Der Bedienweg hat damit eine deutlich größere Nutzergruppe, als die Zahlen zur Schwerbehinderung nahelegen.
Zwei Fragen, die im Prüfprotokoll fehlen
Wie ein Sprachbefehl im Browser ankommt
Sprachsteuerungssoftware arbeitet nicht auf den Bildpunkten des Bildschirms, sondern auf dem Zugänglichkeitsbaum, den der Browser aus dem Dokument aufbaut. Jedes Bedienelement bekommt dort einen zugänglichen Namen, eine Rolle und einen Zustand. Spricht jemand „Klick Absenden“, sucht die Software im Baum nach einem Element mit der Rolle Schaltfläche, dessen Name das Wort „Absenden“ enthält. Findet sie genau eines, löst sie es aus. Findet sie mehrere, nummeriert sie die Treffer und wartet auf eine Auswahl. Findet sie keines, passiert nichts — und zwar ohne Fehlermeldung, weil aus Sicht der Software schlicht kein passendes Element existiert. Für die bedienende Person sieht das aus wie ein defekter Knopf.
Der zugängliche Name entsteht nach einer festen Rangfolge. Ein aria-labelledby verweist auf anderen Text im Dokument und schlägt alles Weitere. Danach greift ein aria-label, dann ein verknüpftes label-Element, dann der Textinhalt des Elements selbst, dann ein alt-Attribut, zuletzt ein title. Jede dieser Stufen kann den sichtbaren Text verdrängen. Genau darin liegt die Bruchstelle: Wer eine Schaltfläche mit dem Text „In den Warenkorb“ zusätzlich mit einem aria-label mit dem Wert „Jetzt kaufen“ versieht, hat den sichtbaren Text aus dem Namen entfernt. Der Screenreader liest „Jetzt kaufen“, die Sprachsteuerung kennt „In den Warenkorb“ nicht mehr. Beide Ausgaben stammen aus derselben Zeile Quelltext, und nur eine davon fällt in einem üblichen Test auf.
| Frage | Tastatur | Screenreader | Sprachsteuerung |
|---|---|---|---|
| Worauf der Bedienweg zugreift | Fokusreihenfolge im Dokument | Zugänglichkeitsbaum, vorgelesen | Zugänglichkeitsbaum, durchsucht |
| Was die bedienende Person wahrnimmt | den sichtbaren Fokusring | den vorgelesenen Namen | den sichtbaren Text |
| Wann es bricht | Element ist nicht fokussierbar | Name fehlt oder ist leer | Name deckt den sichtbaren Text nicht ab |
| Erfolgskriterium | 2.1.1 Keyboard, Stufe A | 4.1.2 Name, Role, Value, Stufe A | 2.5.3 Label in Name, Stufe A |
| Typischer Fehlbefund | eigenes div statt button | Symbol ohne Alternativtext | aria-label ersetzt den Text |
Die Tabelle zeigt, warum ein sauberer Screenreader-Test die Sprachbedienung nicht mit abdeckt. Beide Bedienwege lesen denselben Baum, ziehen aber gegensätzliche Schlüsse: Für die Sprachausgabe ist ein präziser, vom Bildschirm abweichender Name oft eine Verbesserung, für die Sprachsteuerung ist er eine Barriere. Ein Screenreader-Test beantwortet die Frage „Wird das Element verständlich angekündigt?“. Die Sprachbedienung stellt die andere Frage: „Kann ich das Element bei seinem sichtbaren Namen rufen?“. Wer nur die erste Frage stellt, findet die zweite Klasse von Befunden erfahrungsgemäß gar nicht.
2.5.3 Label in Name: die Regel in einem Satz
Das Erfolgskriterium ist kurz. In der WCAG 2.2, seit dem 12. Dezember 2024 (W3C) in der aktuellen Fassung als Empfehlung veröffentlicht, lautet es sinngemäß: Bei Bedienelementen mit einer Beschriftung aus Text oder Schriftgrafik enthält der Name den Text, der visuell dargestellt wird. Drei Formulierungen tragen die ganze Regel. „Enthält“ heißt: Der Name darf mehr sagen als die Beschriftung, aber er muss den sichtbaren Text vollständig führen. „Visuell dargestellt“ heißt: Es zählt, was auf dem Bildschirm steht, nicht was in der Entwurfsvorlage stand. Und „Bedienelemente“ grenzt den Anwendungsbereich ein — für Überschriften und Fließtext gilt das Kriterium nicht.
Zwei Feinheiten entscheiden in der Praxis über den Befund. Erstens gilt als Beschriftung nur der Text in unmittelbarer Nähe des Elements: links neben Eingabefeldern und Auswahllisten, rechts neben Ankreuzfeldern und Optionsfeldern, innerhalb von Schaltflächen und Reitern. Eine Überschrift zwei Abschnitte weiter oben ist keine Beschriftung im Sinne des Kriteriums, auch wenn sie inhaltlich passt. Zweitens empfiehlt die Norm, den Beschriftungstext an den Anfang des Namens zu setzen. Das ist keine Pflicht, erleichtert die Bedienung aber erheblich, weil viele Sprachsteuerungen bei mehreren Treffern nach der Reihenfolge sortieren und ein vorangestellter Zusatz die Trefferliste unnötig verlängert.
aria-label überschreibt
Ein aria-label ersetzt den sichtbaren Text vollständig. Sinnvoll bei Symbolschaltflächen ohne Text, schädlich, sobald eine sichtbare Beschriftung vorhanden ist.
Beschriftung als Grafik
Steht der Text in einer Bilddatei, muss der Alternativtext ihn wörtlich führen. Ein beschreibendes „Logo der Firma“ statt des abgebildeten Wortes bricht den Sprachbefehl.
Symbol ohne Textbezug
Ein Lupensymbol trägt oft den Namen „Suchen“, sichtbar ist aber kein Wort. Hier greift 2.5.3 nicht, wohl aber die Erwartung der bedienenden Person.
Zusatz vor der Beschriftung
Namen wie „Weiterlesen: Barrierefreiheit im Handel“ beginnen mit dem Zusatz. Zulässig, solange der sichtbare Text enthalten ist, aber schwerer zu treffen.
Sonderzeichen und Ligaturen
Typografische Anführungszeichen, geschützte Leerzeichen und Ligaturen im Namen erzeugen Abweichungen, die im Bildschirmfoto unsichtbar bleiben.
Platzhalter statt Beschriftung
Steht nur ein Platzhalter im Feld, wird er zur einzigen sichtbaren Beschriftung — und muss dann auch im Namen stehen.
Diese sechs Muster decken den größten Teil der Befunde ab, die uns in Audits begegnen. Sie haben eine Gemeinsamkeit: Alle entstehen aus dem Versuch, die Ausgabe für Screenreader zu verbessern. Ein Team, das aria-label großzügig einsetzt, meint es gut und erzeugt dabei den verdeckten Befehl. Deshalb gehört der Abgleich zwischen Bildschirm und Baum in dieselbe Prüfrunde wie die ARIA-Rollen und Zustände — sonst optimiert die eine Runde weg, was die andere gerade aufgebaut hat.
Ein abweichender Name ist ein verdeckter Befehl
Wo der zugängliche Name typischerweise abweicht
Die Größenordnung lässt sich aus der Erhebung ablesen. Auf 30,6 Prozent (WebAIM Million) der Startseiten fanden sich leere Schaltflächen, auf 46,3 Prozent (WebAIM Million) leere Links. Bei Formularen fehlte auf 51 Prozent (WebAIM Million) der Seiten mindestens eine Feldbeschriftung; über alle gefundenen Eingabefelder hinweg waren 33,1 Prozent (WebAIM Million) nicht korrekt beschriftet. Ein leeres Element hat gar keinen Namen und ist damit per Sprache nicht ansprechbar — der Extremfall von 2.5.3, formal ein Verstoß gegen 4.1.2 Name, Role, Value. Die WCAG hält ausdrücklich fest, dass ein Bedienelement ohne zugänglichen Name bei vorhandener sichtbarer Beschriftung beide Kriterien verletzt.
Der zweite Block sind Elemente, die einen Namen haben, aber den falschen. Auf 15,2 Prozent (WebAIM Million) der Startseiten stand mehrdeutiger Linktext wie „hier klicken“ oder „mehr“. Solche Links tragen häufig ein aria-label mit dem eigentlichen Ziel — was den Screenreader bedient und die Sprachsteuerung aussperrt, weil der gesprochene sichtbare Text „mehr“ im Namen nicht mehr vorkommt. Wie verbreitet dieser Eingriff ist, zeigt die ARIA-Statistik: Startseiten trugen im Mittel 31,4 (WebAIM Million) Attribute vom Typ aria-label, aria-labelledby oder aria-describedby und 4,8 (WebAIM Million) Vorkommen von role="button". Jedes dieser Attribute ist eine Stelle, an der der Name vom Bildschirm abweichen kann.
- Jede Schaltfläche mit sichtbarem Text trägt diesen Text im zugänglichen Namen — ohne Umformulierung, ohne Kürzung.
- Symbolschaltflächen ohne sichtbaren Text bekommen einen Namen, der dem entspricht, was bedienende Personen aussprechen würden: „Suchen“, „Menü“, „Schließen“.
- Links mit generischem Text bekommen den Zusatz hinter dem sichtbaren Text, nicht davor und nicht an dessen Stelle.
- Eingabefelder haben eine sichtbare Beschriftung über ein label-Element; ein Platzhalter ersetzt sie nicht.
- Beschriftungen in Grafiken führen den abgebildeten Wortlaut im Alternativtext.
- Bedienelemente, die ihren Text ändern — aufklappen und zuklappen —, ändern ihren Namen mit.
- Bei mehreren gleich benannten Elementen auf einer Seite ist geprüft, ob die Sprachsteuerung sie sinnvoll unterscheiden kann.
Die vorletzte Zeile wird am häufigsten übersehen. Ein Schalter, dessen Beschriftung zwischen „Mehr anzeigen“ und „Weniger anzeigen“ wechselt, muss beide Zustände auch im Namen abbilden. Bleibt der Name konstant, bedient die Sprachsteuerung nach dem ersten Klick ein Element, das etwas anderes anzeigt, als sie gerufen hat. Dasselbe gilt für Filter und Sortierungen in einer barrierefreien Produktsuche, deren Beschriftungen sich mit der Auswahl ändern, und für Reiter, die den aktiven Zustand nur farblich zeigen.
Von der Norm zur Rechtspflicht
Die WCAG sind eine Empfehlung des W3C ohne unmittelbare Rechtswirkung. Verbindlich werden sie über die harmonisierte europäische Norm. Die EN 301 549 übernimmt das Erfolgskriterium wörtlich in Klausel 9.2.5.3 (EN 301 549) für Webseiten und noch einmal in Klausel 11.2.5.3 für Software. Zusätzlich nennt die Norm in ihrem Abschnitt zu den funktionalen Leistungsmerkmalen die Sprachbedienung ausdrücklich: Klausel 4.2.7 (EN 301 549) verlangt für Menschen mit eingeschränkter Beweglichkeit oder Kraft eine Bedienung ohne feinmotorische Handlungen und führt Sprachschnittstellen als einen Weg dorthin auf. Wer die Norm hinter dem BFSG liest, findet Sprachbedienung also nicht als Sonderfall, sondern als eingeplanten Bedienweg.
Den Schritt ins deutsche Recht macht das Barrierefreiheitsstärkungsgesetz. Nach § 3 Absatz 1 (BFSG) sind Produkte und Dienstleistungen barrierefrei, wenn sie für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind. Die konkreten Anforderungen stehen in der zugehörigen Verordnung, die auf den Stand der Technik verweist — und der ist für Websites die EN 301 549. Die zugrunde liegende Richtlinie wird seit dem 28. Juni 2025 (EU-Richtlinie 2019/882) angewendet; seither betrifft sie unter anderem den elektronischen Geschäftsverkehr, Bankdienstleistungen für Verbraucher und E-Books.
Für Unternehmen mit Kundschaft in mehreren Mitgliedstaaten lohnt der Blick über die Grenze, weil die nationalen Umsetzungen im Detail abweichen; wir haben das in der Übersicht zur Barrierefreiheit im EU-Ausland zusammengetragen. Innerhalb des Unternehmens hat der Bedienweg noch eine zweite Seite: Wer Mitarbeitende mit eingeschränkter Handmotorik beschäftigt, braucht sprachbedienbare interne Werkzeuge — und eine Karriereseite ohne Hürden, auf der die Bewerbung überhaupt erst abgeschickt werden kann.
Zwei Rollen, zwei Pflichten
Prüfraster: Sprachbedienung in einem halben Tag
Ein belastbares Bild entsteht schneller, als die meisten erwarten. Sie brauchen keine Sprachsteuerungssoftware, um die Kernfrage zu beantworten — der Abgleich zwischen sichtbarem Text und zugänglichem Namen ist in den Entwicklerwerkzeugen jedes gängigen Browsers ablesbar. Wählen Sie die fünf Seiten, über die Ihr Geschäft läuft: Startseite, Suche oder Übersicht, Detailseite, Formular, Abschluss. Arbeiten Sie dann diese Reihenfolge ab.
- Öffnen Sie den Zugänglichkeitsbaum der Entwicklerwerkzeuge und lassen Sie ihn neben der gerenderten Seite stehen.
- Gehen Sie mit der Tabulatortaste durch alle Bedienelemente und notieren Sie je Element den sichtbaren Text und den angezeigten Namen.
- Markieren Sie jede Zeile, in der der sichtbare Text nicht vollständig im Namen vorkommt. Das ist Ihre Befundliste zu 2.5.3.
- Prüfen Sie gesondert alle Elemente ohne sichtbaren Text: Symbolschaltflächen, Schließen-Kreuze, Pfeile in Bildergalerien.
- Suchen Sie im Quelltext nach aria-label und aria-labelledby und gleichen Sie jeden Treffer gegen den daneben sichtbaren Text ab.
- Klappen Sie jedes ausklappbare Element auf und wieder zu und beobachten Sie, ob der Name mitwandert.
- Lassen Sie die Seite einmal mit einer echten Sprachsteuerung bedienen — die Bordmittel gängiger Betriebssysteme genügen für einen ersten Durchlauf.
- Halten Sie je Befund fest, ob er im eigenen Quelltext liegt oder in einer eingebundenen Komponente.
Der letzte Punkt entscheidet über den Aufwand. Ein Befund im eigenen Markup ist meist eine Zeile. Ein Befund in einem eingekauften Baustein oder einem eingebundenen Fremdelement braucht einen anderen Weg — und manchmal eine Entscheidung gegen den Baustein. Wie sich die Verantwortung dafür verteilt, hängt an der Art der Einbindung; die Grundlinie dazu steht in unserem Beitrag zur Verantwortung für Drittanbieter-Elemente.
| Befund | Im eigenen Projekt lösbar | Beim Hersteller angesiedelt |
|---|---|---|
| aria-label ersetzt den sichtbaren Text | ja, Attribut entfernen oder erweitern | wenn das Attribut aus einer Bibliothek stammt |
| Schaltfläche ohne jeden Namen | ja, Text oder Beschriftung ergänzen | bei gekapselten Komponenten ohne Schnittstelle |
| Beschriftung liegt als Grafik vor | ja, Alternativtext angleichen | bei automatisch erzeugten Grafiken |
| Name wechselt nicht mit dem Zustand | ja, Zustandslogik ergänzen | bei fremden Bedienelementen |
| Zahlungsschritt in fremdem Rahmen | nur über die Auswahl des Anbieters | ja, mit Nachweis im Beschaffungsvorgang |
Diese Einordnung verändert das Gespräch mit Lieferanten. Statt einer allgemeinen Frage nach Barrierefreiheit steht eine konkrete Anforderung im Raum: Der zugängliche Name jedes Bedienelements enthält den sichtbaren Text. Das ist prüfbar, nachweisbar und in einer Abnahme formulierbar. Für die Beschaffung selbst haben wir die Anforderungen in unserem Beitrag zu öffentlichen Ausschreibungen beschrieben.
Aus einmal beheben wird laufend prüfen
Ein bereinigter Stand hält so lange, bis die nächste Komponente eingebaut wird. Weil ein abweichender Name kein sichtbares Symptom hat, fällt der Rückfall in der Abnahme selten auf: Die Seite sieht aus wie vorher, die Tastaturbedienung funktioniert, der Screenreader liest sogar etwas Sinnvolles vor. Deshalb gehört die Regel in die Entwicklung, nicht nur in die Prüfung. Ein barrierefreies Design-System kann sie erzwingen, indem seine Schaltflächenkomponente den sichtbaren Text an den Namen bindet und ein abweichendes aria-label ablehnt.
Der zweite Baustein ist die Wiederholung. Wir empfehlen, den Abgleich in die Abnahmeliste jeder größeren Änderung aufzunehmen und ihn zusätzlich in einem festen Takt über die Kernseiten laufen zu lassen — das ist der Kern unseres BFSG-Monitorings. Wer das im eigenen Team halten will, findet in unseren Schulungen den Teil, der Entwicklung und Redaktion zugleich betrifft: Was in den Namen gehört, entscheidet oft die Redaktion, umgesetzt wird es in der Komponente.
Ein Bedienelement, dessen Name den sichtbaren Text enthält, ist mit Maus, Tastatur, Screenreader und Stimme gleichermaßen erreichbar. Ein Name, der davon abweicht, bedient genau einen dieser Wege besser und schließt einen anderen aus.
Der Einstieg ist überschaubar. Der Abgleich zwischen sichtbarem Text und zugänglichem Namen ist ein eigener Prüfschritt mit klarem Ergebnis: eine Liste von Elementen, die per Stimme nicht erreichbar sind, sortiert nach Geschäftsrelevanz. Aus dieser Liste wird eine Aufgabenfolge für die barrierefreie Webentwicklung, und aus wiederkehrenden Mustern wird eine Regel im Design-System. Welche Leistungen dabei zusammenspielen, zeigt die Übersicht unserer Leistungen.
Quellen und Studien