Formulare barrierefrei gestalten: Labels, Fehler, Validierung

Barrierefreie HTML-Formulare: Labels korrekt verknüpfen, Fehlermeldungen zugänglich machen, Pflichtfelder auszeichnen und WCAG 3.3 erfüllen. Mit Code-Beispielen.

EAA Checker Team7 Min. Lesezeit

Formulare sind eine der kritischsten Stellen für Barrierefreiheit — und gleichzeitig eine der am häufigsten falsch implementierten. WCAG widmet Richtlinie 3.3 (Input Assistance) fünf Erfolgskriterien speziell für Formulare. Dieser Artikel zeigt, was korrekte Formular-Implementierung bedeutet — mit konkreten Code-Beispielen.

Labels: Die Grundlage zugänglicher Formulare

Jedes Formularfeld braucht ein Label — eine Beschriftung, die programmatisch mit dem Feld verknüpft ist. Das bedeutet: nicht nur visuell nah am Feld, sondern im HTML verbunden.

Methode 1: for/id-Verknüpfung (bevorzugt)

<!-- RICHTIG: Label mit for-Attribut verknüpft -->
<label for="email">E-Mail-Adresse *</label>
<input
  type="email"
  id="email"
  name="email"
  required
  autocomplete="email"
/>

<!-- FALSCH: Label nur visuell nah, nicht verknüpft -->
<p>E-Mail-Adresse</p>
<input type="email" name="email" />

Methode 2: Verschachteltes Label

<!-- Auch korrekt: Input innerhalb des Labels -->
<label>
  Telefonnummer
  <input type="tel" name="phone" autocomplete="tel" />
</label>

Methode 3: aria-label (wenn kein sichtbares Label möglich)

<!-- Nur wenn absolut kein sichtbares Label möglich ist -->
<input
  type="search"
  aria-label="Produkte suchen"
  placeholder="Suchbegriff eingeben..."
/>

Hinweis: Placeholder-Text ist kein Label-Ersatz. Er verschwindet beim Tippen, hat oft zu wenig Kontrast und wird von Screen Readern unterschiedlich behandelt. Verwenden Sie immer ein echtes Label zusätzlich zum Placeholder.

Pflichtfelder korrekt auszeichnen

<!-- Am Formularanfang: Bedeutung erklären -->
<p>Felder mit * sind Pflichtfelder.</p>

<!-- Pflichtfeld: required + visuelle Markierung -->
<label for="name">
  Name
  <span aria-hidden="true"> *</span>
</label>
<input
  type="text"
  id="name"
  name="name"
  required
  aria-required="true"
/>

<!-- aria-hidden="true" auf dem Sternchen:
     Screen Reader liest "required" durch das required-Attribut vor,
     das Sternchen muss nicht extra vorgelesen werden -->

Fehlermeldungen: Was WCAG 3.3 fordert

WCAG 3.3 hat mehrere Erfolgskriterien für Fehlervermeidung und -korrektur:

KriteriumLevelAnforderung
3.3.1 Error IdentificationAFehler werden erkannt und beschrieben
3.3.2 Labels or InstructionsALabels oder Anweisungen für alle Eingaben
3.3.3 Error SuggestionAAVerbesserungsvorschlag wenn Fehler bekannt
3.3.4 Error PreventionAARückgängig-machen, Prüfen, Bestätigen bei wichtigen Aktionen

Gutes Fehlermeldungs-Beispiel

<!-- Feldzustand: kein Fehler -->
<label for="plz">Postleitzahl *</label>
<input
  type="text"
  id="plz"
  name="plz"
  required
  pattern="[0-9]{5}"
  aria-describedby="plz-hint"
/>
<span id="plz-hint" class="text-gray-500 text-sm">
  5-stellige deutsche Postleitzahl
</span>

<!-- Feldzustand: nach fehlerhafter Eingabe -->
<label for="plz">Postleitzahl *</label>
<input
  type="text"
  id="plz"
  name="plz"
  required
  aria-invalid="true"
  aria-describedby="plz-error"
  value="123"
/>
<span
  id="plz-error"
  role="alert"
  class="text-red-600 text-sm"
>
  Bitte geben Sie eine gültige Postleitzahl ein (5 Ziffern, z.B. 10115).
</span>

Fokus-Management bei Fehlern

Wenn ein Formular mit Fehlern abgeschickt wird, muss der Fokus so gesetzt werden, dass Tastaturnutzer sofort zu den Fehlern gelangen:

// Option 1: Fokus auf Fehlerzusammenfassung
function handleSubmit(e) {
  e.preventDefault();
  const errors = validateForm();

  if (errors.length > 0) {
    const summary = document.getElementById('error-summary');
    summary.innerHTML = `
      <h2>Bitte korrigieren Sie ${errors.length} Fehler:</h2>
      <ul>
        ${errors.map(err =>
          `<li><a href="#${err.fieldId}">${err.message}</a></li>`
        ).join('')}
      </ul>
    `;
    summary.setAttribute('tabindex', '-1');
    summary.focus(); // Fokus auf Zusammenfassung
  }
}

