Practical framework / 5 MIN READ
Explain progress while a task is running
Describe the real processing state and what the reader can safely do while waiting, without inventing precision.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A progress message should reduce uncertainty about a running task. It must distinguish work that is queued, active, completed or unconfirmed rather than using a cheerful spinner for every condition.
What you will leave with: Leave with a state-transition message map and a verified rule for leaving, canceling or checking the task.
Use this when
- A report export or media-processing task takes noticeable time.
- Readers repeat actions because the interface appears frozen.
- A progress bar reaches completion before the output is available.
This covers non-transactional application processing, not payment, order or delivery status, and it does not justify fabricated time estimates.
Describe the states the system can observe
Ask the technical owner to identify the real task lifecycle: accepted, queued, processing, ready, failed or another meaningful state. Record what evidence moves the interface from one state to the next. A request accepted by a server does not necessarily mean processing has started. Avoid exposing internal jargon that does not help the reader, but preserve distinctions that affect their next action. Define what the system should say when it loses contact and cannot confirm progress. Unknown is a legitimate state; it should not be silently converted into failure or success.
Use progress measures only when they mean something
If a percentage is shown, define its denominator and relationship to completed work. Counting uploaded bytes may describe transfer progress without describing later processing. If timing varies and no reliable estimate exists, use a truthful state description rather than a precise countdown. Explain whether the reader can leave the page, continue working or receive a result later, and verify those claims with the actual product behavior. A reassuring instruction to close the window is harmful if doing so cancels the task. Keep any cancellation consequence clear before the reader acts.
Make updates available without constant interruption
W3C's status-message guidance addresses programmatically identifiable updates that assistive technology can present without moving focus. Work with the developer to implement appropriate announcements and test them with relevant expertise. Do not announce every tiny numerical change if that overwhelms the reader. Choose meaningful transitions and preserve a visible current state. Distinguish the message content from its technical announcement behavior: clear wording cannot compensate for an update that some users never receive. Consider a person returning to the page after an interruption as well as someone watching continuously.
Verify completion and recovery
Define the actual completion condition, such as a generated file being available and accessible, not merely the last processing step starting. Make the result route clear and retain enough context to identify the requested task. Test cancellation, connection loss, a slow run and a failed run using safe fixtures. Confirm whether a repeated request creates another job or retrieves the existing one, then write the appropriate instruction. Keep the state map with the feature documentation so backend changes trigger a content review. Measure confusion through observed task behavior rather than assuming animation alone reassures everyone.
Make the reasoning concrete.
A hypothetical design tool generates a large preview package for a user.
Cosmetic progress
Opening: A timer reaches 100 percent after a fixed interval even when processing continues.
Hypothesis: The interface appears active.
Risk: The reader may assume the package is ready and repeat the request when no file appears.
Observed states
Opening: The tool reports queued, generating and ready based on actual job events, with a verified return route.
Hypothesis: The reader understands what is known and can continue safely.
Risk: A lost connection must remain unconfirmed until the job state is checked.
The team replaces the artificial countdown and tests the result link before defining the task as complete.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Lifecycle
What observable states and transitions exist?
Measure
What does any percentage or estimate actually represent?
Waiting
Can the reader leave, continue or cancel safely?
Announcement
Which updates need accessible notification without taking focus?
Completion
What evidence confirms the result is ready and usable?
Watch for the wrong conclusion.
- Equating request acceptance with active processing.
- Using a fixed timer as factual progress.
- Promising the reader can leave without testing that behavior.
- Marking a task complete before its output can be accessed.
Your next action
Map one long-running task from request to usable output and write a truthful message for every observable and uncertain state.
Sources & scope
The framework, examples and suggested checks are original editorial synthesis. Hypothetical examples are not measured results. Source checking is not an independent audit or a guarantee of business outcomes. No named human reviewer is claimed.
- W3C WAI: Understanding SC 4.1.3, Status Messages →Primary publisher guidance · Supports: Supports programmatically identifiable status updates that assistive technology can present without taking focus. It does not validate estimates, progress percentages or backend completion states.