Explore behaviors before defining the interface.
Quick guide for designers
When to use
Use when an operation requires waiting. Show determinate progress only when there is a real measure of advancement.
What to design
Show what is happening, the affected area, waiting, progress, success, failure, and recovery actions.
How it behaves
Updates keep focus predictable. Completion, failure, and cancellation end waiting with understandable feedback.
What to document in Figma
Define what progress measures, what remains available while waiting, and the effects of canceling or retrying.
How to review
Check messages and states in the design. In the implementation, verify updates, focus, announcements, and reduced motion preferences.
Waiting and measuring advancement
- Does the message identify the operation and affected area? An isolated indicator may not explain whether the page is loading or an action was received.
- Is progress determinate with a known total, or indeterminate? Do not display invented percentages or unsupported time estimates.
- Does the measure represent transfer, processing, or the whole task? Reaching 100% transfer does not prove processing has finished.
Availability and continuity
- Which actions remain available? How can duplicate submission be prevented without blocking unrelated controls?
- If a skeleton is used, does it anticipate content structure without presenting falsely actionable elements? Does waiting text remain available?
- What happens on leaving the page, canceling, or losing connection? Document whether the operation continues and how its result is recovered.
Completion and recovery
- Are success, failure, and cancellation distinguishable? Does failure end the animation and offer an appropriate next step, preserving data where possible?
- Do long text and controls remain visible on small screens? Does understanding depend on motion, color, or watching the animation continuously?
Interaction Methods
Mouse, touch, and keyboard
An informational indicator is followed by reading its message and progress without clicking it. Clicking or tapping Cancel or Retry executes that action when available.
Tab and Shift + Tab traverse available controls; Enter or Space on Cancel or Retry executes the action. Progress updates keep focus on the task; the static indicator does not create a focus stop.
Screen readers
Using screen reader reading commands identifies the operation and its value when determinate. With indeterminate progress, people identify waiting without receiving a fictitious percentage.
On operation start or completion, people perceive progress, completion, or failure feedback without moving focus to the bar. To recover from failure, they navigate to Retry and activate the button.
With a mobile screen reader, swiping traverses messages and controls in standard mode; double tapping activates Cancel or Retry when available.
Gherkin
BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).
Scenario: Given that I am on a page containing Loading and progress
Educational scenarios for reviewing behavior. Adapt them to context and execute them in the implementation; the presence of this text does not mean tests were performed.
Keyboard navigation
- WHEN an operation starts and I navigate with the keyboard while waiting
- I SEE operation identification and visible focus on available controls; the informational indicator does not create a focus stop
- THEN, when progress updates, I SEE that focus remains predictable and can activate Cancel or Retry when available
Screen reader on desktop
- WHEN I follow an operation with a desktop screen reader
- I HEAR or perceive which operation is running and its value for determinate progress, without a fictitious percentage during indeterminate waiting
- THEN, when the operation completes or fails, I HEAR or perceive the outcome without moving focus to the indicator or following every percentage change
Screen reader on mobile devices
- WHEN I navigate the operation region with a mobile screen reader
- I HEAR or perceive the waiting message and identify available controls by name
- THEN, when completion, failure, or cancellation occurs, I HEAR or perceive the outcome and can continue the task without watching the animation
Additional scenarios — editorial extension
Progress with an unknown total
- GIVEN an operation with no known total
- WHEN it starts
- THEN I perceive that waiting is in progress and do not receive a fictitious percentage.
Actual completion
- GIVEN transfer followed by processing
- WHEN transfer ends
- THEN the interface reports pending processing and only presents success when the task actually completes.
Failure and recovery
- GIVEN an ongoing operation
- WHEN a failure occurs
- THEN waiting ends, I identify the problem, and can activate available recovery with a keyboard, touch, or screen reader.
Focus during updates
- GIVEN an available control while waiting
- WHEN progress updates
- THEN focus is not moved by the update and the outcome message can be perceived without watching the animation.
Points to consider
Operation progress differs from a journey step indicator. Completed steps do not necessarily represent a percentage of remaining time.
Respect reduced motion preferences and preserve textual feedback when reducing animation. Avoid flashing effects.
Skeletons and spinners do not replace error, completion, or unavailability messages. Avoid waiting that never reaches an outcome.
Implementation notes and behavior decisions
An informational indicator does not need focus. Cancel and Retry, when available, follow button behavior and Tab.
Do not move focus on every update. If a focused control is removed at completion, direct focus to a coherent, documented destination.
A progress bar needs a name and a value when determinate. For indeterminate progress, do not expose a false numeric value. Prefer native progress when appropriate.
Communicate the start and outcome and, if needed, relevant milestones. A progressbar does not guarantee automatic announcement of every change; avoid forcing announcements for every percentage point.
If aria-busy is used on an updated region, reset it to false on completion or failure. Keep the status message perceivable, including while the region is busy.
References
Additional references for components of type Loading and progress.
Important:
Most references are on the course platform alongside the lessons cited in this material.
Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.
Technical references and examples consulted for this editorial adaptation. Each source retains its scope; consulting an example does not prove accessibility of another implementation.
Carbon — Progress bar (external link, opens in a new tab)
MDN — progress (external link, opens in a new tab)
W3C WAI — Status messages (external link, opens in a new tab)