Define truthful states
A background action can leave a customer uncertain even when the software works correctly. After a file upload, report export or saved change starts, the button may remain in place while the result appears elsewhere. A sighted user may notice a spinner or colour change; someone using a screen reader may receive no indication that the task began or finished. The first design question is what the user needs to know to continue: accepted, still processing, completed, failed, or ready for another action. Show those states in ordinary visible words near the task, and make meaningful changes available to assistive technology. W3C's WCAG 2.2 guidance treats success, warning and progress messages as status information that can be conveyed without moving focus. This is about communication during asynchronous work; it does not replace the separate duty to identify and explain invalid form fields.
Map the task lifecycle before choosing ARIA attributes. Write down each transition and whether the application knows the true state. An upload can be waiting for a connection, transferring bytes, undergoing server validation, being scanned, and finally being accepted or rejected. A single 'complete' label when bytes reach the browser's network layer can be false if the server later rejects the file. An export request may be accepted immediately while the file is prepared in a queue. Distinguish 'request received' from 'download ready' and give the user a way to find the result later if it can take a while. For uncertain duration, use a truthful 'still processing' message and avoid an invented percentage. A progress bar is useful only when its value represents measurable progress and its end state is tied to the actual task outcome.
Use a polite status channel for routine updates that should be announced after the current speech finishes. W3C's documented techniques include role=status for success or application state, and a live region for progress. Put a persistent status container in the page before the action and update its text when the state changes; test the chosen implementation with the screen readers and browsers your customers actually use. Keep the visible text as the source of truth so visual and spoken users hear the same result. Do not move keyboard focus merely because 'uploading' becomes 'uploaded'. Focus should remain on the control the customer is using unless the interface genuinely changes context, such as opening a dialog that requires action. A silent spinner alone is insufficient; a constantly announcing timer is distracting.
Announce without interruption
Reserve an alert for an important, time-sensitive interruption. W3C's alert pattern describes a brief message that draws attention without taking keyboard focus, and warns against frequent interruptions or alerts that disappear too quickly. A failed upload that needs immediate retry may justify a concise alert, but routine '20 percent, 21 percent' updates do not. If the problem needs a decision, show a persistent message with an actionable control rather than a transient toast. State what failed and what remains saved: 'The file was not attached; your form details are still here' is more useful than 'Error'. Avoid announcing the same failure repeatedly as the component rerenders. If the user must inspect a new panel, manage focus deliberately according to that interaction instead of treating every status change as an alert.
Take a realistic case: a clinic asks a patient to upload a document before booking. The interface first says 'Uploading file'; after transfer, it says 'Checking file'; only after server acceptance does it say 'File attached'. If validation rejects the file, it explains the reason that the system can actually verify and offers a retry control while preserving the rest of the booking draft. If the network drops before the server confirms receipt, the interface must avoid claiming success just because the local progress bar reached its end. The customer should be able to inspect the attachment list, which is a durable record of the result. For a staff-facing export, the equivalent sequence might be 'Request queued', 'Preparing export' and 'Download ready', with a link or notification history for later retrieval. The words follow system state, not animation state.
Make status language specific in both site languages. A terse English 'Done' and Chinese '完成' may leave a user unsure whether the upload, scan, submission or booking completed. Name the object and action: 'Receipt uploaded; booking not yet submitted' and its natural Traditional Chinese counterpart. Test longer Chinese phrases at narrow mobile widths without hiding the end of the message. Keep the status attached to the relevant task if the page has several simultaneous uploads, so one completion is not mistaken for another. Avoid relying on colour alone; text and icon can reinforce each other. If a progress value is shown visually, its accessible name and value should identify the same operation. Update only when meaningful state changes occur so assistive technology does not become a running commentary on implementation details.
Test the full journey
Acceptance testing should follow the full journey, not a single screen capture. Start with keyboard focus on the action control; trigger the task, let it complete, then repeat with a delayed response, a validation failure and a lost connection. Confirm that the visible and announced messages agree at each transition, that focus does not jump unexpectedly, and that a person can recover without losing unrelated work. Repeat in English and Traditional Chinese. Use a real screen reader and browser pairing because a markup inspection alone cannot establish what is announced. Check whether a late server response can overwrite a newer attempt's status; if the user retries, the interface must keep results associated with the right request. Capture observations as task outcomes and defects, rather than merely checking that an ARIA attribute exists in the DOM.
Start small with one high-value action, such as document upload or invoice export. Ask staff to list the actual server states and customer decisions, write visible messages for each, and then choose the appropriate accessible announcement mechanism. Add a durable result location and a recovery path for failure. Review support tickets about duplicate clicks, abandoned tasks or 'did it save?' questions after release; they can reveal ambiguity, although they do not by themselves prove an accessibility outcome. W3C's status-message criterion addresses programmatic identification without requiring focus movement, while its alert pattern cautions against unnecessary interruption. The practical goal is simple: every person should know whether the business received their action, what remains pending, and what to do next, without having to guess from a spinner.
The interface also needs a policy for leaving the page. If a report continues on the server after the tab closes, tell users where its result will appear and whether reopening the page is necessary. If closing the tab cancels a browser-only transfer, say that before they leave. Do not rely on a transient toast as the only proof that an irreversible action, such as submitting a request, succeeded. Give the action a stable reference or visible history entry when the underlying system supports one. During an outage, distinguish 'we could not confirm receipt' from 'we did not receive it'; the first calls for checking before a retry that might duplicate work. The same distinction should be reviewed by the business team because only it knows the consequences of a duplicate request. Clear status writing therefore depends on accurate backend states and recovery design, not only front-end markup.
Before changing the live system
- Does each message reflect the server’s real state?
- Can screen reader users hear important changes without losing focus?
- Can users find the result or recover after failure?
