form-uxlisted

# Form UX A form is a completion path: reduce effort, prevent predictable errors, and make every failure truthful, repairable, and accessible. ## Model the task before styling fields Start with outcome, risk, and data authority—not an inherited input array. Remove, defer, or explain each field through this contract: | Field contract | What to decide | | --- | --- | | User value | What completing this field unlocks now, in the user's words | | Data rule | Required/optional condition, source of truth, and whether the rule is client- or server-owned | | Input affordance | Label, type, inputmode, autocomplete, format help, and a safe example | | Validation moment | What can be checked while editing, on blur, on submit, or only after a server request | | Recovery | Exact message, preserved value, focus destination, and next available action | | Sensitivity | Whether the field is personal, financial, irreversible, or must never be persisted locally | Unknown rule/ownership stays unresolved; never invent validation. Group by the user’s task, not database/API shape. ## Non-negotiables - Persistent associated label; visible required/optional state; correct type, inputmode, autocomplete, and a one-column task flow (short related pairs excepted). - Validate on submit. Validate on blur only when the value is complete enough to judge; after an error, re-check while the person repairs it. Keep server truth server-owned. - Put specific, adjacent “what + fix” errors behind `aria-i