Formulare für Profis

Formulare sind die Stelle, an der aus Besuchern Kunden werden – oder eben nicht. Jede Anmeldung, jede Bestellung, jede Kontaktaufnahme läuft durch ein Formular, und jedes unnötige Feld, jede kryptische Fehlermeldung kostet messbar Absprünge. Die Grundlagen sitzen bei dir längst; in dieser Lektion holst du heraus, was HTML von Haus aus kann: Validierung ohne eine Zeile JavaScript, passende Tastaturen auf dem Smartphone und Fehlermeldungen, die niemanden ausschließen.

Bevor du für die Formularprüfung eine JavaScript-Bibliothek einbindest: Der Browser bringt eine komplette Validierung mit. Sie springt beim Absenden an, blockiert das Formular bei Fehlern, zeigt eine Meldung in der Sprache des Nutzers an und setzt den Fokus in das erste fehlerhafte Feld – Komfort und Barrierefreiheit inklusive, ganz ohne Code. Gesteuert wird sie über Attribute:

Probiere die eingebaute Validierung direkt aus: Klicke in der Vorschau auf „Reservieren“, ohne etwas auszufüllen – der Browser meldet sich in deiner Systemsprache, ganz ohne JavaScript. Fülle die Felder dann Schritt für Schritt aus und beobachte, wie sich die Meldungen ändern (die Gästezahl steht absichtlich auf einem ungültigen Wert).

Wenn die eingebauten Typen nicht reichen, übernimmt pattern: Das Attribut enthält einen regulären Ausdruck – eine Mustersprache, die dir spätestens beim Programmieren wiederbegegnen wird –, und die Eingabe muss ihm vollständig entsprechen. Für eine deutsche Postleitzahl heißt das Muster [0-9]{5}: „genau fünf Zeichen aus dem Bereich 0 bis 9“.

Zwei Begleiter machen pattern erst rund. Erstens das title-Attribut: Sein Text wird in die Fehlermeldung des Browsers übernommen – ohne ihn erfährt der Nutzer nur, dass das Format nicht stimmt, aber nicht, was erwartet wird. Formuliere dort also immer die Anforderung in Menschensprache. Zweitens die Ausnahme: Mit novalidate am <form>-Element schaltest du die gesamte Browser-Validierung ab – sinnvoll, wenn du eine eigene Fehlerdarstellung per JavaScript baust oder deine Server-Validierung testen willst.

Die beiden letzten Attribute im Beispiel – inputmode und autocomplete – sind kein Zufall: Sie sind der Stoff der übernächsten Station dieser Lektion.

Ein <select> zwingt zur Wahl aus einer festen Liste. Oft willst du aber beides: Vorschläge und Freiheit. Genau dafür gibt es <datalist> – eine Vorschlagsliste, die sich über das list-Attribut mit einem normalen Eingabefeld verbindet. Beim Tippen bekommt der Nutzer passende Vorschläge angeboten, darf aber jederzeit etwas ganz anderes eintragen.

Die Abgrenzung als Faustregel: select, wenn nur definierte Werte gültig sind (Zahlungsart, Land); datalist, wenn du häufige Eingaben beschleunigen, aber keine Möglichkeit ausschließen willst (Stadt, Beruf, Lieblingsbrotsorte).

Gehören mehrere Felder inhaltlich zusammen – Lieferadresse, Rechnungsadresse, Zahlungsart –, fasst du sie mit <fieldset> zusammen und gibst der Gruppe mit <legend> einen Namen. Der Browser rendert einen Rahmen (den CSS jederzeit umgestalten kann); entscheidend ist aber, was im Hintergrund passiert: Screenreader sagen die legend an, wenn Nutzer die Gruppe betreten, und stellen so den Zusammenhang her.

Bei Radio-Gruppen ist das Duo Pflicht, nicht Kür. Denn jeder Radio-Button trägt nur sein eigenes Label – „Ja“, „Nein“, „Vielleicht“. Sehende erfassen die zugehörige Frage über die Optik; wer sich per Screenreader von Feld zu Feld bewegt, hört beim einzelnen Knopf aber nur „Ja, Auswahlknopf“. Worauf sich das Ja bezieht, liefert erst die legend. Praktischer Nebeneffekt: Ein disabled am fieldset deaktiviert alle enthaltenen Felder auf einen Schlag.

