Die meisten HTML-Formulare in der Produktion verwenden drei Input-Typen: text, password und submit. Das war's. Dabei hat HTML seit Jahren umfangreiche eingebaute Input-Typen, Constraint-Validierung und Barrierefreiheitsfunktionen — alles ohne JavaScript, ohne npm install. Zeit, sie zu nutzen.

Input-Typen, die es wert sind

Jeder Input-Typ erledigt echte Arbeit: Er löst die richtige Mobile-Tastatur aus, bietet eingebaute Validierung und kommuniziert die Absicht an assistive Technologien. Das sind die, die in realen Projekten ständig auftauchen:

html
<!-- Email: validates format, shows email keyboard on mobile -->
<input type="email" name="email" autocomplete="email">

<!-- Phone: shows numeric keypad on mobile -->
<input type="tel" name="phone" autocomplete="tel" pattern="[0-9]{10,15}">

<!-- Number: spin buttons, min/max/step validation -->
<input type="number" name="quantity" min="1" max="99" step="1" value="1">

<!-- Date: native date picker (no library needed) -->
<input type="date" name="birthdate" min="1900-01-01" max="2026-12-31">

<!-- Range: slider with min/max/step -->
<input type="range" name="volume" min="0" max="100" step="5" value="50">

<!-- Color: native color picker -->
<input type="color" name="theme_color" value="#0066cc">

<!-- File: single or multiple file upload -->
<input type="file" name="resume" accept=".pdf,.doc,.docx">
<input type="file" name="photos" accept="image/*" multiple>
Praxistipp: type="date" gibt den Wert unabhängig vom Locale des Benutzers im Format YYYY-MM-DD zurück — genau das, was beim Senden an den Server gewünscht ist. Datumsangaben möglichst nie aus type="text"-Feldern parsen.

Label-Zuordnung — Richtig machen

Labels sind keine optionale Dekoration. Sie sind das primäre Mittel, mit dem Screen-Reader Eingabefelder identifizieren, und ein Klick auf ein Label sollte das zugehörige Eingabefeld fokussieren. Es gibt zwei valide Ansätze:

html
<!-- Method 1: for/id association (most common, most flexible) -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

<!-- Method 2: wrapping label (no id needed) -->
<label>
  Email address
  <input type="email" name="email">
</label>

<!-- Wrong: placeholder is NOT a label -->
<input type="email" name="email" placeholder="Email address">
<!-- placeholder disappears when the user starts typing — terrible UX for screen readers -->

Die for/id-Methode ist meist vorzuziehen, da Labels und Inputs im DOM entkoppelt bleiben, was das Styling erleichtert. placeholder niemals als Label-Ersatz verwenden — es versagt bei Nutzern mit kognitiven Einschränkungen und verschwindet, sobald jemand zu tippen beginnt. Das W3C-WAI-Label-Tutorial und die WebAIM-Anleitung zu Formular-Controls behandeln die Barrierefreiheitsbegründung ausführlich.

Eingebaute Constraint-Validierung

Die eingebaute Constraint-Validierung von HTML läuft vor dem Formular-Submit und ist wirklich leistungsfähig. Man bekommt viel nützliches Verhalten gratis:

html
<form>
  <!-- required: field must have a value -->
  <label for="fullname">Full name</label>
  <input type="text" id="fullname" name="fullname" required>

  <!-- minlength/maxlength: character count constraints -->
  <label for="username">Username (3–20 chars)</label>
  <input type="text" id="username" name="username"
         minlength="3" maxlength="20" required>

  <!-- pattern: regex-based validation -->
  <label for="postcode">UK Postcode</label>
  <input type="text" id="postcode" name="postcode"
         pattern="[A-Z]{1,2}[0-9][0-9A-Z]?s?[0-9][A-Z]{2}"
         title="Enter a valid UK postcode (e.g. SW1A 1AA)"
         required>

  <!-- min/max on date -->
  <label for="checkin">Check-in date</label>
  <input type="date" id="checkin" name="checkin"
         min="2026-04-16" required>

  <button type="submit">Submit</button>
