thecatthatflies/form-design

Formulardesign

Ein Formular ist ein Gespräch, bei dem die Organisation etwas verlangt und die Person mit Zeit, Aufwand und Risiko zahlt. Es funktioniert, wenn jede Frage ihren Platz verdient, jede Antwort in den eigenen Worten der Person gegeben werden kann und jeder Fehler früh erkannt, an Ort und Stelle erklärt und ohne Datenverlust korrigierbar ist. Der häufigste Modellfehler ist ein Formular, das fertig aussieht und es nicht ist: Platzhalter-Labels, erfundene Pflichtfelder, type="number" für Kartennummern, kein autocomplete, Fehler nur als Browser-Bubbles oder rote Ränder, ein Absende-Button, der "Absenden" heißt, und ein Erfolgspfad, der der einzige getestete war.

Wenden Sie die Rangfolge der Prinzipien von interface-guidelines an (jeder kann es nutzen > es sagt die Wahrheit > es sagt, was es meint > die Antwort kommt zuerst > Fehler sind überlebbar > es bleibt an Ort und Stelle > das Mögliche ist sichtbar > Konvention > Politur). Wenn dieses Skill installiert ist, lesen Sie zuerst dessen SKILL.md. Abschnitt 3 der references/human-interface.md enthält die Basis-Formularregeln (sichtbare Labels, optionale Markierung, Einfügen, Validierungszeitpunkt, deaktivierter Submit, Speicherverhalten); dieses Skill geht weiter und wiederholt sie nicht.

Kurzfassung

Beantworten Sie diese Fragen, bevor Sie ein Feld zeichnen. Schreiben Sie sie auf, wenn das Formular mehr als fünf Fragen hat.

• Wofür wird jede Antwort verwendet? Benennen Sie die Entscheidung oder Aktion, die sie nutzt. Ein Feld ohne benannte Verwendung wird gestrichen.
• Wer antwortet, wie oft, auf welchem Gerät? Ein einmaliger Bewerber am Telefon oder ein Sachbearbeiter, der täglich 200 Datensätze am Schreibtisch eingibt. Das entscheidet über eine Seite pro Frage versus eine dichte Seite.
• Wessen Daten sind es? Die eigenen der Person (Autofill gilt, WCAG 1.3.5 gilt) oder die einer anderen Person (ein Empfänger, ein Patient, ein Kunde, der von Mitarbeitenden erfasst wird).
• Hat die Person die Antwort parat? Reisepassnummer, Policen-ID, letztjähriges Einkommen. Wenn nicht, sagen Sie vorab, was bereitgelegt werden soll, und erlauben Sie das Speichern.
• Was kostet eine falsche Antwort, und was ist nach dem Absenden unwiderruflich (Zahlung, rechtliche Erklärung, öffentlicher Beitrag)?
• Wo befinden sich die Befragten? Länder, Schriften, Adressformate, Telefonformate, Namensstrukturen.
• Was kann das System bereits wissen? Fragen Sie nie danach (WCAG 3.3.7).
• Agenten-Leser: Wird ein Agent dies für jemanden ausfüllen (Autofill-Erweiterungen, Browser-Agenten, Assistenten)? Gehen Sie bei allem Öffentlichen davon aus.

Regeln

Weniger fragen

