Requires destructive confirmations to identify the target and consequence, follow accessible modal keyboard behavior, and use stronger confirmation profiles only when risk warrants them.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
A destructive action opens a modal that names the consequence and the server display name of the target, not a generic warning. Keyboard focus remains within the modal until confirm, cancel, or dismiss, and initial focus normally favors the least destructive action unless the content needs to be read first. Typed-name confirmation is a high-impact profile, not a universal requirement. Standard form semantics apply: Enter may submit only when the explicit confirm control is enabled and the configured confirmation is valid. Undo after success is offered only when a real recovery path exists.
Scope
- Confirm dialogs for destructive actions on a named target.
- Focus trap, escape, and typed-name confirmation.
- Reversible deletes versus irreversible purges.
- Undo only when a grace path exists.
Outside this block
- Backend purge schedules and backup expiry.
- Replacing the dialog with a spinner that drops the trap.
- Authorization beyond refusing confirm without permission.
Contract
- The dialog accessible name includes the verb and the server target display name.
- Tab cycles only inside the dialog; background controls are inert until close.
- Escape and cancel close without side effects and restore the previously focused control.
- In the high-impact
type-nameprofile, confirm stays disabled until the typed string equalsrequired_phrase; pressing Enter follows normal form behavior and cannot bypass the disabled or invalid state. - Mouse, touch, and keyboard activation invoke the same explicit confirm action only after validation; risk is not inferred from input method.
- Irreversible actions set
reversible: false, communicate the permanent consequence clearly in localized copy, and never promise undo. The literal English word “irreversible” is not required.
Implementation
Use a modal with aria-modal. Choose initial focus using the dialog content and risk profile, usually cancel for a short destructive confirmation or a static explanatory element for long consequences. Fetch the canonical name before open. After reversible confirm, return an operation id for undo. After irreversible confirm, show a static receipt.
Failure handling
If the name fetch fails, do not open a guessing dialog. Mismatched phrases keep the dialog open and announce once. After a network fail on confirm, show uncertain state and refresh existence; do not silently retry an irreversible purge.
Verification
Verify keyboard containment, Escape behavior permitted by the product profile, focus restoration, invalid typed-name refusal, and clear permanent-action copy. Undo must appear only when the mutation is reversible. Execute the packaged scenarios, including a screen-reader pass on the accessible name.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.