Patterns: Forms

Prerequisites

• - A defined form schema and validation rules.
• - Component choice for each field type (input, select, switch, checkbox).
• - Error and success messaging strategy agreed with product and QA.

Step 1: Compose fields with semantic labels and help text

Use component labels and descriptions to reduce ambiguity before users submit.

<diwa-input-text
  label="Email"
  placeholder="name@company.com"
  description="Use a work email for account notifications."
></diwa-input-text>

<diwa-select label="Region" description="Used for timezone defaults."></diwa-select>

Step 2: Show inline validation where problems occur

Display error state on the field itself and keep summary text near the action area.

<diwa-input-password
  label="Password"
  state="error"
  message="Use at least 12 characters."
></diwa-input-password>

Step 3: Confirm submit outcomes with visible feedback

Use inline notifications for context-specific outcomes and toasts for global confirmations.

<diwa-inline-notification
  variant="success"
  heading="Profile updated"
  description="Your changes were saved."
></diwa-inline-notification>

Step 4: Validate keyboard and mobile flow

Ensure logical tab order, visible focus, and enough touch target spacing for dense and default layouts.

@media (pointer: coarse) {
  .form-actions > * + * {
    margin-top: var(--diwa-touch-target-spacing, 0.5rem);
  }
}

Implementation Notes

• - Keep dense mode as an explicit, documented variant for constrained layouts.
• - Avoid blocking users with only top-level error banners without field-level state.
• - Use accessibility tab guidance on each component page before shipping.

Troubleshooting

• - If users miss errors, place messages directly under the affected field.
• - If keyboard focus seems lost, verify custom focus overrides did not remove visible state.
• - If forms feel crowded on mobile, increase spacing and touch-target defaults.

Next Actions