Labels & Beschriftungen für Formulare

Ein Formularfeld ohne Beschriftung ist eine Rückfrage. Wer es ausfüllen soll, muss raten, was hineingehört – und wer einen Screenreader nutzt, hört im Zweifel nur „Eingabefeld“, ganz ohne Hinweis. Das <label>-Element löst das auf die denkbar einfachste Weise: Es verbindet einen sichtbaren Text fest mit einem Bedienelement.

Diese Verbindung ist mehr als Kosmetik. Ein korrekt verknüpftes Label vergrößert die Klickfläche, liefert assistiven Technologien den zugänglichen Namen des Feldes und überlebt jede spätere Umgestaltung. Beschriftungen gehören für mich zu den Dingen, bei denen sich der geringste Aufwand am deutlichsten auszahlt – und trotzdem sehe ich sie ständig falsch oder gar nicht umgesetzt.

Das Wichtigste in Kürze

• Ein Label wird über for/id oder durch Umschließen mit dem Feld verknüpft. Nur diese Verknüpfung erzeugt den zugänglichen Namen; Text daneben allein reicht nicht.
• Das verknüpfte Label vergrößert die Trefferfläche: Ein Klick auf den Text setzt den Fokus ins Feld oder schaltet die Checkbox.
• placeholder ist kein Label – er verschwindet beim Tippen.
• <label> wirkt nur an den sieben beschriftbaren Elementen; an einem div mit ARIA-Rolle hat for keine Wirkung.
• aria-label und aria-labelledby überschreiben das sichtbare <label>. Weicht der Name vom sichtbaren Text ab, verletzt das WCAG 2.5.3 (Stufe A).
• Betroffene Kriterien: 3.3.2 (A), 4.1.2 (A), 2.5.3 (A) und 1.3.5 Eingabezweck (AA).
• Der schnellste Test ist ein Klick auf den Labeltext: Passiert nichts, fehlt die Verknüpfung.

Warum jedes Feld eine Beschriftung braucht

Sobald Software ein Formular interpretieren muss, wird die Beschriftung zum zentralen Anker. Drei Effekte hängen direkt daran:

• Verständlichkeit: Ein Screenreader liest beim Fokussieren des Feldes dessen zugänglichen Namen vor. Fehlt er, bleibt das Feld stumm oder bekommt einen generischen Platzhalternamen.
• Bedienbarkeit: Ein verknüpftes Label ist Teil der Trefferfläche. Ein Klick oder Tap auf den Text setzt den Fokus ins Feld bzw. schaltet eine Checkbox – ein echter Gewinn besonders auf dem Smartphone.
• Robustheit: Die Zuordnung steht im Markup, nicht in der optischen Nähe. Sie bleibt also korrekt, egal wie das Layout später verschoben wird.

Die WCAG fassen das in zwei Kriterien: Jedes Bedienelement braucht eine sichtbare Beschriftung (3.3.2) und einen programmatisch ermittelbaren Namen (4.1.2) – beide auf Stufe A. Mit nativem HTML erfüllst du sie in einer Zeile. Wie aus dem Markup der Name entsteht, den ein Screenreader vorliest, erklärt Screenreader-Grundlagen.

Die zwei Wege, ein Label zu verknüpfen

Es gibt genau zwei korrekte Muster. Beide sind valide – ich greife in der Praxis aber fast immer zur ersten Variante.

Explizit über for und id – das Label verweist per for auf die id des Feldes:

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

Implizit durch Umschließen – das Feld liegt im <label>:

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

Die explizite Variante hat zwei Vorteile, die mir den Ausschlag geben: Sie lässt Text und Feld im Markup frei anordnen (wichtig für viele Layouts), und sie funktioniert zuverlässiger mit älteren Hilfsmitteln. Die id muss dabei pro Seite eindeutig sein – bei generierten Formularen ein häufiger Stolperstein.

