Design loading motion that does not pretend progress

Loading feedback should describe what the system knows. Use a progress bar only when you have meaningful progress to report. Use a status or skeleton when the duration is unknown, and make failure and completion visible without depending on continuous animation.

Match the indicator to the information

A bar that slowly approaches 99% without a real measure can make the wait harder to interpret. A skeleton should resemble the layout, not impersonate loaded content.

Start with a static skeleton

<section aria-busy="true" aria-label="Search results">
  <p role="status">Loading results…</p>
  <div class="skeleton" aria-hidden="true"></div>
</section>

.skeleton {
  min-height: 8rem;
  background: #e4e0d7;
  border-radius: .5rem;
}

Static placeholders avoid unnecessary motion. If you add a shimmer, disable it for reduced motion and check whether it distracts from surrounding content. Do not put placeholder text into the accessibility tree as though it were a result.

Keep the state honest

Set aria-busy to false when the update is complete. Replace the loading status with an appropriate result or error. Do not announce rapidly changing percentages unless the information is useful and the cadence is suitable for assistive technology.

Test the slow and failed paths

Throttle the request, force an error, and trigger a second request before the first finishes. Make sure stale results do not replace newer results and that the indicator belongs to the active operation. A polished loading effect can conceal a race condition if you only test the successful fast path.

Ask AI to review the operation’s states before styling the indicator. The useful output is a complete loading, success, empty, and error flow. Motion is an optional treatment within that flow, not the definition of progress.