How to confirm destructive actions

Recently, I saw an example of asking for confirmation for a destructive action that I really liked.

I posted a tweet where you can see it in action. But basically, this is what happens.

Then I saw this pattern in Zapier (tweet showing it in action). It went further, people implementing this, in different ways.

This approach raised many questions, and I'm not sure I have answers to all the concerns. I would like to hear your opinion and potential solutions to the problems.

Let's go over them.

Double click

The first argument was that users can accidentally double-click, especially those used to doing so on Windows (young people might not know the feeling, but those who used Windows 3.1, 95, 98, etc., know it).

When you need to double-click to open an app and nothing happens visually, you keep on double-clicking, and then boom — you have ten instances of IE6 open. 😅

However, I would say it doesn't work this way, especially if it's a modern web app, because:

• In web apps, we know that everything works with a single click. I don't remember the last time I had to code a double-click.
• The idea of the pattern is to prevent accidental single clicks, not double-clicks. If users want to delete something, they click intentionally, not accidentally. I can barely imagine users accidentally double-clicking links/buttons.
• There can be a slight animation or throttling (slight enough to prevent double-clicking but not enough to be perceived, say, 100ms). That will solve it.

But there is still a problem: creating a habit.

Habit

We are all used to things like banners with ads or confirming actions in popups.

Users might get used to it and confirm deletion subconsciously.

Well, here are my points:

• The action shouldn't be "very dangerous", for instance, we are not talking about account deletion.
• We can fix this by providing an "undo" option. You've probably seen toasts appearing in a corner, giving you the option to undo the destructive action.
• If you use the app daily and know how it works, it seems to me that it won't be a frequent error since you know you want to delete something

If we use a modal with confirmation instead, users might also hit "confirm." The only difference is that the modal is in the center of the screen, but:

• You can still hit the enter button (as a habit)
• It's annoying if you really want to delete something to move your mouse to the center, especially if you need to do it multiple times in a to-do app or a similar one.

Accessibility

I'll admit, this is where my knowledge sucks.

But as far as I understand,

• By using Tab, I can access the dropdown menu with actions
• The screen reader reads all the labels.
• Each label has an icon (which helps people with color vision deficiencies).
• The label is in red.
• When you reach the delete button with Tab keys and hit Enter, another button appears.
• I bet it's totally doable to make the screen reader announce that confirmation is required (it works with modals, right?).

So it seems feasible to handle accessibility as well. But again, I'm not an a11y professional and might be wrong.

Random thought

For almost every redesign, tweet, or tip, I got feedback that there might be an accessibility issue.

But why haven't I ever seen this: provide users an option (when signing up, logging in, or in profile settings) to enable "accessible" mode or set accessibility settings?

After all, if we find out that a solution works well for people without disabilities, and those users are 90% of the total, why not make a special version of some features tailored specifically for the 10% of users with disabilities and satisfy both groups?

For example, you can increase font size with Chrome on any site; you have magnifiers and screen readers. If it was the same experience for everyone, we wouldn't need these things.

So why not ask users first and then use the best option for each? I don't think it's a huge problem to make a setting for increasing contrast, adding extra icons, increasing clickable areas, and so on.

Since we can (more or less) handle responsive design, dark mode, and similar features already.