Placeholder ist kein Label: So machen Sie Formulare BFSG- und WCAG-konform

Viele Formulare scheitern nicht an komplexer Technik, sondern an einem simplen Musterfehler: Das sichtbare Label fehlt, stattdessen steht im Feld nur ein grauer Placeholder wie „Ihre E-Mail“. Das sieht im Mockup oft sauber aus, ist in der Praxis aber riskant – für Conversion, Nutzbarkeit und Barrierefreiheit.

Genau hier greifen die Anforderungen aus BFSG, WCAG und EN 301 549. Wenn Nutzerinnen und Nutzer Felder nicht eindeutig verstehen, Hinweise beim Tippen verschwinden oder Fehlermeldungen nicht sauber mit dem Feld verbunden sind, wird aus einem Kontaktformular schnell ein Beschwerdepunkt.

Die gute Nachricht: Sie müssen Formulare nicht neu erfinden. In den meisten Fällen reichen saubere Labels, verständliche Hilfetexte, korrekt verknüpfte Fehlerhinweise und ein kurzer Praxistest mit Tastatur und Screenreader.

Warum „Placeholder ist kein Label“ so wichtig ist

Ein Placeholder darf nur ein kurzer Hinweis oder ein Beispiel sein, etwa „name@firma.de“. Er ist kein Ersatz für eine sichtbare Beschriftung.

Das hat drei praktische Gründe:

• Der Hinweis verschwindet beim Tippen. Nutzer können während der Eingabe nicht mehr prüfen, was das Feld eigentlich verlangt.
• Placeholder-Texte haben oft schlechten Kontrast. Gerade auf mobilen Geräten oder bei Sehschwäche sinkt die Lesbarkeit.
• Assistive Technologien verlassen sich auf echte Beschriftungen. Screenreader lesen verknüpfte Labels zuverlässig vor; Placeholder-Inhalte dagegen sind kein belastbarer Ersatz.

Für Teams ist das der Kern der Aussage „placeholder ist kein label“: Wenn das Label fehlt, fehlt nicht nur ein Detail, sondern die eigentliche Feldbedeutung.

Welche WCAG- und BFSG-Anforderungen hier berührt werden

Für Websites und Web-Apps laufen die BFSG-Anforderungen in der Praxis auf die Einhaltung einschlägiger WCAG-Kriterien hinaus. Bei Formularen sind vor allem diese Punkte relevant:

• Info and Relationships / 1.3.1: Beschriftungen und Feldbeziehungen müssen strukturell erkennbar sein.
• Labels or Instructions / 3.3.2: Nutzer müssen Labels oder klare Anweisungen erhalten.
• Error Identification / 3.3.1: Fehler müssen verständlich erkennbar sein.
• Name, Role, Value / 4.1.2: Form Controls brauchen einen sauberen zugänglichen Namen und nachvollziehbare Zustände.

Wichtig in der Praxis: Ein Formular kann technisch irgendeinen zugänglichen Namen haben und trotzdem für echte Nutzer schlecht sein, wenn sichtbare Labels fehlen. BFSG-Konformität entsteht nicht durch ARIA-Tricks allein, sondern durch verständliche, für alle sichtbare Formulare.

Die 4 häufigsten Formularfehler in der Praxis

1. Placeholder statt sichtbarem Label

Typischer Fehler:

<input type="email" placeholder="Ihre E-Mail" />

Das Problem: Sobald jemand tippt, ist die einzige Orientierung weg. In längeren Formularen führt das schnell zu Unsicherheit, besonders bei Pflichtfeldern, Fachbegriffen oder ähnlichen Feldern wie „E-Mail“, „Rechnungs-E-Mail“ und „Ansprechpartner E-Mail“.

Besser:

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" placeholder="name@firma.de" autocomplete="email" />

So bleibt die Beschriftung sichtbar, und der Placeholder dient nur als Beispiel.

2. Hinweise nur im Label oder nur im Placeholder verstecken

Viele Formulare versuchen Formatregeln in ein Label oder einen Placeholder zu quetschen, etwa „Passwort“ oder „MM/JJ“. Das reicht oft nicht.

Besser: kurze Beschriftung plus separater Hilfetext.

<label for="geburtsdatum">Geburtsdatum</label>
<input type="text" id="geburtsdatum" name="geburtsdatum" aria-describedby="geburtsdatum-hint" />
<p id="geburtsdatum-hint">Bitte im Format TT.MM.JJJJ eingeben.</p>

