Skip to main content
Hennepin County Design System

Buttons

Button elements draw attention to events. Use clear button labels to let the user know what action they will trigger.

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 a meaningful action. Actions can include starting an application, saving information, or expanding and collapsing accordions. 

When not to use

  • Don’t use buttons in place of links. Screen readers treat links and buttons differently. If you need to style a link to look like a button, use CSS.
Open all

Create clear button labels 

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. No feedback makes it hard for users to know why they can't use the button. 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.

Focus on the most important actions. Too many actions on a page can confuse users. Use consistent locations for button positioning on the interface.

Use the right button style

Use button style to guide users.

  • Primary - for the main action the user could take.
  • Secondary - for supporting actions.
  • Tertiary - for low priority optional actions.

Use large buttons 44px by 44px in all public facing applications. This is a comfortable and accessible touch point size for both desktop and mobile devices. This ensures buttons are easy to tap for all users, including those with motor impairments.

Small buttons: May be appropriate for use in internal tools. This is because users are more familiar with the inferences. Always check that the buttons remain visually clear and keyboard accessible. Interactive targets can include white space around the target. This meets WCAG 2.1 AA standard.

Write effective 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.
  • Avoid long, redundant button labels. Drop unnecessary articles, such as: a, or, and the for more concise labels.
  • 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. 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