Ein verbreiteter Irrtum: placeholder sei ein Label. Ist es nicht. Der Platzhalter verschwindet beim Tippen, hat oft zu wenig Kontrast und wird von manchen Screenreadern gar nicht als Name gewertet. Nutze ihn höchstens als ergänzendes Beispiel („z. B. max@example.com“), nie als Ersatz für das Label.

Nicht jedes Element lässt sich beschriften

Ein Detail, über das ich in Reviews regelmäßig stolpere: <label for="…"> wirkt nicht auf beliebige Elemente. Der HTML-Standard kennt genau sieben beschriftbare Elemente – input (außer type="hidden"), select, textarea, button, meter, output und progress. Zeigt for auf irgendetwas anderes, passiert schlicht nichts: kein Name, keine vergrößerte Trefferfläche, keine Fehlermeldung.

Praktisch relevant wird das bei nachgebauten Bedienelementen. Ein <div role="textbox"> oder ein als Checkbox gestylter <span> ist kein beschriftbares Element; sein Name muss über aria-labelledby kommen:

<!-- funktioniert NICHT: for zeigt auf ein nicht beschriftbares Element -->
<label for="menge">Menge</label>
<div id="menge" role="spinbutton" tabindex="0">1</div>

<!-- richtig: der Text benennt das Element per aria-labelledby -->
<span id="menge-label">Menge</span>
<div role="spinbutton" tabindex="0" aria-labelledby="menge-label"
     aria-valuenow="1" aria-valuemin="1" aria-valuemax="99">1</div>

Die bessere Antwort ist meistens, gar nicht erst nachzubauen: Ein natives <input type="number"> bringt Name, Rolle, Wert und Tastaturbedienung mit. Wann ein Nachbau trotzdem vertretbar ist, ordnet Rollen, States & Properties ein.

Wenn kein sichtbares Label möglich ist

Manchmal verlangt das Design ein Feld ohne sichtbaren Text – das klassische Suchfeld mit Lupensymbol etwa. Auch dann braucht das Feld einen Namen. Drei Wege führen zum Ziel, in meiner bevorzugten Reihenfolge:

<!-- 1. Bevorzugt: sichtbares <label>, nur optisch ausgeblendet -->
<label class="visually-hidden" for="suche">Suche</label>
<input type="search" id="suche" name="q" />

<!-- 2. aria-label, wenn ein echtes Label nicht praktikabel ist -->
<input type="search" name="q" aria-label="Suche" />

<!-- 3. aria-labelledby, wenn ein vorhandener Text das Feld benennt -->
<h2 id="newsletter-titel">Newsletter abonnieren</h2>
<input type="email" name="email" aria-labelledby="newsletter-titel" />

Ich nehme das visuell versteckte <label> (.visually-hidden) den ARIA-Attributen gegenüber bewusst vor: Es ist echter Text, wird von Übersetzungs-Tools mitübersetzt und lässt sich nicht so leicht übersehen. aria-label ist die solide zweite Wahl – kein sichtbarer Text, der versehentlich unübersetzt bleibt. Das passt zur ersten Regel von ARIA: natives HTML zuerst, ARIA nur, wo es wirklich nötig ist.

Wichtig ist die Rangfolge, in der Browser den Namen ermitteln: aria-labelledby schlägt aria-label, und aria-label schlägt das <label>. Ein aria-label neben einem sichtbaren Label ersetzt es also – es ergänzt es nicht. Genau daraus entsteht der Fehler am Ende dieser Seite: sichtbar steht „E-Mail-Adresse“, angesagt wird „Kontaktfeld“.

Floating Labels: erlaubt, aber mit zwei Bedingungen

Das Muster, bei dem der Labeltext zunächst im Feld steht und beim Fokussieren nach oben wandert, ist weit verbreitet – und es ist nicht per se ein Problem. Es wird eines, wenn zwei Bedingungen verletzt werden.

Erstens muss der Text sichtbar bleiben. Wandert er beim Tippen nach oben, ist alles in Ordnung. Verschwindet er, war es ein placeholder mit Animation, und die Beschriftung existiert im ausgefüllten Zustand nicht mehr – wer das Formular vor dem Absenden noch einmal durchgeht, muss aus dem Inhalt rückschließen, was das Feld wollte.