Auf dem Smartphone entscheidet die eingeblendete Tastatur über Tempo und Tippfehler. Drei Attribute geben dir die Kontrolle, ohne die Validierung anzufassen:

• autocomplete sagt dem Browser, was in ein Feld gehört, damit er es automatisch ausfüllen kann. Die wichtigsten Werte: name, email, postal-code, street-address – und der Geheimtipp one-time-code: Damit schlägt das Smartphone den gerade per SMS erhaltenen Bestätigungscode direkt über der Tastatur vor.
• inputmode wählt die Bildschirmtastatur: numeric für Ziffernblöcke, decimal für Kommazahlen, email blendet das @-Zeichen ein. Wichtig: Es ändert nur die Tastatur, nicht die Validierung.
• enterkeyhint beschriftet die Enter-Taste passend zur Aktion: search, send, next oder done – eine kleine Geste mit spürbar besserer Führung.

Und autocomplete="off"? Nur mit sehr gutem Grund. Autofill auszuschalten trifft genau die Menschen am härtesten, die auf Unterstützung angewiesen sind – Nutzer mit motorischen oder kognitiven Einschränkungen. Die Barrierefreiheits-Richtlinien fordern maschinenlesbare Feldzwecke sogar ausdrücklich, und bei Login-Feldern ignorieren Browser das Abschalten ohnehin bewusst. Wer Autofill sabotiert, senkt seine Abschlussrate und schließt Menschen aus – ein doppelt schlechtes Geschäft.

Das unscheinbare <output>-Element markiert das Ergebnis einer Berechnung im Formular – etwa eine Preissumme, die auf Eingaben reagiert. Es sieht aus wie normaler Text, hat aber zwei eingebaute Vorteile: Über das for-Attribut dokumentiert es, aus welchen Feldern das Ergebnis entsteht, und Screenreader behandeln es als Live-Region – Änderungen werden automatisch angesagt, ohne dass du aria-live setzen musst.

Damit im nächsten Beispiel etwas passiert, steckt im oninput-Attribut des Formulars eine einzige Zeile JavaScript – betrachte sie als kleinen Vorgeschmack auf spätere Kurse. Ziehe am Regler und beobachte, wie die Summe live mitrechnet; die Stadt-Eingabe zeigt dir nebenbei die datalist aus dem vorigen Abschnitt in Aktion.

Spätestens wenn du eigene Fehlermeldungen gestaltest (oder sie vom Server zurückkommen), stellt sich die Frage: Wie erfährt ein Screenreader-Nutzer, was an seinem Feld falsch ist? Die rote Umrandung sieht er nicht. Die Lösung ist ein Dreiklang: Die Fehlermeldung steht als sichtbarer Text beim Feld, das Feld verweist per aria-describedby auf die id dieser Meldung, und aria-invalid="true" markiert den Fehlerzustand. Beim Fokussieren hört der Nutzer dann alles Nötige in einem Zug: „E-Mail-Adresse, ungültige Eingabe, Bitte gib eine vollständige Adresse mit @-Zeichen ein.“

Zum Schluss zwei UX-Grundsätze, die mehr bewirken als jedes technische Attribut. Erstens: So wenige Felder wie irgend möglich. Jedes zusätzliche Feld kostet nachweislich Absprünge – frage dich bei jedem einzelnen, ob du die Information jetzt wirklich brauchst. Zweitens: Labels bleiben immer sichtbar. Ein Platzhaltertext ist kein Ersatz für ein <label>: Er verschwindet beim Tippen (spätestens beim Kontrollieren der Eingaben fehlt dann jede Orientierung), sein Kontrast ist meist zu schwach, und assistive Technologien behandeln ihn uneinheitlich. Der Platzhalter darf ergänzen – etwa ein Formatbeispiel zeigen –, niemals ersetzen.

Damit beherrschst du das anspruchsvollste Eingabe-Werkzeug des Webs. In der nächsten Lektion wird es visuell: „Responsive Bilder, Video & Audio“ zeigt dir, wie du Medien lieferst, die auf jedem Display scharf aussehen – ohne unnötige Megabytes zu verschwenden.