</form>
  • required. Das Feld muss einen Wert haben. Bei Checkboxen muss es angehakt sein.
  • pattern. Ein Regex, dem der Wert entsprechen muss. Immer ein title-Attribut hinzufügen — es wird zum Validierungs-Tooltip-Text und gibt Nutzern einen Hinweis zum erwarteten Format.
  • minlength / maxlength. Zeichenanzahl für Text-Inputs. maxlength kürzt die Eingabe stillschweigend; minlength validiert nur beim Submit.
  • min / max. Numerische Grenzen oder Datumsgrenzen. Funktioniert bei number-, date-, range- und time-Inputs.
  • step. Definiert gültige Schrittweiten. step="0.01" bei einem Währungsfeld erlaubt Cent-Beträge. step="any" deaktiviert die Schrittprüfung vollständig.

fieldset und legend für Gruppierungen

Bei einer Gruppe zusammengehöriger Inputs — insbesondere Radio-Buttons oder Checkboxen — gruppieren <fieldset> und <legend> sie semantisch. Screen-Reader lesen die Legende vor jedem Input in der Gruppe vor, sodass Nutzer immer wissen, auf welche Frage ein Radio-Button antwortet.

html
<form>
  <fieldset>
    <legend>Preferred contact method</legend>

    <label>
      <input type="radio" name="contact" value="email" checked>
      Email
    </label>
    <label>
      <input type="radio" name="contact" value="phone">
      Phone
    </label>
    <label>
      <input type="radio" name="contact" value="post">
      Post
    </label>
  </fieldset>

  <fieldset>
    <legend>Notification preferences</legend>

    <label>
      <input type="checkbox" name="notify_new_posts" value="1">
      New articles
    </label>
    <label>
      <input type="checkbox" name="notify_replies" value="1">
      Replies to my comments
    </label>
  </fieldset>
</form>

Die Constraint Validation API

Die Constraint Validation API gibt JavaScript-Zugriff auf dieselbe Validierungslogik, die der Browser nativ verwendet. Das ermöglicht programmatisches Auslösen der Validierung und das Setzen benutzerdefinierter Fehlermeldungen, ohne den Submit zu blockieren:

js
const usernameInput = document.getElementById('username');

// Check if a single field is valid
console.log(usernameInput.checkValidity()); // true or false
console.log(usernameInput.validity.tooShort); // true if below minlength
console.log(usernameInput.validity.patternMismatch); // true if pattern fails

// Set a custom error message (shows in the browser's native validation tooltip)
usernameInput.setCustomValidity('That username is already taken.');
usernameInput.reportValidity(); // triggers the tooltip immediately

// Clear a custom error (important — once set, it sticks until cleared)
usernameInput.setCustomValidity('');

// Validate on the fly as the user types (async example — username availability)
usernameInput.addEventListener('input', async () => {
  const value = usernameInput.value;
  if (value.length < 3) return; // let minlength handle this

  const response = await fetch(`/api/check-username?q=${encodeURIComponent(value)}`);
  const { available } = await response.json();

  usernameInput.setCustomValidity(available ? '' : 'Username is already taken.');
});

Das kritische Detail: Sobald setCustomValidity() mit einem nicht-leeren String aufgerufen wird, ist das Feld dauerhaft ungültig, bis es durch Aufrufen von setCustomValidity('') geleert wird. Den Lösch-Schritt zu vergessen ist der häufigste Fehler bei der Verwendung dieser API.

novalidate für benutzerdefinierte JS-Validierung

Wenn eine benutzerdefinierte Validierungs-UI mit gestylten Fehlermeldungen (statt der nativen Browser-Tooltips) gebaut wird, novalidate zum Formular hinzufügen. Das deaktiviert die native Browser-Validierung, lässt aber die Constraint Validation API für eigene Prüfungen verfügbar:

html
<form id="signup-form" novalidate>
  <div class="field">
    <label for="signup-email">Email</label>
    <input type="email" id="signup-email" name="email" required>
    <span class="error" aria-live="polite"></span>
  </div>

  <div class="field">
    <label for="signup-password">Password</label>
    <input type="password" id="signup-password" name="password" minlength="8" required>
    <span class="error" aria-live="polite"></span>
  </div>

  <button type="submit">Create account</button>
</form>
js
const form = document.getElementById('signup-form');

form.addEventListener('submit', (e) => {
  e.preventDefault();

  let isValid = true;

  form.querySelectorAll('input').forEach((input) => {
    const errorEl = input.nextElementSibling;

    if (!input.checkValidity()) {
      isValid = false;
      errorEl.textContent = input.validationMessage;
      input.setAttribute('aria-invalid', 'true');
    } else {
      errorEl.textContent = '';
      input.removeAttribute('aria-invalid');
    }
  });

  if (isValid) {
    form.submit();
  }
});

