Error State Patterns
Best practices for displaying errors in Fidus. Choose the right error display method based on severity, context, and user action required.
When to Use Each Error Type
| Component | Severity | Use Case | Example |
|---|---|---|---|
| Toast | Low | Transient errors that auto-dismiss | Network timeout, save failed |
| Alert (Inline) | Medium | Contextual errors within a section | Form validation, missing data |
| Banner | High | Page-level errors requiring attention | Session expired, payment failed |
| Modal | Critical | Blocking errors requiring immediate action | Data loss, security alert |
Inline Errors (Alert Component)
Use inline alerts for contextual errors that relate to a specific section or form. These errors stay visible until the issue is resolved.
Form Validation Error
Please correct the following errors:
- Email address is required
- Password must be at least 8 characters
- You must agree to the terms and conditions
Missing Data Error
Unable to load budget data
Permission Error
Access denied
Page-Level Errors (Banner Component)
Use banners for important errors that affect the entire page or require immediate attention. Banners should be dismissible unless the error is critical.
Session Expired
Payment Failed
System Error
Modal Error Dialogs
Use modal dialogs for critical errors that block the user from continuing until they acknowledge or resolve the issue.
Critical Error (Data Loss Warning)
Validation Error Modal
Toast Notifications for Transient Errors
Use toast notifications for low-severity errors that auto-dismiss. These should not block the user and typically indicate recoverable issues.
Save Failed
Network Error
Usage Guidelines
When to use
- •When a user action fails or cannot be completed
- •When data cannot be loaded or is unavailable
- •When validation rules are not met
- •When network or system errors occur
- •When user permissions prevent an action
Best practices
- •Explain what went wrong in plain language, avoiding technical jargon
- •Provide clear next steps or recovery options
- •Match error severity to the appropriate component (Toast, Alert, Banner, Modal)
- •Preserve user input when errors occur to avoid data loss
- •Show errors near the context where they occurred
- •Include error codes for technical support when appropriate
- •Distinguish between error states and empty states clearly
Accessibility
- •Error messages announced with aria-live="assertive" for critical errors
- •Error dialogs trap focus until dismissed
- •Error messages linked to form fields with aria-describedby
- •Error icons have appropriate ARIA labels
- •Keyboard users can dismiss errors with Escape key
- •Error colors meet WCAG AA contrast requirements
- •Error information is not conveyed by color alone
Do's and Don'ts
✓ Do
- •Explain what went wrong: "Unable to save budget. The amount exceeds your spending limit."
- •Provide actionable next steps: "Please reduce the amount or increase your limit."
- •Use appropriate severity levels based on impact
- •Preserve user input to prevent data loss
- •Include error codes for support: "Error PAY_001"
Unable to save budget
✗ Don't
- •Use technical jargon: "NullPointerException in BudgetService"
- •Blame the user: "You entered an invalid value"
- •Show multiple error dialogs simultaneously
- •Use generic messages: "Error occurred", "Something went wrong"
- •Auto-dismiss critical errors without acknowledgment
Error
Related Components
Alert
Inline contextual error messages
Banner
Page-level error notifications
Modal
Critical error dialogs
Toast
Transient error notifications
Empty States
When no errors occurred, just no data
Form Validation
Form-specific error handling