A visitor presses a button and nothing seems to happen. Perhaps the request is travelling to a server; perhaps it has already finished; perhaps the connection has failed. A spinning ornament does not resolve that uncertainty. Waiting is part of the interface, and it deserves the same editorial care as the final result.
Name the work, not just the delay
Start with the action the person has chosen. ‘Preparing the comparison’ is more informative than a lonely spinner because it connects the pause to the task. Keep the explanation close to the affected content. The rest of the page should not become an unexplained blank screen when only one small section is updating.
Do not invent precision. A percentage is useful only when the system can measure meaningful progress. A countdown that resets or freezes at ninety-nine percent creates a promise the interface cannot keep. If the remaining time is unknown, say what is happening without manufacturing a deadline.
Separate receipt from completion
A button press, receipt of a request and completion of the requested work are not the same event. Define what each message means before choosing its colour or animation. For example, accepting a file for processing does not mean the file has been checked; saving an enquiry does not mean someone has answered it.
Show success only after the relevant confirmation is available. If the outcome is uncertain, preserve that distinction rather than displaying a reassuring green tick. Clear states also help a support conversation later: the visitor can describe what the page actually reported instead of guessing.
Make the update available beyond sight
A small change at the edge of the screen can be missed. W3C’s explanation of status messages covers updates about results, waiting or progress that do not move the user’s focus. Appropriate roles or properties allow assistive technologies to present those messages without forcing the person into a new context.
For a region receiving several related updates, MDN describes aria-busy as a way to mark that changes are not yet complete. Return it to false when the update is finished. It is not a visual loading indicator by itself, and adding the attribute does not replace testing the actual announcement and the visible text.
Leave a safe next step
Waiting should not become a dead end. Keep the visitor’s input when possible, explain a failure in ordinary language and offer a next action appropriate to the operation. ‘Try again’ is not automatically safe: if the first request may have succeeded, a second submission can create a duplicate. Establish the outcome before encouraging repetition.
If cancellation is supported, make its effect clear. Stopping the visible animation is not the same as cancelling server work. A route back to the page can be helpful, but it should not silently discard the person’s effort. The principles of helpful form errors apply here too: describe the situation and the useful next step.
Test the awkward middle, not only the happy ending
Review a quick response, a slow one, a failure and an uncertain outcome. Watch whether the message arrives at the right time, whether repeated clicks are handled deliberately and whether keyboard focus remains sensible. Check the reduced-motion presentation as well: the meaning must survive without a spinning or pulsing effect.
During ongoing website care, revisit these states when the underlying service changes. The goal is not to make every wait entertaining. It is to give the visitor an honest answer to three questions: what is happening, what is known and what can I do next?