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.