error-handling-recovery

Error messages should be specific, actionable, and accessible. Include what went wrong, why it happened, and the exact step to recover—for example, "Email format invalid. Use [email protected]" instead of "Error 400." Pair each message with a recovery action like a retry button or inline correction field.

Use inline recovery for validation errors: display the error message next to the field, highlight the input, and enable immediate correction. For complex validation failures, pair inline feedback with progressive recovery options—suggest corrections, show password strength, or offer alternative sign-up methods.

Network errors benefit from modal or persistent recovery workflows. Display the error state, explain the failure, provide a retry action, and offer fallback options like offline mode or data sync. Assign error IDs for debugging and include accessible messaging for screen readers.

Yes. Robust error handling prevents drop-offs by catching permission issues, payment failures, and sync problems early. Design recovery workflows that preserve user input, explain blockers clearly, and provide immediate resolution paths—reducing friction at high-value conversion points.

Error messages must be screen-reader friendly, use semantic HTML, avoid color-only indicators, and include ARIA labels. Ensure recovery actions are keyboard-navigable and error IDs are announced alongside user-facing text for assistive technology users.

Core principles—specific messaging, actionable recovery, accessibility—apply to both. Mobile requires more compact messaging and touch-friendly recovery buttons; web may use modals or inline fields. Adapt layout and interaction patterns while maintaining consistent error messaging anatomy.