WCAG 3.3.2: Beschriftungen oder Anweisungen

WCAG 3.3.2 verlangt, dass überall dort, wo Nutzereingaben erwartet werden, Beschriftungen oder Anweisungen bereitstehen: Jedes Feld sagt sichtbar, was hineingehört – einschließlich Format und Pflichtstatus. Ein Platzhalter erfüllt das nicht, weil er beim Tippen verschwindet.

(Englisch: Labels or Instructions.)

Das Wichtigste in Kürze

• 3.3.2 verlangt die sichtbare Beschriftung, die technische Verknüpfung (<label for>) verlangt 1.3.1. Beide zusammen ergeben ein brauchbares Feld.
• Anweisungen müssen vor der Eingabe dastehen, nicht erst in der Fehlermeldung danach. Format, erlaubte Zeichen, Beispielwerte gehören ans Feld.
• Pflichtfelder gehören gekennzeichnet – als Wort, als erklärtes Sternchen oder im Label selbst. Ein rotes Sternchen ohne Legende genügt nicht, weil Farbe nie das einzige Signal sein darf.
• Platzhaltertext ist kein Label. Er verschwindet beim Tippen, hat oft zu wenig Kontrast und lässt ausgefüllte Formulare fälschlich fertig wirken.
• Zusammengehörige Felder brauchen eine Gruppenbeschriftung über <fieldset> und <legend> – sonst fehlt Radiobuttons die Frage.
• Im BITV-Test heißt der Prüfschritt „3.3.2 Beschriftungen von Formularelementen vorhanden“; die programmatische Zuordnung wird separat unter 1.3.1h geprüft.

Reicht ein Platzhalter als Beschriftung?

Nein – der Platzhalter verschwindet beim Tippen. Jedes Feld braucht eine sichtbare Beschriftung samt Format- und Pflichtangabe.

Der Normtext ist einer der kürzesten der ganzen WCAG: Wenn der Inhalt eine Eingabe durch die Nutzenden verlangt, werden Beschriftungen oder Anweisungen bereitgestellt. Was daraus in der Prüfpraxis folgt, ist deutlich mehr:

• Sichtbares Label pro Feld – dauerhaft, nicht als verschwindender Platzhalter, nicht nur als Tooltip beim Überfahren.
• Formatangaben, wo ein bestimmtes Format erwartet wird: „TT.MM.JJJJ“, „IBAN ohne Leerzeichen“, „mindestens 12 Zeichen“. Und zwar am Feld, nicht in der Fehlermeldung, die danach kommt.
• Pflichtfeld-Kennzeichnung, damit man vor dem Absenden weiß, was nötig ist. In der Praxis am robustesten: das Wort „(Pflicht)“ im Label, zusätzlich required im Markup.
• Gruppen-Beschriftungen für Felder, die nur gemeinsam Sinn ergeben: Radiobutton-Sets, Adressblöcke, Zeiträume mit Von und Bis.

Wie ausführlich eine Anweisung sein muss, hängt davon ab, wie überraschend die Anforderung ist. „Name“ braucht keine Erklärung. „Aktenzeichen“ braucht ein Beispiel. Eine Passwortregel braucht die vollständige Liste der Bedingungen – sichtbar, bevor jemand tippt, nicht als rote Zeile danach.

Den Wortlaut samt Techniken führt das Understanding-Dokument des W3C zu 3.3.2 auf.

Wen betrifft es besonders?

Menschen mit kognitiven Einschränkungen und Gedächtnisproblemen trifft die Platzhalter-Falle am härtesten: Verschwindet die Beschriftung beim Tippen, ist der Feldzweck weg – und beim Nachkontrollieren vor dem Absenden steht man vor einer Liste von Werten ohne Namen. Das ist einer der häufigsten Gründe, warum Formulare abgebrochen werden.

Screenreader-Nutzer hören bei einem Feld ohne Beschriftung nur „Eingabefeld, leer“. Selbst wenn ein Platzhalter vorgelesen wird – was nicht alle Kombinationen aus Browser und Screenreader tun –, ist er nach der ersten Eingabe verschwunden.

