Use determinate progress when completed work and the total are known. Otherwise use a short loading message, optionally with a spinner or indeterminate bar.
Problem
The interface is waiting for an operation.
Choose a loading indicator
- Progress bar: completed work and the total are known, such as bytes transferred during an upload.
- Skeleton: the structure of the incoming content is predictable.
- Loading message, optionally with a spinner: work is pending but its progress cannot be measured.
Loading indicator mistakes to avoid
- A fake percentage or a skeleton that suggests content you cannot predict.
- Replacing the entire screen when only one region is updating.
Example
Example file upload
This is a simulation. No files are uploaded.
Ready to start.
Implementation
- Acknowledge the action and prevent duplicate requests. Keep existing content and unrelated controls usable when possible.
- Prefer a labeled <progress> element. Set value and max for measured progress; omit value when progress is unknown. Use <meter> for measurements such as storage usage, not task completion.
- For WCAG AA, displayed loading and completion status messages must be available to assistive technology without taking focus. A role=status region present before updates is one approach. Announce useful milestones rather than every percentage change.
- When a page region is loading, mark that region aria-busy=true and clear it when updates finish, including after failure. Keep live status messages outside the busy region, where announcements will not be deferred by that state.
- Handle failure, timeout, and retry; offer cancellation when the operation supports it. Distinguish transfer progress from later processing before reporting success.
- Use skeletons only for predictable structure. Respect reduced motion and keep a readable loading message when decorative animation is removed.
Tradeoffs
Skeletons preview structure; spinners and indeterminate bars indicate waiting without estimating completion. Indicator choice and timing are design decisions to test with users, not universal accessibility thresholds.
Verification
Can users identify pending, completed, and failed states with a keyboard and screen reader? Can they recover when the operation takes too long or never finishes?