Zweitens muss der verkleinerte Text noch lesbar sein. Floating Labels schrumpfen typischerweise auf 11 oder 12 Pixel und werden grau – und rutschen damit unter die 4,5:1-Grenze aus 1.4.3 Kontrast (Minimum). Das ist in der Praxis der häufigere der beiden Fehler, weil er im Entwurf hübsch aussieht und niemandem auffällt, der das Formular kennt. Die Werte prüfst du mit dem Kontrast-Check.

Technisch bleibt es dabei ein normales <label for="…">; die Bewegung ist reines CSS. Wer das Label dagegen als placeholder umsetzt und per Skript ein zweites Element einblendet, baut sich beide Probleme gleichzeitig ein.

Beschriftungen, die wirklich helfen

Ein verknüpftes Label ist die halbe Miete – die andere Hälfte ist sein Wortlaut. Ein paar Punkte, auf die ich achte:

• Knapp und eindeutig. „E-Mail-Adresse“ ist besser als „Bitte geben Sie hier Ihre E-Mail-Adresse ein“. Die Aufforderung steckt schon im Feld.
• Zusatzhinweise nicht ins Label, sondern daneben. Formatregeln oder Beispiele gehören in einen separaten Text, der über aria-describedby mit dem Feld verbunden wird – so bleiben Name und Hilfetext getrennt.

<label for="pw">Passwort</label>
<input type="password" id="pw" aria-describedby="pw-hilfe" />
<p id="pw-hilfe">Mindestens 12 Zeichen, mit Zahl und Sonderzeichen.</p>

Genau dieses aria-describedby-Muster trägt später auch die Fehlermeldungen und die Kennzeichnung von Pflichtfeldern. Es lohnt sich, es einmal sauber zu verstehen.

Gruppen brauchen eine eigene Beschriftung

Ein einzelnes <label> benennt genau ein Feld. Mehrere zusammengehörige Felder – etwa die Radio-Buttons einer Frage – brauchen zusätzlich eine übergeordnete Beschriftung. Dafür gibt es <fieldset> und <legend>, die ich auf der Seite fieldset & legend ausführlich behandle. Welche Elemente ein Formular sonst noch strukturieren, steht unter Formular-Semantik & Input-Typen.

So testest du die Beschriftungen

Fünf Schritte, mehr braucht es nicht – und der erste findet schon die Mehrzahl der Fehler:

1. Auf jeden Labeltext klicken. Springt der Fokus ins zugehörige Feld, schaltet die Checkbox um? Wenn nicht, ist das Label nicht verknüpft. Dieser Test dauert pro Formular zwanzig Sekunden und braucht kein Werkzeug.
2. Den zugänglichen Namen auslesen. In den DevTools das Feld auswählen und im Barrierefreiheits-Panel (Chrome: „Accessibility“, Firefox: „Barrierefreiheit“) die Eigenschaft Name prüfen. Leer oder „Eingabefeld“ heißt: kein Name. Steht dort etwas anderes als der sichtbare Text, überschreibt ein ARIA-Attribut das Label.
3. Die Formularfeld-Liste im Screenreader öffnen. In NVDA über NVDA+F7 → Formularfelder, in VoiceOver über den Rotor. Die Liste zeigt alle Felder nur mit ihrem Namen – ohne umgebenden Text. Was dort unverständlich ist, ist es auch beim Ausfüllen. Das Vorgehen steht unter Mit NVDA testen.
4. Sichtbaren Text und Namen abgleichen. Für 2.5.3 Beschriftung im Namen muss der sichtbare Text im zugänglichen Namen enthalten sein – sonst greift keine Spracheingabe.
5. Automatisiert gegenprüfen. axe DevTools oder der Struktur-Check finden fehlende Namen und doppelte id-Werte zuverlässig. Was sie nicht beurteilen können, ist, ob ein Name die richtige Information trägt – dafür bleibt Schritt 3.