Genau dafür ist aria-describedby sinnvoll: Es verbindet zusätzliche Beschreibung mit dem Feld, ohne das eigentliche Label zu ersetzen.

3. Fehlermeldung ohne Bezug zum konkreten Feld

Ein roter Kasten mit „Bitte prüfen Sie Ihre Eingaben“ hilft in echten Formularen wenig. Nutzer müssen sofort erkennen:

• welches Feld falsch ist,
• was genau falsch ist,
• wie die korrekte Eingabe aussieht.

Besser:

<label for="telefon">Telefonnummer</label>
<input
  type="tel"
  id="telefon"
  name="telefon"
  aria-describedby="telefon-hint telefon-error"
  aria-invalid="true"
/>
<p id="telefon-hint">Optional mit Landesvorwahl, z. B. +49 30 123456.</p>
<p id="telefon-error">Bitte geben Sie nur Ziffern, Leerzeichen und ein führendes Pluszeichen ein.</p>

So können Screenreader Hilfetext und Fehlermeldung am Feld ausgeben. Für sehende Nutzer steht die Meldung direkt dort, wo sie gebraucht wird.

4. Pflichtfelder nur mit Sternchen oder nur per Farbe markieren

Ein Sternchen ist okay – aber nicht allein. Nur Rot ist ebenfalls zu wenig.

Robuster ist diese Kombination:

• sichtbares Label,
• klare Kennzeichnung „Pflichtfeld“ oder Legende,
• required im Feld,
• verständliche Fehlermeldung bei leerer Eingabe.

Gerade bei Checkout- oder Kontaktformularen spart das Rückfragen und reduziert Abbrüche.

So bauen Sie barrierefreie Labels sauber auf

Wenn Sie Formulare BFSG- und WCAG-konform aufsetzen wollen, gilt diese Reihenfolge:

1. Jedes Feld bekommt ein sichtbares Label.
2. Label und Feld werden technisch verknüpft (for ↔ id).
3. Zusätzliche Hinweise kommen außerhalb des Felds als normaler Text.
4. Hinweise und Fehler werden bei Bedarf mit aria-describedby referenziert.
5. Der Placeholder bleibt optional und dient nur als Beispiel, nicht als eigentliche Beschriftung.

Ein solides Grundmuster sieht so aus:

<div class="form-group">
  <label for="kontakt-email">Geschäftliche E-Mail-Adresse</label>
  <input
    type="email"
    id="kontakt-email"
    name="kontakt-email"
    autocomplete="email"
    aria-describedby="kontakt-email-hint"
    required
  />
  <p id="kontakt-email-hint">Wir nutzen Ihre E-Mail nur zur Beantwortung Ihrer Anfrage.</p>
</div>

Das ist meist stabiler als komplexe Custom-Patterns mit Floating Labels, die bei Zoom, Autofill oder Fehlermeldungen schnell unübersichtlich werden.

aria-describedby für Hilfetexte und Fehlermeldungen richtig nutzen

Das Keyword aria-describedby fehlermeldung taucht nicht zufällig oft auf: Genau daran scheitern viele Formulare in Audits.

Die Faustregel ist einfach:

• Label = Was ist das Feld?
• Description = Was muss ich beachten?
• Error = Was ist schiefgelaufen und wie korrigiere ich es?

Sinnvolle Nutzung

aria-describedby ist passend für:

• Format-Hinweise
• Datenschutz- oder Prozesshinweise
• Zusatzinformationen bei komplexen Feldern
• konkrete Fehlermeldungen

Typische Fehlanwendungen

Nicht sinnvoll ist es,

• ein fehlendes Label durch aria-describedby zu ersetzen,
• sehr lange Textblöcke daran zu hängen,
• dieselbe ID mehrfach oder inkonsistent zu verwenden,
• Fehlermeldungen nur visuell einzublenden, aber nicht zu referenzieren.

Wenn Sie mit React, Vue oder einem Design System arbeiten, lohnt sich ein standardisiertes Form-Pattern mit festem API-Schema für label, hint, error und required. Dann lösen Sie das Problem einmal zentral statt in jedem Formular neu.

Kontaktformular barrierefrei machen: der pragmatische 15-Minuten-Test

