Skip to content

Dangerous confirm modal best practices #6506

@markov00

Description

@markov00

We have multiple modals in Kibana that are used to ask for confirmation when you are leaving an usaved work in a page. For example, Lens uses the following

and Dashboard has a similar one with a different action and color:

Following EUI example for dangerous confirm modals: https://eui.elastic.co/#/layout/modal#confirm-modal Kibana Dashboard should align to the practice and use the dangerous color for the primary button.

But I have a doubt: is that a good practice? The difference with the simple Confirm Dialog is just the color of the button.
I know that the text of the button is also different, but to me it looks like it can be confusing.
WCAG says that we should not use the color alone and I believe that in this situation we should probably improve it by switching the buttons roles: the primary button should not be the destructive one, but the less destructive: like the Cancel, or something better named like Continue editing. Where the destructive button Dismiss/Discard/Delete/Destroy should be placed on the other side with less emphasis to avoid hasty interactions.

Screenshot 2022-12-30 at 17 44 45

In this way we promote:

  • a positive attitude and without throwing responsibility to the user (using a red color looks like an error done by the user, we instead want just to notify them about a dangerous thing)
  • the primary action is a safe net in most situation, even without reading the message you can click it and nothing happen to your work
  • this mechanism could be also used to teach the user on using the save button instead, as going back to editing stimulate them to find the save button next time, where instead discarding changes by error increase the frustration and the fear of use it.

Interested to hear your thoughts

cc @elastic/kibana-design

Metadata

Metadata

Assignees

Labels

accessibilitydesign decisionUse this to flag an item that needs input from the design teamdocumentationIssues or PRs that only affect documentation - will not need changelog entries

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions