Name the condition and authority
Before choosing microcopy, identify the condition, who decides it, when it was last checked, which action it affects, and whether input can be retained. A browser clock or local component state can display a condition; it cannot decide that a reservation, role, or policy is still valid.
Use text that distinguishes “the condition changed before confirmation” from “your request was denied” and “the operation completed.” W3C's error identification guidance requires detected input errors to be described in text. A changed system condition is not always an input error, but relying only on color, disappearance, or a disabled control leaves the consequential change unexplained.
Preserve context and recovery
Show the action, record, old or current condition where policy permits, and the time or revision the system supplied. If the service rejects the action, show only its policy-safe reason class—for example changed precondition, authorization denial, or conflict—rather than collapsing every result into one “blocked” label. If the policy does not permit details, use a generic unable-to-complete message and a generic review or support route. Keep prepared values visible unless policy requires their removal; if they are removed, explain why. Provide the applicable recovery: refresh, revise, withdraw, request review, or start a new attempt.
Use a pre-existing role="status" aria-atomic="true" region when the whole changed-condition message—including affected action, consequence, and next step—must be announced together. ARIA22 describes this as a polite way to expose ordinary status changes without moving focus. Important recovery choices still need visible, keyboard-reachable controls.
Review the state map
Use this acceptance map before implementing the screen. It is an editorial specification, not a browser or policy test and not a claim that the interface enforces the condition.
| State | Visible text and context | Action available | Trusted-service boundary |
|---|---|---|---|
| Ready | Name the action, record, current condition, and consequence. | Confirm, revise, or withdraw. | Service evaluates the condition again. |
| Changed before confirm | State what changed, when known, and which action is affected. Preserve prepared values if policy allows. | Refresh, revise, withdraw, or request review. | Service supplied a newer condition. |
| Blocked | State the policy-safe reason class and affected action; distinguish changed condition, authorization denial, conflict, and service failure only where details may be disclosed. | Follow the reason-specific path, or offer generic review or support when details are restricted. | Service returns the current decision and disclosure-safe reason class. |
| Refreshed | State that the condition was refreshed and whether re-confirmation is required. | Confirm after deliberate re-review. | Service returns current snapshot. |
| Withdrawn | State that the operator ended this pending attempt. | Start a separate attempt where policy permits. | Service records withdrawal if consequential. |
| Completed | State final result and operation reference. | View result or begin a new permitted operation. | Service recorded completion. |
Acceptance checklist
- The changed precondition and affected action are identified in text.
- Changed-before-confirm is distinct from final denial, withdrawal, and completion.
- Draft input is retained or its removal is explained.
- Refresh, revision, withdrawal, and escalation options are explicit.
- Recovery controls have a keyboard-operable equivalent; W3C's keyboard guidance describes this requirement. Ordinary status messages are programmatically determinable, and the pre-existing status region includes complete context with
aria-atomic="true"when needed; separately test the implemented screen with keyboard and assistive technology. - A trusted service evaluates the condition again before completing the operation.
Can the interface simply disable Confirm after a condition changes?
It may disable that path, but it must also explain what changed and what the operator can do next. The service must still make the final decision when a request arrives.