autocomplete und aria-describedby

Zwei Attribute, die die Formular-UX erheblich verbessern und leicht übersehen werden:

html
<!-- autocomplete: tells browsers/password managers what the field is for -->
<input type="text"     name="fname"    autocomplete="given-name">
<input type="text"     name="lname"    autocomplete="family-name">
<input type="email"    name="email"    autocomplete="email">
<input type="tel"      name="phone"    autocomplete="tel">
<input type="password" name="password" autocomplete="current-password">
<input type="password" name="new_pass" autocomplete="new-password">
<input type="text"     name="cc"       autocomplete="cc-number">

<!-- aria-describedby: links an input to a hint or error message -->
<label for="pass">Password</label>
<input
  type="password"
  id="pass"
  name="password"
  minlength="8"
  aria-describedby="pass-hint"
  required
>
<span id="pass-hint">Must be at least 8 characters.</span>

Das autocomplete-Attribut verwendet standardisierte Token-Werte, die von der WHATWG-Spezifikation definiert werden. Mit dem richtigen Token können Browser und Passwortmanager Felder zuverlässig automatisch ausfüllen. aria-describedby verknüpft einen Hinweis oder eine Fehlermeldung mit einem Input — Screen-Reader lesen die Beschreibung nach dem Feld-Label vor, sodass Einschränkungen hörbar sind, bevor der Nutzer überhaupt zu tippen beginnt.

Ein vollständiges barrierefreies Login-Formular

Hier ist alles zusammengefasst — ein Login-Formular, das für Tastaturnutzer, Screen-Reader-Nutzer und Mobile-Nutzer funktioniert, nur mit HTML und einer kleinen Menge JavaScript:

html
<form id="login-form" novalidate>
  <h2>Sign in</h2>

  <div class="field">
    <label for="login-email">Email address</label>
    <input
      type="email"
      id="login-email"
      name="email"
      autocomplete="email"
      aria-describedby="email-error"
      required
    >
    <span id="email-error" class="error" aria-live="polite" role="alert"></span>
  </div>

  <div class="field">
    <label for="login-password">Password</label>
    <input
      type="password"
      id="login-password"
      name="password"
      autocomplete="current-password"
      aria-describedby="password-error"
      required
    >
    <span id="password-error" class="error" aria-live="polite" role="alert"></span>
    <a href="/forgot-password">Forgot password?</a>
  </div>

  <label class="inline">
    <input type="checkbox" name="remember" value="1">
    Keep me signed in for 30 days
  </label>

  <button type="submit">Sign in</button>
</form>

Wichtige Punkte: aria-live="polite" auf Fehler-Spans bedeutet, dass Screen-Reader Fehler ankündigen, wenn sie erscheinen, ohne das zu unterbrechen, was der Nutzer gerade hört. role="alert" verstärkt dies für ältere Screen-Reader. Die autocomplete-Werte entsprechen dem, was Passwortmanager erwarten, sodass das automatische Ausfüllen beim ersten Versuch korrekt funktioniert.

Hilfreiche Tools

Beim Erstellen und Testen von HTML-Formularen erkennt der HTML-Validator strukturelle Fehler wie fehlende Labels und doppelte IDs, bevor die Nutzer es tun. Für allgemeines HTML-Aufräumen hält der HTML-Formatierer den Markup lesbar. Die MDN-Referenz für das Input-Element ist die vollständigste Dokumentation für alle Input-Typen und ihre Attribute.

Fazit

HTML-Formulare haben weit mehr eingebaute Möglichkeiten, als die meisten Projekte nutzen. Den richtigen Input-Typ zu wählen liefert Mobile-Tastaturen, Validierung und semantische Bedeutung kostenlos. Korrekte Label-Zuordnung und aria-describedby machen Formulare ohne Maus navigierbar. Die Constraint Validation API bietet JavaScript-Hooks in die native Validierung, ohne mit dem Browser kämpfen zu müssen. Diese Teile zusammengesetzt ergeben Formulare, die für alle funktionieren — bevor eine einzige Zeile benutzerdefinierter Validierungslogik geschrieben wird.

← All HTML articles Browse all categories →