Sprachsteuerungs-Nutzer sprechen Felder über ihren sichtbaren Namen an: „Klicke Geburtsdatum“ funktioniert nur, wenn dieser Text auch dasteht. Und für alle anderen ist eine Formatangabe vor der Eingabe schlicht der Unterschied zwischen einem Anlauf und dreien.

Richtig & falsch im Code

<!-- Falsch: Platzhalter spielt Label -->
<input type="text" placeholder="Geburtsdatum" />

<!-- Falsch: Format steht erst in der Fehlermeldung -->
<label for="geb">Geburtsdatum</label>
<input id="geb" name="geb" />
<!-- … nach dem Absenden: „Bitte im Format TT.MM.JJJJ eingeben" -->

<!-- Falsch: Sternchen ohne Erklärung, Bedeutung nur über Farbe -->
<label for="mail">E-Mail <span style="color:red">*</span></label>

<!-- Richtig: sichtbares Label, Format vorab, Pflichtstatus im Text -->
<label for="geburtsdatum">Geburtsdatum (Pflichtfeld)</label>
<input id="geburtsdatum" name="geburtsdatum" required
       inputmode="numeric" autocomplete="bday"
       aria-describedby="geb-hinweis" />
<p id="geb-hinweis">Format TT.MM.JJJJ, zum Beispiel 24.06.1985</p>

Der Platzhalter darf bleiben – als Ergänzung, nie als Ersatz:

<!-- Richtig: Label trägt den Namen, Platzhalter zeigt das Format -->
<label for="iban">IBAN (Pflichtfeld)</label>
<input id="iban" name="iban" required placeholder="DE00 0000 0000 0000 0000 00" />

Für Gruppen führt kein Weg an <fieldset> vorbei – ohne <legend> fehlt den einzelnen Optionen die Frage, zu der sie gehören:

<!-- Richtig: die Gruppe hat eine eigene Beschriftung -->
<fieldset>
  <legend>Wie möchten Sie benachrichtigt werden? (Pflichtangabe)</legend>
  <label><input type="radio" name="kanal" value="mail" /> E-Mail</label>
  <label><input type="radio" name="kanal" value="sms" /> SMS</label>
</fieldset>

Und ein Hinweis, der viel Ärger spart: aria-label ist hier die schlechteste Lösung. Es erzeugt einen Namen für assistive Technologien, aber nichts Sichtbares – 3.3.2 verlangt aber genau das Sichtbare. Mehr dazu unter Labels & Beschriftungen.

So testest du es

1. Sichtprüfung im leeren Zustand: Hat jedes Feld eine dauerhaft sichtbare Beschriftung? Stehen Formatanforderungen da, bevor jemand tippt?
2. Die Ausfüll-Probe: Formular komplett ausfüllen und dann von oben nach unten lesen – weiß man bei jedem Feld noch, was es war? Das ist der Platzhalter-Test, und er entlarvt das Muster in zehn Sekunden.
3. Pflichtfelder prüfen: Sind sie als Text oder erklärtes Symbol gekennzeichnet und technisch mit required versehen? Reicht die Angabe allein über Farbe, ist es ein Verstoß.
4. Gruppen kontrollieren: Haben Radiobutton-Sets und zusammengehörige Feldblöcke eine <legend>? Ohne sie hört man beim Screenreader die Optionen ohne die Frage.
5. Screenreader-Gegenprobe: Mit NVDA mit Tab durch das Formular – wird zu jedem Feld Name, Pflichtstatus und Hinweis angesagt?
6. Fehlerfall durchspielen: Absenden mit leeren Pflichtfeldern. Standen die Anforderungen vorher da, oder erfährt man sie erst jetzt?

Felder ganz ohne Beschriftung – und solche, die nur einen placeholder haben – findet der Struktur-Check automatisch.

Häufiger Fehler in der Praxis

