Destructive buttons

Destructive buttons serve a similar purpose to primary buttons, except they alert the user of potential negative consequences. They should be used sparingly to confirm irreversible actions such as deleting data or canceling a request. Destructive buttons emphasize the importance of considering whether to proceed with the action they represent. Destructive buttons should be red to help draw the user’s attention and convey danger.

See the article on Modals to learn more about confirmation dialogues.

When to use this component

• Use a destructive button as the primary button in the confirmation dialog of an irreversible or destructive action, like deleting content or canceling a request

When not to use this component

• Don’t use destructive buttons for actions that are reversible or don’t have significant consequences to the user

• Don’t use destructive buttons outside of confirmation dialogs or situations where the user is being asked to confirm they would like to proceed with an irreversible or destructive action

Best practices

Do

• Make destructive buttons visually prominent by using eye-catching colors such as red

• Ensure there is sufficient color contrast between the button and text. Be careful when using white text on a red button, as many shades of red will not have sufficient contrast

• When pairing a destructive button with a secondary button, such as in a modal, place the destructive button on the right of the secondary button. If designing for mobile, place the destructive button above the secondary

• Label buttons clearly and keep text short yet descriptive. Labels should use a max of 25 characters. Use common action verbs to help users to understand what action they are initiating when they interact with the button

• Consider the French translation when designing and placing primary buttons on an interface since French uses approximately 2.2x more characters than English

• Buttons should be the size of the text label with additional padding. Use 32px of horizontal spacing (white space) between buttons for desktop and 24px of vertical spacing (white space) between block-level buttons for mobile

Don’t

• Don’t use destructive buttons as the primary button, or main call to action (CTA) on a page

• Overuse destructive buttons, overuse may result in users becoming desensitized to their importance

• Don’t hide destructive action buttons, they should be prominent, easy to locate and consistent across the application

• Don’t use multiple different colors for destructive buttons across an application, this can make them challenging to recognize

• Don’t underline text on a primary button

Accessibility 

The WCAG criteria outlined in this section were chosen because they represent some of the most common failures when designing and implementing these components. For a comprehensive list, please see Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org).

1.4.11: Non-text contrast

All active UI elements must have sufficient contrast to ensure readability and usability for users with visual impairments or in varying lighting conditions. The contrast between the primary button's text and/or icon and its background must meet the minimum contrast ratio of 3:1. Use tools like WebAIM’s Contrast Checker to verify compliance.

Understanding Non-text Contrast

Key component features 

Telerik’s button component can be styled as a destructive button with and without an icon. The component offers various states such as default, focused, and hover, and multiple button sizes for different screen sizes. Please note that while tertiary buttons are available in the Figma UI kit, they have not been developed and added to the theme.

Blazor Buttons Demos - Overview

Open

Figure 1 - Primary button with and without icon example (left to right: default, focused, hover)

Examples

Open

Figure 2 - Telerik destructive button component used to confirm the user wants to delete a time entry

External resources 

GOV.UK Design System - Buttons

WebAIM Colour Contrast Checker

Dangerous UX: Consequential Options Close to Benign Options

Designing for Action: Best Practices for Effective Buttons