VOCABULARY / ENTRY
Indeterminate Progress Indicator
indeterminate-progress
When remaining time or completed fraction cannot be known, a continuously spinning icon or looping bar shows that the system is still working, without reporting how much has actually been done.
Recognizing it
- A spinning icon or a looping bar plays continuously, showing no number or percentage
- It only conveys that work is in progress; the animation itself does not correspond to any calculable completed amount
- It is replaced immediately by the result, content, or an error once processing ends, rather than lingering
Concept boundary
An indeterminate progress indicator only answers whether the system is still working, not how much is done or how long is left; once a reliable completed amount and total are available, switch to a determinate progress bar instead — the two are not interchangeable, and a spinner must not be used to hide progress that could in fact be quantified. A skeleton screen is for when the content structure is known and only that structure is waiting to be filled; an indeterminate indicator is for when the completion fraction itself is unknown, or the wait covers the whole interface rather than a known structure.
When to consider it
- The system cannot obtain a reliable completed amount or total
- The wait is expected to exceed about 1 second, and users need to see that the system is still responding rather than stuck
- The wait may exceed about 10 seconds, so text guidance or a way to cancel is needed alongside the animation to keep users oriented
When to be cautious
- A real completed amount and total are already available, yet a vaguer spinner is used instead of switching to a determinate progress bar
- An animation that fills at a steady or accelerating pace is used to fake real progress, leading users to believe they are seeing a percentage
- The content structure is already known and only waiting to be filled in (use a skeleton screen instead)
Tradeoff
A spinner or looping animation is simple to implement and avoids any false sense of precision, but once a wait passes about 10 seconds users lose patience and orientation; it still needs text guidance or a cancel option and cannot carry the waiting experience on animation alone.
Conditional rules · Editorial advice
Related entries
When a reliable completed amount and total exist, switch to a determinate progress bar; an indeterminate indicator must not stand in for it to imply precise progress, so the two are chosen based on measurability.
Use a skeleton screen when the content structure is known and only waiting to be filled; use an indeterminate indicator when the content structure is unknown or the wait covers the whole interface.
An indeterminate indicator only shows that the process is ongoing; the result, error, or next step once it ends is left to a status message to report.
Sources and what they support
This article recommends reserving looping indeterminate indicators for waits of roughly 2 to 10 seconds, and switching to a determinate indicator that shows completion percentage once a wait exceeds 10 seconds.
Retrieved: 2026-09-15 · Archived 2026-09-16This article sets out three response-time limits of 0.1, 1, and 10 seconds: within about 1 second a user's train of thought stays uninterrupted, and beyond about 10 seconds users struggle to keep their attention on the task, so progress feedback and a way to interrupt the process become necessary.
Retrieved: 2026-09-15 · Archived 2026-09-16MDN explains that omitting the value attribute makes a progress element indeterminate, indicating that an activity is ongoing with no indication of how long it is expected to take.
Retrieved: 2026-09-15 · Archived 2026-09-16This criterion requires that moving content which starts automatically, runs alongside other content, and lasts more than 5 seconds provide a way to pause, stop, or hide it; the page uses a "loading" animation shown during a download as an example, noting that if the animation is not presented in parallel with other interactive content it can be treated as essential motion and does not need such a control.
Retrieved: 2026-09-15 · Archived 2026-09-16Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
This entry has no operable specimen yet; the illustration is an editorial sketch. When applied to a product, still verify: whether the looping animation downgrades to a static but recognizable state under reduced motion, whether a text or semantic status independent of the animation can be announced by screen readers, and whether waits beyond about 10 seconds are supplemented with guidance or a cancel option to keep users oriented.
{
"states": [
"idle",
"indeterminate",
"success",
"error"
],
"a11y": [
"The container is marked busy and provides a text status independent of the animation, so information does not depend on the visual animation alone",
"Avoid having screen readers interrupted repeatedly and meaninglessly by the animation itself"
],
"motion": "Loops a spinning or scrolling animation by default; switches to a static but still recognizable processing style when reduced motion is enabled"
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.