Direkt zum Hauptinhalt

WCAG 2.2 · Level A · BedienbarBarrierefreiheit als Cloud-Service

2.5.3 Label im Namen

Der barrierefreie Name muss den sichtbaren Text enthalten.

Auf einen Blick

Was bedeutet dieses Kriterium?

Kurz gesagt

Der barrierefreie Name muss den sichtbaren Text enthalten.

Aufwand

Einfach umzusetzen, schnell erledigt

Betrifft Rolle

Entwicklung

Konformitätsstufe

Level A

EN 301 549

Abschnitt 9.2.5.3 · BITV 2.0 · BFSG

Verständlich erklärt

Was heißt 2.5.3 für die Praxis?

Der barrierefreie Name muss den sichtbaren Text enthalten.

Wenn ein Button 'Suche' zeigt, muss der barrierefreie Name (aria-label) auch 'Suche' enthalten — nicht etwas Anderes.

Technisch formuliert: Bei UI-Komponenten mit Labels, die Text enthalten, enthält der barrierefreie Name den visuell angezeigten Text.

Wer ist betroffen?

Ein Alltagsbeispiel

Bedienbarkeit bedeutet: jeder Mensch kann die Seite nutzen — egal ob mit Maus, Tastatur, Touchscreen oder Sprachsteuerung. Wer dieses Kriterium verletzt, schließt Nutzer aus, die auf eine bestimmte Eingabemethode angewiesen sind. Besonders betroffen sind: Menschen mit motorischen Einschränkungen, Tastaturnutzer, Menschen mit kognitiven Einschränkungen.

Die Lösung

So setzen Sie es richtig um

Wenn ein Button 'Suche' zeigt, muss der barrierefreie Name (aria-label) auch 'Suche' enthalten — nicht etwas Anderes.

Bei UI-Komponenten mit Labels, die Text enthalten, enthält der barrierefreie Name den visuell angezeigten Text.

Umsetzung

Schritt für Schritt

Konkrete Anleitung zur praktischen Umsetzung dieses Kriteriums.

  1. 1

    aria-label mit sichtbarem Text vergleichen

    Stimmt der aria-label mit dem angezeigten Text überein?

Typische Fehler

Das wird häufig falsch gemacht

Diese Fehler sehen wir in der Praxis besonders oft — und wie Sie sie vermeiden.

Nur mit der Maus testen

Entwickler nutzen beim Testen fast immer die Maus. Viele Probleme werden erst sichtbar, wenn man die Tastatur verwendet. Der Tab-Test sollte Routine sein.

Hover-Effekte als einzige Interaktion

Was nur per Hover funktioniert, ist per Tastatur unbedienbar. Interaktionen sollten immer auch per Fokus oder Klick auslösbar sein.

Selbst prüfen

So testen Sie dieses Kriterium

Mit diesen Methoden können Sie selbst prüfen, ob Ihre Webseite das Kriterium erfüllt.

Tastatur-Test

Legen Sie die Maus beiseite. Navigieren Sie ausschließlich mit Tab, Umschalt+Tab, Enter, Leertaste und Pfeiltasten durch die Seite. Alles erreichbar? Alles bedienbar?

Fokusindikator prüfen

Bei jeder Tastaturnavigation sollte ein sichtbarer Fokusring das aktuell aktive Element markieren. Ist er überall gut sichtbar?

Mit Screenreader und Tastatur

Kombinieren Sie Screenreader-Ansage und Tastaturnavigation. So simulieren Sie die tägliche Nutzung blinder Menschen.

Häufige Fragen

Fragen und Antworten

Ist dieses Kriterium wirklich Pflicht?
Ja. Level A ist die Grundlage jeder Barrierefreiheit. Ohne Level A ist eine Website für bestimmte Nutzergruppen komplett unzugänglich. BITV 2.0, EN 301 549 und BFSG verlangen mindestens Level AA — was Level A einschließt.
Wie kann ich prüfen, ob meine Seite dieses Kriterium erfüllt?
Nutzen Sie einen Test-Mix: automatisierte Tools wie Pa11y oder axe DevTools finden viele Probleme zuverlässig, aber nicht alle. Ergänzen Sie mit manuellen Tests — Tastaturnavigation, Screenreader-Test und eine visuelle Prüfung der relevanten Seitenbereiche.
Welche anderen Kriterien hängen damit zusammen?
Dieses Kriterium steht in engem Zusammenhang mit 4.1.2. Diese Kriterien sollten gemeinsam geprüft werden, weil sie sich gegenseitig ergänzen.

Verwandte Kriterien

Weiterführende Erfolgskriterien

Diese Kriterien stehen in engem Zusammenhang mit 2.5.3 und sollten gemeinsam betrachtet werden.