Wenn Sie wissen möchten, ob Ihr kontaktformular barrierefrei ist, brauchen Sie kein Großprojekt. Diese Routine deckt erstaunlich viel auf:

1. Seite ohne Maus bedienen.
2. Mit Tab durch jedes Feld springen.
3. Prüfen, ob jedes Feld ein sichtbares, eindeutiges Label hat.
4. Absichtlich falsche oder leere Eingaben absenden.
5. Prüfen, ob Fehler direkt am Feld erscheinen und verständlich sind.
6. Prüfen, ob der Fokus sichtbar bleibt und sinnvoll zum ersten Fehler führt.
7. Testen, ob Hinweise wie Formatregeln auch nach Beginn der Eingabe noch verfügbar sind.

Wenn Sie dabei rätseln müssen, ist das Formular nicht robust genug.

Gute und schlechte Beispiele für typische Felder

E-Mail-Feld

Schlecht:

• Placeholder: „Ihre E-Mail“
• keine sichtbare Beschriftung
• Fehlertext nur global oben auf der Seite

Gut:

• Label: „E-Mail-Adresse“
• optionaler Placeholder: „name@firma.de“
• Hilfetext bei Bedarf
• Fehlermeldung direkt am Feld und mit aria-describedby verknüpft

Telefonnummer

Schlecht:

• Label: „Telefon“
• keine Angabe zum gewünschten Format

Gut:

• Label: „Telefonnummer“
• Hilfetext: „Optional mit Landesvorwahl, z. B. +49 30 123456“

Nachrichtenfeld im Kontaktformular

Schlecht:

• nur Placeholder „Ihre Nachricht“

Gut:

• sichtbares Label „Nachricht“
• optionaler Hinweis „Bitte beschreiben Sie Ihr Anliegen möglichst konkret.“

Was Teams sofort priorisieren sollten

Wenn Sie mehrere Formulare haben, starten Sie nicht mit einer Vollsanierung aller Seiten, sondern mit den Conversion-kritischen Stellen:

1. Kontaktformular
2. Lead-Formulare
3. Login / Passwort vergessen
4. Checkout / Adress- und Zahlungsformulare
5. Support- oder Terminformulare

Genau dort entstehen Beschwerden, Abbrüche und das höchste BFSG-Risiko. Für angrenzende Themen helfen Ihnen auch diese Ratgeber:

• Barrierefreie Formulare: Labels, Fehler & Pflichtfelder
• BFSG: Kontaktformular barrierefrei machen (Labels, Fehlertexte, Fokus)
• Tastaturbedienung testen: Fokus, Tab-Reihenfolge & Skip-Links
• Barrierefreier Checkout: Formulare, Zahlarten, Fehlertexte im E-Commerce
• Die 15 häufigsten Barrierefreiheits-Fehler – und wie Sie sie einfach beheben

Fazit: Sichtbare Labels zuerst, ARIA danach

Wenn Sie sich nur eine Regel merken wollen, dann diese: Placeholder ist kein Label.

Ein barrierefreies Formular braucht zuerst verständliche, sichtbare Beschriftungen. Danach folgen Hilfetexte, Fehlermeldungen, Fokusführung und saubere technische Verknüpfungen. aria-describedby ist dabei sehr nützlich – aber nur als Ergänzung, nicht als Ersatz für gutes Formulardesign.

Wer Formulare so aufbaut, erfüllt nicht nur WCAG-Anforderungen sauberer. Sie senken auch Abbruchquoten, reduzieren Supportaufwand und machen aus einem häufigen Schwachpunkt einen robusten Teil Ihrer Website.

CTA: Formular-Risiken jetzt schnell prüfen

Wenn Sie herausfinden möchten, ob Ihre Formulare bereits die typischen BFSG- und WCAG-Probleme enthalten, starten Sie mit einem schnellen Scan und priorisieren Sie danach die kritischsten Fixes.

Jetzt BFSG-Scan starten

Quellen

• MDN: HTML attribute placeholder
• MDN: ARIA aria-describedby attribute
• W3C WAI: Forms Tutorial – Form Instructions
• W3C WAI: Understanding Success Criterion 3.3.2 Labels or Instructions
• W3C WAI: Technique ARIA21 – Using aria-invalid to Indicate an Error Field

Hinweis: Dieser Artikel stellt keine Rechtsberatung dar, sondern dient der allgemeinen Information.