• Streichen Sie Felder, bevor Sie sie entwerfen. Jedes Feld muss eine benannte Verwendung jetzt haben, nicht "könnte nützlich sein". Baymard stellt fest, dass der durchschnittliche Checkout 11,3 Felder hat, wo 8 ausreichen; die Feldanzahl schadet mehr als die Schrittzahl. [P: Baymard 2024]
• Erfassen Sie einen vollständigen Namen in einem Feld, es sei denn, die Teile steuern ein bestimmtes Verhalten (Sortierung, formelle Anrede). Viele Namen lassen sich nicht in Vorname und Nachname aufteilen. Fordern Sie niemals einen Nachnamen. [S: W3C i18n; P: Baymard]
• Verstecken Sie selten verwendete Felder hinter einem Link, nicht als Pflichteingabe: Adresszeile 2, Firma, Gutscheincode. [P: Baymard]
• Standardmäßig Rechnungsadresse an Lieferadresse anpassen mit einem aktivierten Kontrollkästchen, das die Rechnungsfelder ausblendet. [P: Baymard]
• Bieten Sie die Kontoerstellung nach der Transaktion an, nicht als Hürde davor. [P: Baymard]
• Erlauben Sie "Ich weiß nicht" wo dies eine gültige Antwort ist, anstatt eine Schätzung zu erzwingen. [S: GOV.UK Frageseiten]
• Leiten Sie ab, was Sie können: Stadt und Region aus Postleitzahl, wo zuverlässig, Kartentyp aus der Nummer, Land aus der Adresssuche. Halten Sie abgeleitete Werte sichtbar und bearbeitbar. [P: Baymard]

Struktur und Ablauf

• Wählen Sie die Form aus der Aufgabenstellung, nicht aus Gewohnheit. Seltene, stressige oder unbekannte Aufgaben: eine Frage pro Seite, mit der Frage als h1/legend. Häufige Experteneingabe: eine Seite, gruppiert, tastaturschnell. GOV.UK beginnt jeden Dienst mit einer Sache pro Seite und fasst nur zusammen, wenn die Forschung dies sagt. [S: GOV.UK Formularstruktur]
• Ordnen Sie die Fragen so, wie die Person darüber denkt, zuerst die einfachsten und sichersten, und verzweigen Sie, sodass niemand eine Frage sieht, die nicht zutreffen kann. [S: GOV.UK; J]
• Sagen Sie vor dem Start, was die Person braucht (Dokumente, Zeit, Kosten) und was danach passiert. [S: GOV.UK Startseiten]
• Lange, sitzungsübergreifende Formulare erhalten eine Aufgabenliste mit einfachen Statusangaben und Speichern-und-Zurückkehren. Verwenden Sie eine nur, wenn Leute nicht in einer Sitzung fertig werden oder ihre eigene Reihenfolge wählen müssen. [S: GOV.UK Aufgabenliste]
• Zurück funktioniert. Fügen Sie einen Zurück-Link auf Fragenseiten ein und unterbrechen Sie niemals die Zurück-Schaltfläche des Browsers; beim Zurückkehren werden vorherige Antworten vorausgefüllt angezeigt. [S: GOV.UK]
• Beenden Sie folgenreiche Abläufe mit einer Zusammenfassungsseite: jede Antwort mit einem Ändern-Link, dessen zugänglicher Name das Feld benennt ("Geburtsdatum ändern"), nach der Bearbeitung zurück zur Zusammenfassung. [S: GOV.UK Zusammenfassung prüfen; WCAG 3.3.4]
• Mehrspaltenlayouts unterbrechen die Lesereihenfolge für Menschen und Agenten. Eine Spalte, außer bei natürlich gepaarten kurzen Feldern (Ablaufmonat und -jahr, Stadt und Postleitzahl). [P: Baymard, Wroblewski; J]

Labels, Hinweise und Gruppierung

• Label oberhalb des Feldes. Der von Penzo 2006 berichtete Geschwindigkeitsvorteil stammt aus einem kleinen, informellen Eye-Tracking-Test und wurde von Das 2008 widerlegt; wählen Sie obere Labels, weil sie schmale Bildschirme, lange Übersetzungen und Zoom überleben, nicht weil sie nachweislich am schnellsten sind. [E, schwach: Penzo 2006, Das 2008]
• Hinweise stehen zwischen Label und Feld und sind mit aria-describedby verknüpft. Formatbeispiele ("Zum Beispiel 27 3 2007") gehören in den Hinweis, niemals in den Platzhalter. [S: GOV.UK]
• Gruppieren Sie verwandte Steuerelemente mit fieldset und legend: jede Radio-Gruppe, Checkbox-Gruppe und mehrteilige Antwort (Datum, Kartenablauf). Die Legende ist die Frage. [S: WCAG 1.3.1; GOV.UK]
• Auf einer Ein-Fragen-Seite ist das Label oder die Legende die Seitenüberschrift, damit Screenreader sie einmal hören. [S: GOV.UK Frageseiten]
• Markieren Sie optionale Felder mit "(optional)" und verwenden Sie keine Sternchen für Pflichtfelder. Wenn die meisten Felder optional sind, hinterfragen Sie, ob sie dazugehören. [S: GOV.UK]