Der Dauerbrenner ist das Platzhalter-Formular. Es sieht in jedem Entwurf großartig aus: aufgeräumt, luftig, ohne Beschriftungstexte. Der Haken zeigt sich erst im ausgefüllten Zustand, und den sieht man in Design-Dateien praktisch nie. Wer das Muster behalten will, hat eine saubere Alternative: das schwebende Label, das beim Fokus nach oben rutscht statt zu verschwinden. Dann bleibt die Beschriftung sichtbar – nur eben kleiner.

Der zweite Fall sind Formatanforderungen, die als Fehlermeldung getarnt sind. Ein Passwortfeld ohne jeden Hinweis, und nach dem Absenden erscheint: „Das Passwort muss mindestens zwölf Zeichen, eine Ziffer und ein Sonderzeichen enthalten.“ Diese Information lag die ganze Zeit vor, sie wurde nur nicht angezeigt. Das kostet jeden Nutzer einen Anlauf.

Der dritte: das unerklärte Sternchen. Ein rotes * neben dem Label, keine Legende, keine Textalternative. Für Sehende ist es Konvention, für den Screenreader ein „Stern“ ohne Bedeutung, und über Farbe allein transportiert es gar nichts. Ne Legende in der Form „* Pflichtfeld“ oben am Formular kostet eine Zeile und räumt den Punkt ab – noch besser ist das Wort direkt im Label.

Häufige Fragen

Reicht ein Platzhalter als Beschriftung?

Nein. Er verschwindet beim Tippen, wird nicht von allen Kombinationen aus Browser und Screenreader zuverlässig als Name gewertet und liegt in den Browser-Standardfarben meist unter dem geforderten Kontrast. Als Ergänzung für ein Formatbeispiel ist er nützlich, als Ersatz für das Label nicht.

Muss die Beschriftung über dem Feld stehen?

Nein, die Position gibt das Kriterium nicht vor. Üblich und gut lesbar ist oben links; rechts neben Checkboxen und Radiobuttons ist ebenfalls Konvention. Wichtig ist nur, dass die Zuordnung eindeutig ist – bei mehrspaltigen Formularen wird sie das schnell nicht mehr.

Wie kennzeichne ich Pflichtfelder richtig?

Am robustesten im Label selbst: „E-Mail-Adresse (Pflichtfeld)“. Wer das Sternchen behalten will, braucht eine sichtbare Erklärung am Formularanfang und sollte das Symbol für assistive Technologien auflösen. Zusätzlich gehört required ins Markup, damit der Pflichtstatus auch programmatisch ankommt – Details unter Validierung und Pflichtfelder.

Was ist der Unterschied zwischen 3.3.2 und 1.3.1?

3.3.2 verlangt, dass eine Beschriftung sichtbar vorhanden ist. 1.3.1 verlangt, dass sie programmatisch mit dem Feld verbunden ist. Ein Text neben einem Feld ohne <label for> erfüllt 3.3.2 und verstößt gegen 1.3.1; ein aria-label ohne sichtbaren Text erfüllt 1.3.1 und verstößt gegen 3.3.2. Man braucht beides.

Gilt 3.3.2 auch für die Suchfunktion mit Lupensymbol?

Ja. Ein Suchfeld ist ein Eingabefeld. Wenn das Design kein sichtbares „Suche“ zulässt, ist der übliche Weg ein sichtbar beschrifteter Button neben dem Feld, dessen Beschriftung das Feld miterklärt – oder ein Label, das per visually-hidden nur optisch entfällt. Letzteres ist ein Kompromiss: Er erfüllt 1.3.1 sicher, bei 3.3.2 wird er in strengen Prüfungen diskutiert.

Verwandte Themen

• Labels & Beschriftungen – das Grundlagen-Muster mit allen Varianten
• Validierung & Pflichtfelder – Pflichtstatus und Fehlerbehandlung
• fieldset & legend – Beschriftung für Feldgruppen
• 3.3.1 Fehlererkennung – wenn trotz Anleitung etwas schiefgeht
• 1.3.1 Info und Beziehungen – die programmatische Seite derselben Sache