Empty states, errors, and accessibility get treated as the last 10% of the work — but for a real share of your users, they're the whole experience.
1These States Are Common, Not Rare
Every new user sees an empty state. Every user on a flaky connection eventually sees an error state. Designing these as a rushed afterthought means deprioritizing experiences that a real, substantial share of your total user sessions actually have.
2Accessibility Fixes Are Usually Just Better UX
A logical tab order, a clear focus indicator, and a descriptive error message help a keyboard-only user and a screen-reader user directly — and they also help a sighted mouse user who's in a hurry, distracted, or using the product one-handed on a phone. Treating accessibility as product quality tends to raise quality across the board.
3Step-by-Step Breakdown
'What happens when there's no data yet', 'what happens when the request fails', and 'can this be used without a mouse' aren't edge cases — for a meaningful share of real sessions, they're the actual experience. Designing them as an afterthought is designing for a minority of your real users.
A good empty state explains why there's nothing here and what to do next (not just a blank rectangle). A good error state explains what went wrong in plain language and gives a real next action (retry, contact support, go back) — not just 'Something went wrong.'
Why should empty and error states be designed with the same care as the 'happy path', not treated as afterthoughts?
- →They shouldn't — happy path design matters far more
- →For a meaningful share of real sessions, these ARE the experience the user has, not a rare exception
- →Because QA teams require it
- →Because they're easier to design than the happy path
Accessibility is the same category of mistake when treated as a compliance checkbox instead of product quality. Keyboard and screen-reader users aren't an edge case either — and a genuinely accessible flow is usually also clearer and more robust for everyone, not just assistive-technology users.
What's the risk of treating accessibility purely as a legal compliance checkbox rather than a product quality dimension?
- →There's no risk, compliance checklists are sufficient
- →It gets deprioritized like any 'someday, not urgent' checklist item, and teams miss that fixing it often improves clarity and robustness for all users, not just assistive-tech users
- →Compliance checklists always produce worse results than product thinking
- →It only affects a legal team, not engineers
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Write Error Messages a Screen Reader Announces Automatically
An error message that only appears visually (e.g. a red border with no text) communicates nothing to a screen-reader user. Pair every error state with an announced text message, ideally using `aria-live` so it's read out without requiring the user to hunt for it.
<div role="alert" aria-live="assertive">Email address is invalid.</div>SEO Implications
- 1
Target 'designing empty states and error states' and 'accessibility as product quality' as distinct, practical search intents
Readers researching this want concrete patterns for these specific states, not a general accessibility compliance overview.
Best Practices
Design All Four Core States Before Calling a Feature Done
Loading, empty, error, and populated — sketch or build all four before considering a feature complete. A feature that only handles the populated state is a demo, not a shippable product.
Frequent Bugs
Shipping a generic 'Something went wrong' error message with no specific cause or next action, for every possible failure.
Differentiate error messages by cause where feasible (network failure vs. validation failure vs. permission denied) and always include a concrete next action — retry, go back, or contact support — rather than a dead-end generic message.
Real-World Examples
The Blank Rectangle That Looked Broken
A new dashboard showed a blank white rectangle for users with no data yet, with no explanatory text. Support received repeated 'is the dashboard broken?' tickets from new users — the empty state was never designed, just left as the default of 'nothing rendered'.
// Before: renders nothing when data.length === 0
// After: <EmptyState message="No reports yet — create your first one" cta="Create report" />