Eingabetypen und Autofill

• Setzen Sie autocomplete auf jedes Feld, das die Person betrifft, mit dem genauen WHATWG-Token (given-name, email, postal-code, cc-number, one-time-code, new-password). Es ermöglicht Browser-Autofill, Passwortmanager und Agenten-Ausfüllen und ist eine WCAG 1.3.5-Anforderung. autocomplete="off" bei personenbezogenen Daten ist ein Fehler. [S: WHATWG Autofill; WCAG 1.3.5]
• Verwenden Sie type für die Bedeutung und inputmode für die Tastatur. type="email", type="tel", type="url" wo zutreffend. Kennungen, die aus Ziffern bestehen (Karte, Postleitzahl, Konto, Code) sind type="text" inputmode="numeric", niemals type="number", das führende Nullen entfernt, beim Scrollen ändert, lange Werte rundet und Diktiersoftware verwirrt. [S: GOV.UK 2020; MDN]
• Native Steuerelemente zuerst. select für eine geschlossene Liste mit etwa einem Dutzend Optionen, Radios für wenige Optionen, die Leute vergleichen sollen, eine Combobox mit Type-Ahead für lange Listen wie Länder. Benutzerdefinierte Dropdowns verbergen ihre Optionen vor Agenten. [S: APG; P: Sonde in interface-guidelines]
• Denkwürdige Daten sind drei Textfelder (Tag, Monat, Jahr) mit bday-*-Token für Geburtsdaten, die Monatsnamen akzeptieren. Datumsauswahlen eignen sich nur für Daten, die Personen relativ zu einem Kalender wählen. [S: GOV.UK Datumseingabe]
• Größe des Feldes an die erwartete Antwort anpassen. Ein Postleitzahlenfeld, das so breit ist wie ein Straßenfeld, deutet falsch hin. [S: GOV.UK; J]
• Antworten im Format der Person akzeptieren: Leerzeichen und Bindestriche in Karten- und Telefonnummern, Groß-/Kleinschreibung bei Postleitzahlen, Monatsnamen, führende oder nachgestellte Leerzeichen. Auf dem Server normalisieren. [S: GOV.UK]
• Feld-für-Feld-Muster (Namen, Adressen nach Land, Telefon, Geld, Karten, Dateien) finden Sie in references/fields.md.

Validierung und Fehler

• Standardmäßig beim Absenden validieren; inline erst, nachdem die Person ein Feld verlassen hat, das sie abgeschlossen hat, und einen Fehler sofort löschen, sobald er behoben ist. Nie beim ersten Tastendruck kennzeichnen. Belege widersprechen sich: Bargas-Avila 2007 fand, dass nach Abschluss aufgelistete Fehler sofortige Fehler übertrafen; Wroblewski 2009 fand, dass On-Blur-Inline-Validierung half (n=22). GOV.UK validiert beim Absenden; Baymard empfiehlt On-Blur und Entfernen von Fehlern bei Korrektur. Entscheiden Sie nach Formularlänge und wie gut das Feld allein prüfbar ist. [E: Bargas-Avila 2007; E, schwach: Wroblewski 2009; S: GOV.UK; P: Baymard]
• Bei fehlgeschlagenem Absenden: jede Antwort behalten, eine Fehlerzusammenfassung oben mit einem Link pro Problem zu seinem Feld einfügen, den Fokus auf die Zusammenfassung setzen, den Seitentitel mit "Fehler: " voranstellen und dieselbe Formulierung neben jedem Feld anzeigen. [S: GOV.UK Fehlerzusammenfassung; WCAG 3.3.1]
• Jede Nachricht mit ihrem Feld verknüpfen mit aria-describedby (fügen Sie aria-errormessage hinzu, wenn Sie möchten; die Screenreader-Unterstützung ist noch uneinheitlich) und aria-invalid="true" setzen. Die Nachricht muss sichtbarer Text sein: Agenten-Serialisierer lassen aria-invalid weg, behalten aber benachbarten Text. [S: WCAG 3.3.1; P: Roselli 2023; P: Sonde in interface-guidelines]
• Browser-Validierungsblasen ausschalten (novalidate) und Nachrichten in der Seite rendern. Blasen verschwinden, können nicht aus einer Zusammenfassung verlinkt werden und sind kein Seitentext. Die Server-Validierung bleibt maßgeblich. [S: GOV.UK Validierung]
• Fehler schreiben, die sagen, wie man sie behebt, spezifisch für die Ursache: "Geben Sie ein Geburtsdatum in der Vergangenheit ein", nicht "Ungültiges Datum". Eine Nachricht pro Ursache (leer, falsches Format, außerhalb des Bereichs), in den Worten des Formulars. [S: GOV.UK Fehlermeldung; WCAG 3.3.3]
• Ein Zustand, den die Person nicht durch Bearbeiten beheben kann (nicht berechtigt, Konto gesperrt, Dienst ausgefallen) ist eine Seite mit dem Grund und dem nächsten Schritt, kein Feld-Fehler. [S: GOV.UK]

