# Confirmation or undo?

[Website version](https://patterns.alexanderclaes.com/patterns/destructive-actions/)

Updated 28 October 2026

Use undo for safely reversible changes. Confirm specific, irreversible consequences.

## Recommendation

Offer undo when restoration is reliable; confirm when the consequence cannot be safely reversed.

## Problem

An action could remove something important.

## Choose confirmation or undo

- Confirm before permanently deleting an account or shared data that cannot be restored.
- Offer undo after removing an item when all affected data and state can be reliably restored.

## Confirmation and undo mistakes to avoid

- A generic 'Are you sure?' for routine actions people perform repeatedly.
- Promising undo when external effects, messages, or permissions cannot be restored.

## Example

[View the example on the website](https://patterns.alexanderclaes.com/patterns/destructive-actions/#example).

## Implementation

1. Name the item, what changes, who is affected, and any limits on recovery. Use a specific action label such as “Delete project” and a clear Cancel action.
2. If confirmation uses a dialog, give it an accessible name and follow modal keyboard and focus behavior. For a hard-to-reverse action, consider initial focus on Cancel; this is a design recommendation, not a universal rule.
3. For undo, retain everything needed to restore the item. Prefer a lasting recovery route such as Trash or history; a brief Undo timeout needs an equivalent untimed route or must satisfy WCAG 2.2.1’s timing rules and exceptions.
4. WCAG 3.3.4 requires a safeguard for covered changes to stored user data: reversal, checking with correction, or review and confirmation. It does not require a confirmation dialog for every routine save.
5. After removal, move focus to a logical control if its current target disappears. Make the outcome and any restoration feedback available to assistive technology.

## Tradeoffs

Confirmation adds friction and can become habitual. Undo is faster but shifts responsibility to recovery. The correct choice depends on actual reversibility, not how dramatic the button looks.

## Verification

Can users identify the affected item and consequences, cancel before an irreversible action, and find and use recovery whenever it is offered?

## References

- [W3C · Error prevention for legal, financial and stored-data changes](https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html)
- [W3C · Recovering deleted information](https://www.w3.org/WAI/WCAG22/Techniques/general/G99)
- [W3C · Time limits and equivalent untimed alternatives](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html)
- [W3C · Modal dialog keyboard and focus behavior](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)

## Related patterns

- [Modal, drawer, or separate page?](https://patterns.alexanderclaes.com/patterns/modal-or-page.md)
- [Toast, banner, or inline message?](https://patterns.alexanderclaes.com/patterns/toast-or-banner.md)