Enter a valid email address.
\n```\n\n**In-place editing:**\n- When a field is edited inline (table cell, card title), show save/cancel controls adjacent to the field\n- On save: brief success indicator (\"✓ Saved\") that fades after 2s — do not navigate away\n- On error: inline error message below the field with a retry option\n- On cancel: restore the original value immediately\n\n---\n\n## Alert Banners\n\nBanners are persistent — they stay until the condition is resolved or the user dismisses them.\n\n**Use for:**\n- Service degradation (\"Some features are temporarily unavailable\")\n- Account issues requiring action (\"Your subscription expires in 3 days. [Renew]\")\n- Ongoing sync errors (\"Changes are not saving. [Retry]\")\n- Important announcements tied to the current page\n\n**Placement:** top of the affected section, not the entire page unless the issue is truly global.\n\n**Anatomy:**\n```\n[Icon] [Message — describes the issue and its scope] [Action] [×]\n```\n\n- One banner at a time per region — multiple simultaneous banners create alarm fatigue\n- Dismissible unless the condition is blocking\n- Colour follows status colour conventions: red (error), orange (warning), blue (info), green (success/resolved)\n\n---\n\n## Recovery Patterns\n\nEvery error state must have a path forward. Design the recovery action at the same time as the error message.\n\n### Retry\nFor transient failures (network, timeout, rate limit):\n\n```\n\"Could not load results.\"\n[Try again]\n```\n\n- Retry button triggers the same action\n- After 3 failed retries, escalate: \"Still having trouble? [Contact support]\"\n- Show a spinner during retry — do not let the user click multiple times\n\n### Undo\nFor destructive or irreversible actions (delete, archive, send):\n\n```\n\"Message sent. [Undo] ×\"\n```\n\n- Undo window: 5–10 seconds. Toast persists for this duration.\n- After the window closes, the action is final\n- Undo is preferable to confirmation dialogs for low-stakes actions — it is faster and less disruptive\n\n### Autosave and Draft Recovery\nFor long-form inputs (forms, documents, editors):\n\n- Autosave every 30–60 seconds silently\n- On save failure: \"Autosave failed — your changes are stored locally. [Retry save]\"\n- On return after crash or close: \"You have unsaved changes from [time]. [Restore] [Discard]\"\n\n### Graceful Degradation\nWhen a feature fails but the rest of the product still works:\n\n- Show an error state for the failed section only — do not blank the entire page\n- Offer a fallback: \"Could not load recommendations. [Browse all products →]\"\n- Log the error silently; surface only what the user needs to know\n\n---\n\n## Loading and Skeleton States\n\nLoading is not an error, but it is a state that needs design.\n\n- **Skeleton screens** for content-heavy pages — show the layout shape while data loads\n- **Spinners** for targeted async actions (button loading, inline refresh)\n- **Progress bars** for long operations with known duration (file upload, multi-step processing)\n- Never show a blank screen while loading — always show something\n\nSkeleton screens reduce perceived wait time compared to spinners. Match the skeleton shape to the actual content layout.\n\n---\n\n## Notification Accessibility\n\n- Errors use `role=\"alert\"` — announced immediately by screen readers\n- Status updates use `role=\"status\"` — announced politely (after current speech)\n- Toasts must be reachable by keyboard — do not use `pointer-events: none` on the close button\n- Auto-dismissing toasts must have sufficient duration (`prefers-reduced-motion` users may need more time to read)\n\n```html\n\n