Anmeldung, Passwörter, Passkeys

• Passwortmanager und Einfügen funktionieren lassen. autocomplete="username" und current-password oder new-password; Einfügen niemals blockieren; kein maxlength unter 64; Passwort anzeigen anbieten; das Bestätigungs-Passwortfeld entfernen, wenn Anzeigen angeboten wird. [S: NIST SP 800-63B-4 3.1.1.2; GOV.UK Passworteingabe; WCAG 3.3.8]
• Keine Zusammensetzungsregeln, kein regelmäßiger Ablauf, keine Hinweise. Neue Passwörter stattdessen mit bekannten kompromittierten Listen abgleichen und sagen, warum eines abgelehnt wurde. [S: NIST SP 800-63B-4]
• Passkeys anbieten, ohne eine Wahl im Voraus zu erzwingen: das Benutzernamensfeld behalten, autocomplete="username webauthn" und eine bedingte WebAuthn-Anfrage hinzufügen, dann Passkey-Erstellung nach einer Passwort-Anmeldung anbieten. [S: WHATWG Autofill; P: web.dev Passkey-Autofill]
• Einmalcodes: ein Feld, autocomplete="one-time-code", inputmode="numeric", Einfügen akzeptiert. Einzelne Ziffernfelder, die einen eingefügten Code ablehnen, verletzen WCAG 3.3.8. [S: WCAG 3.3.8]
• Nicht sagen, ob der Benutzername oder das Passwort falsch war. [S: GOV.UK Passwörter]
• Anmeldung nicht mit einem Rätsel-CAPTCHA blockieren. Text- und Logikrätsel verletzen WCAG 3.3.8 ohne eine nicht-kognitive Alternative. [S: WCAG 3.3.8]

Absenden

• Der Absende-Button benennt das Ergebnis: "Konto erstellen", "£42,00 bezahlen", "Bewerbung absenden". "Weiter" zwischen Schritten; "Speichern und weiter" nur, wenn gespeichert wurde. [S: GOV.UK Button; Grundlage]
• Rechtliche, finanzielle und datenlöschende Übermittlungen sind umkehrbar, geprüft oder bestätigt mit einem Prüfschritt (WCAG 3.3.4). Die Prüfung zeigt genau, was gesendet wird und was es kostet. [S: WCAG 3.3.4]
• Absenden ist idempotent: Wiedereingabe während der Übertragung deaktivieren, Fortschritt auf dem Button anzeigen und serverseitig mit einem Idempotenzschlüssel schützen. Ein erneuter Versuch nach einer Zeitüberschreitung darf nicht doppelt belasten. [S: GOV.UK Button; P: Stripe Idempotenz]
• Die Bestätigungsseite sagt, was passiert ist, eine Referenznummer und was als Nächstes passiert, und überlebt ein Neuladen. Ein Toast ist keine Quittung. [S: GOV.UK Bestätigungsseiten; Grundlage]

