Write and announce interface status messages

Name a confirmed state

Write from the service state, not the click. “Request received” needs confirmed receipt; “Sending” means waiting. A stopped animation does not prove acceptance. Avoid always showing success when the network or server can still reject the request.

No result is different from failure. Distinguish “No products match” from “Unable to load the catalogue”. One invites changed criteria; the other may offer retry. Provide a workable action without discarding fields already completed.

Announce without needless interruption

The W3C criterion on status messages concerns changes that should be perceived without receiving focus. An appropriate region can communicate a result. Reserve urgent announcements for situations that truly justify interruption.

Do not announce an entire result list on every typed character. Communicate a useful summary after updating and keep results available for reading. Check for repeated messages and outdated counts overtaken by newer input.

Preserve useful evidence of the task

A temporary message may suit a reversible action, but important confirmation should remain findable. An enquiry may need a summary or result page. References and next steps must match what the service actually accepted.

Explain failure without unnecessary technical detail. Preserve recoverable input and indicate whether retrying could create a duplicate. When the outcome is uncertain, state that uncertainty rather than claiming success or failure without evidence.

Example: filter a document library

Educational example: filtering announces “8 documents” while focus stays on the filter. No matches prompts removal of a criterion. A service failure explains that data could not load. Testing distinguishes all three outcomes and verifies that the message belongs to the latest search.