Häufige Fehler

• placeholder statt label. Der häufigste Fehler überhaupt – und für mich ein echter Klassiker des „sieht hübsch aus, funktioniert aber nicht“.
• Label nicht verknüpft. Ein <label> ohne for (oder ohne Umschließen) ist nur Text daneben. Die programmatische Verbindung fehlt.
• Doppelte oder fehlende id. for zeigt dann ins Leere oder auf das falsche Feld.
• Nur eine Grafik als Beschriftung. Ein Icon ohne Textalternative benennt nichts – siehe Icons & SVGs.
• Sichtbares Label und abweichendes aria-label. Spracheingabe-Nutzer sagen „Klick E-Mail“, treffen aber den unsichtbaren Namen nicht. Sichtbarer Text und zugänglicher Name sollten übereinstimmen (WCAG 2.5.3, „Label in Name“).
• autocomplete vergessen. Bei Feldern, die persönliche Daten des Nutzers abfragen, verlangt 1.3.5 Eingabezweck bestimmen auf Stufe AA zusätzlich den maschinenlesbaren Zweck – autocomplete="email" statt nur eines guten Labels.
• Das Sternchen als einziger Pflichthinweis. „*“ im Labeltext wird je nach Screenreader als „Stern“ oder gar nicht vorgelesen. Wie es richtig geht, steht unter Validierung & Pflichtfelder.

Häufige Fragen

Reicht ein aria-label nicht völlig aus?

Technisch benennt es das Feld, ja. Sehende Nutzer ohne Screenreader sehen dann aber gar keine Beschriftung. Ein sichtbares Label hilft allen – darum ist es die erste Wahl, und aria-label nur der Notnagel.

Muss jedes Feld ein eigenes Label haben?

Ja. Auch Checkboxen, Radio-Buttons und <select> brauchen je ein verknüpftes Label. Ein Datumsbereich aus zwei Feldern bekommt zwei Labels („von“ / „bis“), zusammengehalten von einer Gruppen-Beschriftung.

Wie beschrifte ich einen Button?

Bei einem <button> ist der sichtbare Textinhalt zugleich der Name – ein zusätzliches <label> ist weder nötig noch vorgesehen. Worauf es bei Buttons ankommt, steht unter Buttons vs. Links.

Sind Floating Labels barrierefrei?

Ja, solange der Text sichtbar bleibt, sobald das Feld ausgefüllt ist, und der verkleinerte Zustand noch 4,5:1 Kontrast erreicht. Beides ist Handwerk am CSS, kein Problem des Musters. Was nicht funktioniert: ein placeholder, der sich als Floating Label ausgibt und beim Tippen verschwindet.

Zählt der Text neben einer Checkbox automatisch als Label?

Nein. Optische Nähe erzeugt keine Verknüpfung – der Text muss in einem <label> stehen, das per for auf die id der Checkbox zeigt oder sie umschließt. Der Unterschied ist direkt spürbar: Beim korrekt verknüpften Label schaltet ein Klick auf den Text die Checkbox um, sonst muss man das 16 Pixel große Kästchen selbst treffen.

Fazit

Beschrifte jedes Feld mit einem verknüpften <label> – explizit über for/id, sichtbar wo immer möglich. Das ist die wichtigste und billigste Maßnahme für zugängliche Formulare. Alles Weitere, von Pflichtfeldern über Fehlermeldungen bis zu Feldgruppen, baut auf dieser einen sauberen Verbindung auf. Wenn ich ein Formular prüfe, ist es das Erste, wonach ich schaue.

Quellen

• HTML Standard: The label element (WHATWG – Definition der beschriftbaren Elemente)
• Accessible Name and Description Computation (W3C – die Rangfolge aria-labelledby vor aria-label vor label)
• Understanding SC 3.3.2: Labels or Instructions (W3C)
• Understanding SC 2.5.3: Label in Name (W3C)