A useful delete confirmation dialog names the item, explains what else will disappear, and gives the user a clear way to stop. For a SaaS product, the copy and the keyboard behavior should support the same decision.
A red button alone does not explain the scope. “Delete project” might remove an empty folder, shared reports, or work that other people still need. Make that difference visible before the final action.
Write the consequence before styling the dialog
Start with three questions: What is being deleted? Who or what else is affected? Can the user restore it?
Here is a hypothetical dialog for a project tool:
Delete “October client report”?
This removes the project and its 12 saved reports for everyone in this workspace. You cannot restore them from this app.
Cancel · Delete project
Use those claims only if the product behaves that way. If the action moves the project to a recoverable trash folder, state the real recovery window. If attachments stay elsewhere, say so when that would change the choice.
Avoid “Are you sure?” as the entire message. The person needs enough detail to know what they are confirming.
Match the interruption to the action
Use a confirmation step where a mistaken action would be costly. For frequent, recoverable actions, consider a clear undo flow instead. That is a design choice to test with your users, not a rule that every product must follow.
Typing a project name can add a deliberate pause for a serious action, but it does not replace an explanation. A person can copy a name without understanding what will disappear.
The W3C alert-dialog pattern is intended for an important message that interrupts a task and needs a response. It describes a labelled dialog with its alert message connected for assistive technology. Do not make every routine notice an alert dialog.
Keep keyboard focus inside the decision
The W3C modal-dialog pattern describes moving focus into a modal, keeping Tab and Shift+Tab within it, and closing it with Escape. For a difficult-to-reverse final action, it suggests considering initial focus on the least destructive choice.
For the example above, Cancel is a sensible starting point. A keyboard user should not land on Delete merely because it is visually prominent.
When the dialog closes, return focus to the control that opened it when that control still exists. If the deleted row is gone, choose a logical place in the remaining workflow. A modal label alone does not implement any of this behavior.
Design the failed request too
Write down what the person should see while deletion is running, when it succeeds, and when it fails.
For example, keep the selected project name visible while the request runs. If the server rejects the request, retain the project and explain that deletion did not finish. Let the person retry or cancel. Do not show a success message just because the button was clicked.
Also check a stale page: what should happen when a teammate has already removed the item? The interface should resolve the current state without trapping the user in an endless retry.
Review the flow with a small test list
Use a disposable test project, then check these cases:
- Open the dialog using only the keyboard and read its title and consequence.
- Move forward and backward through the controls; check Escape and Cancel.
- Confirm one deletion and check where focus goes afterward.
- Simulate a failed request and verify that the item still exists.
- Check whether another user's view and any recovery screen match the promise in the dialog.
These checks do not replace a full accessibility review. They do give the deletion flow a concrete promise to meet: the user understands the choice, can operate it, and sees what actually happened.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