// Option 2: Fokus auf erstes fehlerhaftes Feld
const firstError = document.querySelector('[aria-invalid="true"]');
if (firstError) firstError.focus();

autocomplete-Attribute: UX und Barrierefreiheit

WCAG 1.3.5 (Identify Input Purpose, Level AA) fordert, dass der Zweck von Eingabefeldern programmatisch erkennbar ist. Das ermöglicht Browsern und Hilfstechnologien, Felder automatisch auszufüllen:

<input type="text"    autocomplete="given-name"   />  <!-- Vorname -->
<input type="text"    autocomplete="family-name"  />  <!-- Nachname -->
<input type="email"   autocomplete="email"        />  <!-- E-Mail -->
<input type="tel"     autocomplete="tel"          />  <!-- Telefon -->
<input type="text"    autocomplete="street-address"/>  <!-- Straße -->
<input type="text"    autocomplete="postal-code"  />  <!-- PLZ -->
<input type="text"    autocomplete="cc-number"    />  <!-- Kreditkartennummer -->
<input type="password" autocomplete="current-password"/> <!-- Passwort -->

Besonders wichtig für Menschen mit Mobilitätseinschränkungen: autocomplete reduziert die notwendigen Tastatureingaben erheblich.

Checkliste: Barrierefreie Formulare

Jedes Feld hat ein sichtbares, programmatisch verknüpftes Label (for/id oder verschachtelt)

Kein Placeholder als einziges Label

Pflichtfelder mit required-Attribut ausgezeichnet

Fehlermeldungen via aria-describedby mit dem Feld verknüpft

aria-invalid='true' bei Feldern mit Fehlern gesetzt

Fehlermeldungen konkret und mit Lösungshinweis

Fokus nach Submit auf Fehler oder erste Fehlermeldung

Autocomplete-Attribute für persönliche Daten gesetzt

Kontrast der Fehlermeldungen ≥ 4,5:1

Keine rein farbbasierte Fehlermarkierung (z.B. nur rote Border ohne Text)

Formulare vollständig per Tastatur bedienbar

Submit-Button mit aussagekräftigem Text (nicht nur 'Senden')

Formulare auf Ihrer Website prüfen

Unser Scanner erkennt fehlende Labels, falsche aria-Attribute und andere Formular-Probleme auf Ihrer Website automatisch. Starten Sie den kostenlosen Scan.

Website kostenlos prüfen →

Häufige Fragen

Reicht ein Placeholder als Beschriftung für ein Formularfeld?
Nein. Placeholder-Text verschwindet beim Eingeben und ist standardmäßig zu hell für ausreichenden Kontrast. Er ersetzt kein Label. WCAG 1.3.1 und 3.3.2 fordern sichtbare Labels für alle Eingabefelder. Der Placeholder kann als zusätzlicher Hinweis dienen (z.B. Beispiel-Format), aber das Label muss dauerhaft sichtbar bleiben.
Wie zeichne ich Pflichtfelder barrierefrei aus?
Nutzen Sie das native required-Attribut — es kommuniziert Pflichtfelder automatisch an Screen Reader ("Pflichtfeld"). Ergänzen Sie zusätzlich eine visuelle Kennzeichnung (z.B. Sternchen *) und erklären Sie deren Bedeutung am Formularanfang ("* Pflichtfeld"). Verlassen Sie sich nicht nur auf Farbe (Rot = Pflicht), da farbenblinde Nutzer das nicht erkennen.
Wo sollen Fehlermeldungen erscheinen?
Fehlermeldungen sollen: 1. Direkt beim betroffenen Feld erscheinen (nicht nur oben auf der Seite). 2. Über aria-describedby mit dem Feld verknüpft sein. 3. Den Fehler konkret beschreiben (nicht nur 'Ungültige Eingabe'). 4. Sagen, wie der Fehler behoben werden kann. 5. Den Fokus nach dem Submit auf das erste fehlerhafte Feld setzen oder auf eine Fehlerzusammenfassung.
Was ist der Unterschied zwischen aria-describedby und aria-errormessage?
aria-describedby verknüpft ein Feld mit einer allgemeinen Beschreibung oder Hilfstexten — auch Fehlermeldungen können so verknüpft werden. aria-errormessage (ARIA 1.1) ist speziell für Fehlermeldungen gedacht und wird zusammen mit aria-invalid='true' verwendet. Browserunterstützung für aria-errormessage ist noch nicht vollständig — aria-describedby ist die sicherere Wahl.