message channel · Feedback and notices
Progress Indicator
A visual indicator of task progress — a determinate bar for known percentage, an indeterminate spinner or ring, or a combination showing remaining time or steps.
Decisive boundary
Distinguish a determinate progress bar (known percentage) from an indeterminate spinner (unknown duration). Choose based on whether you can calculate the completion ratio.
Definition and intent
What is a Progress Indicator UI pattern?
Use the behavior, not the silhouette
A visual indicator of task progress — a determinate bar for known percentage, an indeterminate spinner or ring, or a combination showing remaining time or steps. The term is used here as a message channel whose timing, persistence, urgency, and actions must be specified. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Show users that a task is progressing and how much is left, or signal that work is happening if the duration is unknown. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Progress Indicator, the boundary is: Distinguish a determinate progress bar (known percentage) from an indeterminate spinner (unknown duration). Choose based on whether you can calculate the completion ratio.
Do not implement it as Skeleton loader for known layout shapes, and Toast for a completion message that disappears before the user can read it. If those requirements describe the real task better, use the related pattern page or the full Feedback and notices comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Show users that a task is progressing and how much is left, or signal that work is happening if the duration is unknown.
Define opening and closing
Appears when a task begins; hides when the task completes or fails. Resolved when the task completes or an error message appears.
Specify access behavior
Progress elements do not steal focus; indeterminate spinners should announce their state via a live region. No keyboard interaction; any related cancel or retry action is independently keyboard operable.
Reject the near miss
Skeleton loader for known layout shapes, and Toast for a completion message that disappears before the user can read it.
Behavior contract
What must survive the build
- trigger
- Appears when a task begins; hides when the task completes or fails.
- dismissal
- Resolved when the task completes or an error message appears.
- modality
- Non-modal inline feedback.
- focus
- Progress elements do not steal focus; indeterminate spinners should announce their state via a live region.
- keyboard
- No keyboard interaction; any related cancel or retry action is independently keyboard operable.
- interactive
- Usually informational; optionally includes a cancel button for user-initiated tasks.
- persistence
- Temporary — lasts only for the duration of the task.
- placement
- Inline near the task, or in a shared status region.
- mobile
- Avoid covering the entire viewport; use inline or compact indicators that do not block interaction.
Failure modes
Common wrong builds
- Leaving a progress bar at 99% indefinitely.
- Omitting an accessible label for the progress meaning.
- Animating the indicator when prefers-reduced-motion is set.
- Blocking interaction behind a full-viewport spinner when an inline indicator would do.
Observable checks
Verify the result
- Determinate bars always show the current value.
- Indeterminate spinners announce their loading state.
- The indicator disappears when the task completes.
- Animation respects prefers-reduced-motion.
- A cancel or escape path exists for user-initiated tasks.
Coding-agent handoff
Implementation brief template
Pattern: Progress Indicator Purpose: Show users that a task is progressing and how much is left, or signal that work is happening if the duration is unknown. Trigger: Appears when a task begins; hides when the task completes or fails. Dismissal behavior: Resolved when the task completes or an error message appears. Modality: Non-modal inline feedback. Focus behavior: Progress elements do not steal focus; indeterminate spinners should announce their state via a live region. Keyboard behavior: No keyboard interaction; any related cancel or retry action is independently keyboard operable. Interactive content: Usually informational; optionally includes a cancel button for user-initiated tasks. Placement: Inline near the task, or in a shared status region. Mobile behavior: Avoid covering the entire viewport; use inline or compact indicators that do not block interaction. Do not implement as: Skeleton loader for known layout shapes, and Toast for a completion message that disappears before the user can read it. Acceptance checks: - Determinate bars always show the current value. - Indeterminate spinners announce their loading state. - The indicator disappears when the task completes. - Animation respects prefers-reduced-motion. - A cancel or escape path exists for user-initiated tasks.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Progress Indicator UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Progress Indicator in web UI?
A visual indicator of task progress — a determinate bar for known percentage, an indeterminate spinner or ring, or a combination showing remaining time or steps. In this reference set it is a message channel whose timing, persistence, urgency, and actions must be specified.
When should I use a Progress Indicator?
Show users that a task is progressing and how much is left, or signal that work is happening if the duration is unknown. The decisive boundary to confirm is this: Distinguish a determinate progress bar (known percentage) from an indeterminate spinner (unknown duration). Choose based on whether you can calculate the completion ratio.
What keyboard and focus behavior does a Progress Indicator need?
No keyboard interaction; any related cancel or retry action is independently keyboard operable. Progress elements do not steal focus; indeterminate spinners should announce their state via a live region. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Progress Indicator behave on mobile?
Avoid covering the entire viewport; use inline or compact indicators that do not block interaction. Its modality is a separate requirement: Non-modal inline feedback.
How do I verify a Progress Indicator implementation?
Start with observable checks: Determinate bars always show the current value. Indeterminate spinners announce their loading state. The indicator disappears when the task completes. Then verify the remaining checks and compare the result with the linked source guidance.