accessibility

Jedes Formularfeld beschriften

MetricSpot prüft jedes Eingabefeld auf ein zugeordnetes <label>, aria-label oder aria-labelledby. Unbeschriftete Felder werden von Screenreadern nur als "Eingabefeld" angesagt.

Was diese Prüfung macht

Geht jedes <input>, <textarea> und <select> auf der Seite durch und prüft, ob es einen zugänglichen Namen aus einer der folgenden Quellen hat:

  • Ein explizites <label for="id">
  • Ein umschließendes <label>…<input>…</label>
  • Ein aria-label="…"-Attribut
  • Ein aria-labelledby="other-id", das auf sichtbaren Text zeigt
  • Ein title-Attribut (am schlechtesten — ein Hover-Tooltip ist ein minderwertiger Fallback, zählt aber)

Die Prüfung fällt durch, wenn ein Eingabefeld keines davon hat und kein Hidden-Field, Submit-Button oder CSRF-Token ist.

Warum es wichtig ist

Eine Person mit Screenreader, die ein Checkout-Formular ausfüllt, hört „Eingabefeld, Eingabefeld, Eingabefeld” statt „Kartennummer, Ablaufdatum, CVV”. Unbeschriftete Felder sind unbenutzbar.

  • Conversion-Effekt, nicht nur Compliance. Jede UX-Studie zu Zahlungsformularen zeigt dasselbe: sichtbare Feld-Labels (nicht nur Platzhalter) heben die Abschlussrate um 10–20 %. Platzhalter verschwinden beim Tippen — der Nutzer kann nicht mehr prüfen, in welches Feld er gerade schreibt.
  • Rechtliches Risiko. Formular-Labels gehören zu den am häufigsten zitierten WCAG-Verstößen in Barrierefreiheits-Klagen, weil sie leicht zu verifizieren sind (Seite in NVDA öffnen, durchtabben). Die meisten ADA-Title-III-Klagen gegen US-Shops nennen Formular-Labels unter den Top-3-Verstößen.
  • Autofill funktioniert besser. Browser und Passwort-Manager erkennen Feldtypen am Label-Text. Ein Feld mit Label „E-Mail” wird automatisch ausgefüllt; ein unbeschriftetes <input type="text"> nicht.

Wie du es behebst

Verwende ein sichtbares <label>, das per for/id mit dem Feld verbunden ist. Verlass dich nicht allein auf Platzhalter-Text.

Das kanonische Muster:

<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email" autocomplete="email" required>

Umschließendes Muster (Label als Elternelement, kein for nötig):

<label>
  E-Mail-Adresse
  <input name="email" type="email" autocomplete="email" required>
</label>

Icon-Buttons (ohne sichtbaren Text)aria-label verwenden:

<button type="submit" aria-label="Suchen">
  <svg aria-hidden="true">…</svg>
</button>

React mit kontrollierten Eingaben:

<label htmlFor="email">E-Mail-Adresse</label>
<input
  id="email"
  type="email"
  value={email}
  onChange={(e) => setEmail(e.target.value)}
  autoComplete="email"
  required
/>

(Hinweis: JSX nutzt htmlFor, nicht forfor ist ein reserviertes Wort.)

Floating Labels (Material Design, shadcn/ui) — das sichtbare Label ist animiert, aber das zugrundeliegende HTML muss <label for> weiterhin mit <input id> paaren. Versteckt dein Design-System das Label visuell, nutze class="sr-only" (eine Tailwind-Utility), statt das Element wegzulassen:

<label for="search" class="sr-only">Dokumentation durchsuchen</label>
<input id="search" type="search" placeholder="Suchen…">

Vermeide.

  • Platzhalter nicht als einziges Label nutzen — er verschwindet beim Tippen und hat geringeren Kontrast.
  • Kein <div> oder <span> als Label — die Zuordnung wird assistiver Technologie nicht offengelegt.
  • Dieselbe id nicht mehrfach vergeben — die Zuordnung bricht stillschweigend.

Linter und CI. eslint-plugin-jsx-a11y liefert eine label-has-associated-control-Regel. In die Config aufnehmen und CI bei fehlenden Labels brechen lassen. axe-core / Playwright fangen sie zur Laufzeit — siehe Snippet auf der Seite Lighthouse-Accessibility-Score.

Häufig gestellte Fragen

Ist placeholder ein Label?

Nein. Platzhalter sind Hinweise für leere Felder; sie verschwinden beim Fokus. WCAG stellt ausdrücklich klar: Platzhalter erfüllen die Label-Anforderung nicht.

Was ist mit aria-label?

aria-label funktioniert, sichtbare Labels funktionieren besser — sehende Nutzer mit kognitiven Einschränkungen, Nutzer mit Sehschwäche und Bildschirmlupe und Nutzer, die die Seite im Browser übersetzen, profitieren alle von Text, den sie sehen können. Nutze aria-label nur, wenn ein sichtbares Label redundant wäre (Icon-Buttons, Suchfeld mit eindeutigem Submit-Icon).

Brauche ich ein Label für Submit-Buttons?

<button type="submit">Registrieren</button> hat eigenen sichtbaren Text — der ist der zugängliche Name, kein extra Label nötig. Gleiches gilt für <input type="submit" value="Registrieren">. Submit-Buttons nur mit Icon brauchen aria-label.

Quellen

Zuletzt aktualisiert 2026-05-11