form-validation

# Form Validation Validation combines **correctness** and **UX**: when errors appear, how they are announced, and how client rules match the server. ## When to Offer This Workflow **Trigger conditions:** - Long forms, wizards, or multi-step checkouts - Accessibility audits flagging unclear errors - Mismatch between client-side “valid” and API rejection **Initial offer:** Use **six stages**: (1) model & schema, (2) rule layers, (3) UX timing, (4) accessibility, (5) async & server parity, (6) testing). Confirm framework (React Hook Form, Formik, native, etc.). --- ## Stage 1: Model & Schema **Goal:** Single schema (Zod, Yup, JSON Schema) as source of truth; share with backend when feasible. --- ## Stage 2: Rule Layers **Goal:** Separate required/format rules from cross-field rules (e.g., date range); isolate async checks (username available) from fast inline validation. --- ## Stage 3: UX Timing **Goal:** Choose onBlur vs onSubmit per field; avoid shouting on every keystroke unless real-time feedback is a product requirement. --- ## Stage 4: Accessibility **Goal:** Associate errors with fields via `aria-describedby`; move focus to first error on submit; use live regions judiciously. --- ## Stage 5: Async & Server Parity **Goal:** Map API validation errors to fields; handle race conditions on slow networks; idempotent submit with dedupe if needed. --- ## Stage 6: Testing **Goal:** Unit-test schema; e2e critical paths including server error mapping. --- ## Final Review Checklist - [ ] Schema aligned or shared with server - [ ] Validation timing and copy defined - [ ] Accessible error patterns - [ ] API errors mapped to UI - [ ] Tests for schema and flows ## Tips for Effective Guidance - Server rules always win—document intentional client shortcuts. - Pair with **ux-writing** for error microcopy. ## Handling Deviations - Wizards: validate per step and on final submit; persist drafts securely.