01 — Foundation

Confirmation creates confidence

Users should never wonder whether an action worked.

Confirmation patterns reassure users that actions succeeded. Without clear feedback, people repeat clicks, lose trust, and assume the interface ignored them.

02 — Success

After the action succeeds

Feedback should be immediate, visible, understandable, and proportionate to the task.

  • changes saved, upload complete, account created, payment successful
  • inline or in-context messages — not only colour or a tiny toast off-screen
  • announce success to assistive technology without hiding the message from sighted users
<p role="status" aria-live="polite">
    Changes saved.
</p>

03 — Destructive

Before destructive or irreversible actions

Some actions need confirmation before execution — not after.

Deletion, account closure, and payment submission may need a focused confirmation step. Use a native dialog with specific copy — see the Modal / Dialog pattern for focus and Escape behaviour.

'Delete this invoice permanently?'

Vague “Are you sure?” copy causes mistakes. Name what will happen and whether recovery is possible.

Avoid confirmation fatigue

  • do not confirm harmless actions constantly — users stop paying attention
  • prefer undo where possible instead of blocking every small change

04 — Accessibility

Accessible confirmation

Confirmation is state communication — not decoration.

  • sufficient contrast and readable text for success and error states
  • aria-live regions used thoughtfully — not noisy repeated announcements
  • motion restrained; respect prefers-reduced-motion

05 — Review

Before you approve

A short checklist for confirmation in code review.

  • users can tell whether the action succeeded without guessing
  • destructive actions use specific pre-confirmation, not generic prompts
  • feedback is visible, announced appropriately, and not overused

Confirmation should create confidence — not force users into detective work.