Für den Agenten-Leser

• Jedes Steuerelement hat einen programmatischen Namen, der mit seinem sichtbaren Label übereinstimmt, und seine Auswahlmöglichkeiten sind aufzählbar (natives select, sichtbare Radios). [J]
• Einschränkungen sind vor dem Absenden sichtbarer Text (Format, Länge, erlaubte Werte), nicht nur in einem pattern-Attribut. [J]
• Fehler sind Text neben dem Feld und in einer Zusammenfassung, stabil bis zur Behebung. [J]
• Die URL oder Überschrift jedes Schritts sagt, wo im Ablauf der Agent ist; Zurück- und Ändern-Pfade existieren. [J]
• Von außen geschriebener Text (vorausgefüllt aus einer E-Mail, einer Überweisungsnotiz) wird als zitierte Daten angezeigt, niemals als Label oder Anweisung. [J]
• Folgenreiche Übermittlungen behalten die Autorität auf dem Server: eine Zusammenfassungsseite hilft Menschen; sie stoppt keinen Agenten, der durchklickt. [J]

Erstellungsreihenfolge

1. Listen Sie die Fragen mit der Verwendung jeder Antwort auf; löschen Sie die ohne eine.
2. Wählen Sie die Form: eine Seite, eine Sache pro Seite oder Aufgabenliste. Skizzieren Sie Verzweigungen.
3. Schreiben Sie den Text: Fragen, Hinweise, jede Fehlermeldung pro Ursache, Button-Labels, Bestätigung.
4. Bauen Sie mit nativen Elementen: label for, fieldset/legend, korrektes type, inputmode, autocomplete, novalidate.
5. Server-Validierung und idempotentes Absenden, dann Client-Validierung mit denselben Meldungen.
6. Fehlerzustand: Zusammenfassung, Fokus, Titelpräfix, Inline-Nachrichten, erhaltene Eingabe.
7. Zusammenfassungs- und Bestätigungsseiten; speichern und zurückkehren bei mehreren Sitzungen.
8. Styling zuletzt; die Marke bestimmt das Aussehen (brand-identity).

Überprüfen

• node <form-design>/scripts/form-check.mjs <url|file|dist> --try-submit gegen einen lokalen oder Test-Build. Es prüft Namen und sichtbare Labels, Gültigkeit und Zweck von Autocomplete, Eingabetypen, Einfügen, versteckte native Radios, Gruppenlegenden, Fehlerverdrahtung, Fokus nach fehlgeschlagenem Absenden und Absende-Formulierung. Fehler beenden mit Exit-Code 1. --try-submit sendet wirklich ab: niemals auf die Produktion richten.
• node <interface-guidelines>/scripts/audit.mjs <url|dist> für das allgemeine gerenderte Audit (Kontrast, Ziele, Tastatur, Umbruch, Agentenstabilität).
• Mit einem Passwortmanager und Browser-Autofill ausfüllen mit einem echten Profil: jedes persönliche Feld wird ausgefüllt und nichts landet im falschen Feld.
• Nur mit der Tastatur ausfüllen und bei 320 px mit 200 % Text.
• Als Agent ausfüllen allein aus dem Barrierefreiheits-Snapshot: jedes Feld beim Namen finden, jede Auswahl lesen, falsch absenden, Fehler lesen, beheben, fertigstellen.
• Schlechte Daten: ein einwortiger Name, ein 60-Zeichen-Name mit Apostroph und Akzenten, eine Adresse in Japan und eine in Irland ohne Postleitzahl, eine eingefügte Kartennummer mit Leerzeichen, ein Doppelklick auf Absenden, eine Sitzungszeitüberschreitung mitten im Ablauf.

Fallen

• Platzhalter als Label oder ein schwebendes Label, das in den Rand schrumpft und den Kontrast verfehlt.
• type="number" für Karte, Telefon, Postleitzahl oder Codes.
• autocomplete="off"

… [für Übersetzung gekürzt]