Ask five questions before drawing a dialog
- What exact object, version, or set will change?
- What else becomes unavailable, unassigned, or invalid as a consequence?
- Can the backend reverse the action completely?
- How long does recovery remain available, and who can perform it?
- What result proves completion, failure, or an unknown outcome?
If those answers are missing, a polished “Are you sure?” dialog only hides an undefined system contract.
The W3C's error-prevention guidance requires an important data-changing action in scope to be reversible, checked, or confirmed. It does not require a confirmation before every ordinary save. Its confirmation technique specifically applies when an action cannot be undone and says the request should name the selected action and its consequences.
Use recovery when recovery is real
Undo is a good fit for a frequent action when the backend can restore the full object and its important relationships during a stated window. After the action, show what changed, an Undo control, and the time or condition after which undo expires. Keep that message available long enough for the real task; a fleeting toast is not the recovery contract.
Do not call a client-side visual reversal “undo” if the server already performed an irreversible operation. Do not promise restoration when related files, notifications, external side effects, or audit requirements cannot be reversed.
Use review or confirmation for hard consequences
Use a review step when the user needs to inspect structured consequences: the target identity, dependent records, changed permissions, or a large scope. Use a short confirmation when the consequence is simple, clear, and irreversible.
For a modal, follow the WAI dialog pattern:
move focus into the dialog, keep the rest of the page inert, support Escape,
and return focus logically when it closes. For a difficult-to-reverse final
step, the pattern advises considering initial focus on the least destructive
action. A native HTML dialog can handle several mechanics, but content and
consequence still need review.
Specify the complete state map
| State | What the interface must communicate |
|---|---|
| Ready | Named target and current dependencies |
| Reviewing | Consequence, reversibility, and available choices |
| Cancelled | Nothing changed |
| Pending | Request received; duplicate activation contained |
| Failed | Record remains, or the result is explicitly unknown |
| Deleted and recoverable | What changed, how to undo, and recovery deadline |
| Deleted permanently | What changed and the next logical place for focus |
The U.S. Web Design System's alert guidance distinguishes status feedback from a more intrusive confirmation for an action that destroys work. After completion, use a persistent result that says what happened. Disappearance from a list is weak evidence, especially when many rows or a filter are involved.
Acceptance checks
- The trigger names the action; the review names the target.
- The interface states whether recovery is available and for how long.
- Consequences include important dependent records or external effects.
- Cancel changes nothing and returns focus logically.
- Pending activation cannot silently start the same request twice.
- Failure does not look like success or silently remove the object.
- Success names the completed action and next recovery or navigation step.
- The server rechecks authorization and preconditions at execution time.
These checks define visible behavior. They do not implement authorization, transactionality, retention, or restoration. Those backend guarantees must be specified and tested independently.