Skip to main content
Hennepin County Design System

Buttons

Button elements draw attention to events. They let users know what will happen next and give users a choice of options. Labels for buttons clarify to the user what action they will trigger when they use a button.

Default buttons

Default buttons help users execute primary actions on a page.

HTML

<button class="hc-button">Primary</button>
A PrimeNG default button component example.

Import

import { Component, OnInit } from &#39;@angular/core&#39;;

@Component({
  selector: &#39;app-button&#39;,
  templateUrl: &#39;./button.component.html&#39;,
  styleUrls: [&#39;./button.component.css&#39;]
})
export class ButtonComponent implements OnInit {

  constructor() { }

  ngOnInit() {
  }

}

Label

&lt;button pButton label=&quot;Button&quot; aria-label=&quot;Primary&quot;&gt;&lt;/button&gt;

When to use

Use the button component to help users carry out an action. Actions can include starting an application, saving information, or expanding and collapsing accordions. 

Use this button for: 

  • Submit
  • Save and continue
  • Next page

When not to use

  • Don’t use buttons in place of links. Use links for link and style to look like a button in CSS.
Open all

Create clear button labels

Make button labels concise and clear enough to state the action the user will take. Use strong action verbs or phrases. For example, use verbs like "submit," "register," "sign up," "donate," etc. 

When using icons as buttons, use aria-label or aria-labelledby. This will give the button an accessible name. For example: an arrow icon for a next page button.

When using an icon and text within a button, make the icon hidden to screen readers using aria-hidden=”true”. The icon image is redundant if a button is already labeled.

Don’t rely only on the use of color to convey the seriousness of the action. Not all users can distinguish color or know what it signifies. Warning buttons are often red. Use color, context, and button text to state what will happen if the user clicks the button.

Identify expand-collapse state

Use aria-expanded attribute on the button. This lets screen reader users know if an accordion state is expanded (“true”) or collapsed (“false”).

Avoid disabled buttons

Avoid using disabled buttons, especially in forms. Disabled buttons provide no feedback, making it hard to know why the button isn't usable. Instead, use validation and errors to show the user what they still need to do. If you must have a disabled button, use the aria-disabled attribute. This will notify screen readers of the button’s existence. You must also create extra styling and event listeners. These will ensure the disabled button is accessible.

Overview

Use different button styles for the initial and final actions. Use one style for the initial action. Use a separate style for the warning button that comes before the final action.

  • Focus on the most important actions. Too much action on a page can confuse users.
  • Use consistent locations for button positioning on the interface.
  • Buttons should be no smaller than 44px by 44px. This is a comfortable touch point size for both desktop and mobile devices.

Button label

  • Avoid long, redundant button labels. Drop unnecessary articles, such as a or the, for a more concise label. Use a verb and a noun. For example: start survey.
  • Write buttons in sentence case. Capitalize only the first word unless using a proper noun.

Open all

Secondary buttons

Secondary buttons help users execute supporting actions related to a primary button. Examples of secondary buttons include Back and Cancel. Secondary button colors are more subtle. They should not be as noticeable as primary buttons.

HTML

<button class="hc-button hc-button--secondary">Secondary</button>
A PrimeNG secondary button component example.

Import

Label

Warning or danger button

Warning buttons interrupt users before taking a destructive action. For example, a button would warn a user before permanently deleting an account. They only work if we use them for rare, specific events. Most services should not need one. When needed, include a step asking users for final confirmation.

HTML

<button class="hc-button hc-button--danger">Danger</button>
A PrimeNG warning button component example.

Import

Label

Disabled button

Disabled buttons display as greyed out. Users can’t interact with them. A user should understand they can’t do the action associated with them. Disabled buttons have inherent issues with accessibility so use them only very sparingly. It’s better to keep a button enabled and show an error message explaining why the user cannot proceed.

HTML

<button class="hc-button hc-button--secondary" aria-disabled="true">Disabled</button>
A PrimeNG disabled button component example.

Import

Label

Open all

Disabled buttons block users without informing them what is wrong. Avoid using disabled, especially for form submissions.

Disabled buttons generally have poor color contrast. This can confuse users who are visually impaired.

Use aria-disabled=”true” to make the button disabled and visible to screen readers. This helps the button receive focus on tab and notifies the screen reader user of its existence.

The aria-disabled attribute requires both CSS and JavaScript/TypeScript. This toggles between an element as enabled or disabled. Mozilla article on the aria-disabled attribute.

Open all