Build a Confirmation Dialog: Patterns and Edge Cases

By /
⏱ 2 min read

Confirmation dialogs (“Are you sure you want to delete?”) protect users from mistakes. Done well, they prevent disasters. Done poorly, they create fatigue without protection. The interview tests whether you understand when to show them, how to design them, and the technical patterns.

When to show a confirmation

Show:

  • Destructive actions (delete account, delete data)
  • Irreversible actions (publish, send)
  • Actions with significant impact (charge a credit card, send email to many users)

Don’t show:

  • Reversible actions (undo is sufficient)
  • Common low-stakes actions (save, edit)
  • Actions the user just initiated (no need to double-confirm)

Functional requirements

  • Modal dialog blocks interaction
  • Title and explanatory text
  • Two buttons: Confirm (action) and Cancel
  • Destructive Confirm has red styling
  • Default focus is on Cancel (safer)
  • Escape and click-outside dismiss as Cancel

The “type to confirm” pattern

For very destructive actions: require typing the resource name.

"Type 'my-project' to confirm deletion"

Used for: deleting databases (Stripe, AWS), deleting accounts, irreversible operations. Significantly reduces accidental deletions.

Implementation: enable Confirm button only when input matches expected text.

The “checkbox to confirm” pattern

“☐ I understand this action cannot be undone.” Confirm button enables only when checked.

Less friction than typing; less safety. Use for moderate-stakes actions.

Architecture

Imperative API (most ergonomic):

const ok = await confirm({
  title: 'Delete project?',
  description: 'This cannot be undone.',
  confirmLabel: 'Delete',
  destructive: true
});
if (ok) deleteProject();

Library: react-confirm, custom hook around your modal system.

Same patterns as general modals:

  • Focus trap
  • Escape closes
  • Click outside closes
  • Returns focus to trigger
  • aria-modal, role=”alertdialog” for confirmations

Default focus

For destructive actions: focus Cancel by default. Pressing Enter cancels by default.

For non-destructive (publish): focus Confirm. Pressing Enter confirms.

Saves users from accidental Enter-key destruction.

Loading state

If the confirm action is async:

  • Show loading spinner on Confirm button
  • Disable both buttons during request
  • On success: close dialog, show success toast
  • On error: keep dialog open, show error inline

Multi-step confirmations

For very high-stakes:

  1. First dialog: “Are you sure?”
  2. Second dialog: “Really? Type ‘DELETE’ to confirm”

Reserve for genuinely catastrophic actions. Two clicks of friction signal the cost.

Confirmation fatigue

Showing confirmations for everything trains users to click through without reading. Counter:

  • Reserve confirmations for genuinely consequential actions
  • Make undo the primary safety mechanism
  • Vary the confirmation type (text vs checkbox vs default focus) to keep attention

Mobile

  • Bottom sheet instead of centered modal
  • Larger tap targets
  • Same confirm/cancel patterns

Accessibility

  • role=”alertdialog”
  • aria-labelledby pointing to title
  • aria-describedby pointing to description
  • Initial focus on safer button (Cancel for destructive)
  • Buttons have explicit labels (not just “OK” — say “Delete project”)

Common antipatterns

  • “OK” / “Cancel” without context
  • Default focus on destructive button
  • Confirmation for trivial actions
  • No undo as alternative
  • Modal that does not return focus on close

Frequently Asked Questions

Should every delete require confirmation?

For trash/recycle-bin model: no — soft delete with undo is enough. For hard delete: yes.

How do I avoid confirmation fatigue?

Use them sparingly. Make undo the default. Reserve for irreversible actions.

Should confirmations have keyboard shortcuts?

Yes. Cmd+Enter or Tab+Enter to confirm. Escape to cancel. Match user expectations.

Scroll to Top