← ClaudeAtlas

form-uxlisted

Form UX and accessibility pass. Use for forms, inputs, checkout, signup/login, validation, labels, autocomplete, mobile keyboards, inline errors, required fields, disabled submits, and field-level accessibility.
KyaniteLabs/tastecheck · ★ 8 · Web & Frontend · score 71
Install: claude install-skill KyaniteLabs/tastecheck
# Form UX A form is a completion path: reduce effort, prevent predictable errors, and make failure truthful, repairable, and accessible. ## Model task before styling 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 task, not database/API shape. ## Non-negotiables - Persistent associated label; visible required/optional state; correct type, inputmode, autocomplete, and 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-invalid`/`aria-describedby`; an