How can I announce loading and completion states for a website action?

Treat the messages as a short account of the action’s real state, not as decoration. Before work starts, the button can say “Export report.” Once the export has actually begun, show a clear in-progress message such as “Preparing your report…” and make it apparent which report is being prepared if the page contains several.

When the result is ready, say what happened: “Report downloaded” or “Your report is ready to download,” depending on the behavior. If the action fails, state that it did not complete and give a useful next step when you know one, for example, “Report couldn’t be prepared. Try again.” Avoid saying “Done” if the result has not yet been delivered or made available.

Use a percentage only when the application has a meaningful measurement of progress. If it cannot measure progress, a concise activity message is more honest than a changing number that merely looks precise.

For routine updates such as “Preparing your report…” or “Report ready,” use a status region: it is intended for advisory information, has polite live behavior by default, and should not take focus away from the user’s current activity. [S2] A live region can announce dynamic changes without moving focus; polite announcements generally wait for a suitable opportunity, while assertive announcements can interrupt and are best reserved for cases needing immediate attention. [S3]

Make sure the live region is already present before its text changes. [S3] If several pieces of a region are being updated together, aria-busy="true" can signal that updates are underway; set it to false when they are complete so assistive technology can receive the finished update rather than incomplete intermediate content. [S1] That attribute does not tell users a percentage or say whether the action succeeded or failed, so provide accurate outcome text separately. [S1]

In this example, the status text changes as the action moves through its states; the quoted messages are illustrative, not a prescribed workflow:

1. Start: “Preparing your report…”
2. Success: “Report ready to download.”
3. Failure: “Report couldn’t be prepared. Try again.”

Keep the message concise and avoid announcing every internal step if those steps do not help the user.

Show the in-progress state only after the action has actually started. Make the affected control’s state understandable, and prevent accidental duplicate submissions if that fits the action; if you disable a control, keep the in-progress message visible so the user still knows what is happening. When the action ends, restore or update the control according to the real result.

For a retry, begin a new state sequence: replace an old success or failure message with the current in-progress message, then announce the new outcome. Do not leave a previous “Report ready” beside a failed retry, where it could be mistaken for the latest result. If the action’s state is uncertain, say that it is still being checked rather than claiming success or failure.

A useful design check is to ask: “If someone sees only this message, can they tell which action it describes and whether it is still underway?” If not, add the relevant item or action name, not implementation details.

Review the full path from activation to outcome, including failure and retry—not just the spinner. Confirm that visible wording and announcements stay in sync, that the message reflects the actual result, and that routine updates do not unnecessarily interrupt or move the user. The guidance here explains announcement behavior and update signaling; it does not establish a particular product workflow, progress measure, or wording for your action, so check those choices against what your interface actually does.