1. Home
  2. :
  3. Tests by component
  4. :
  5. Buttons

Buttons

General information

Buttons are used to take an action, most frequently in forms, but also to complete tasks or trigger events.

Warning!
Designers and developers often use buttons where they should be using links and vice versa. Read Links vs Buttons to make sure you’re implementing the right one.

Using the <button> element

This newer method for creating a button allows you to add some HTML elements inside the button element, and is the recommended way to create a button. 

<button>Refresh</button>

Using the <input> element

This was the original method for generating buttons back when dinosaurs roamed the earth. MDN notes:

Note: While <input> elements of type button are still perfectly valid HTML, the newer <button> element is now the favored way to create buttons. Given that a <button>‘s label text is inserted between the opening and closing tags, you can include HTML in the label, even images.

by MDN on <input type=”button”>
<input type="button" value="Refresh" />

When to use

  • When the user triggers an event or action. Examples:
    • Refreshing a page. 
    • Saving or canceling a form. 
    • Moving elements up or down on a list. 
  • When navigating a paginated subset of data within a larger page, such as a wizard or paginated table.

When to use the Primary Action button variant

Most design systems include a button style specifically indicating the primary call to action. This is the thing you want the user to do next to complete the happy path of their task flow. Examples: Save, Create, Next, Finish. The Primary Action button has a higher visual hierarchy than the other buttons (possibly excepting the Risky button) and often the highest visual hierarchy of anything on the page.

In an ideal world, each page has only one call to action.

When to use the Risky button variant

Many design systems include a button style specifically signaling to the user that Use the Risky button to signal that “the action you’re about to take is risky.” This includes destructive actions such as clearing repository data, deleting an item irreversibly, or taking other irreversible actions that could cause the user extreme angst if they messed them up.

When not to use

  • When the user is navigating to another location or context. Use a link instead.
  • In place of other form fields that indicate state such as toggles or radio buttons or custom choosers. Buttons do things, they do not indicate a user’s choice. 
  • When the reason you’re using a button is to draw attention to a call to action that takes the user to another place. There are lots of ways to get a user to a call to action or next step. Buttons are not a visual hierarchy tool. Use a link and make it fancy.

Components contained within it

None. It may contain text or icons, but both of those are content, not components.

How to use

  • Place buttons associated with forms as close to the end of the form as possible. Not in the footer, not in the header, not way to the right of the form. Under the last field.
  • Ensure that buttons associated with dialogs are be contained within button sets for design and development convenience, generally at the bottom of the dialog. 
  • Place buttons not associated with forms or dialogs as close to the item that spurs the action as possible. For example, a Search button should be adjacent to the search box, not in a button bar at the bottom of the page.

Anatomy

Basic buttons

A basic button is text normally with a background color or border to set it off from other elements on the page. For a <button>, the accessible name by default is the text inside the element. For an <input type="button"> the value attribute provides the accessible name.

Decorated buttons

Buttons often have an icon next to the text. If the icon and the text mean the same thing, hide the icon from assistive technology using the aria-hidden attribute. If the icon has its own meaning that the user must also be aware of, the icon must provide its accessible name through the alt attribute or a similar technique.

If you’re still supporting Internet Explorer (I’m sorry) and you’re using an SVG icon, you also need to ensure that focusable=false so that it doesn’t add a tab stop for the SVG.

Icon buttons

Icon buttons — buttons that only have an icon to indicate their use — are more difficult for users to understand , so avoid using buttons of this type whenever possible.

If you are using an icon button, you must provide an accessible name. There are a large number of techniques to provide an accessible name to the icon button.

Sara Soueidan provides five different techniques for providing icon buttons with accessible names that don’t visually display text.

Do and do not

Do

  • Ensure each button on the page has a unique accessible name. Nobody wants to try to remember which of the five “Click here!” buttons they’re supposed to click.

Do not

  • Avoid using icon buttons as much as possible. You or your team may think that the meaning of each icon is perfectly clear, but humans gave up writing strictly in pictograms for a reason and that reason was clarity. If your user has to interpret what the icon means, there’s a strong chance they won’t bother.
  • Avoid disabling buttons whenever possible. See below

Special Topics: Disabled Buttons

Disabled buttons in the interface should be the exception, not the rule.

I often see design systems whose design of serial processes includes disabling the continue or submit button until the user has completed all the required fields and cleared any validation errors. The argument is that by disabling the button, we’re signaling to the user that they’re not ready to proceed.

That doesn’t work. At all.

First, disabling a button it doesn’t stop users from trying to click that button if they think it’s the next step. (You can thank “flat design” and grey buttons for that.) Your users will often think the button’s broken instead of thinking they can’t do something. (Yes, this also means that your error messaging, presuming you’re displaying it, isn’t catching the user’s attention. But in the meantime, the disabled button isn’t helping them either.)

Second, disabled buttons by definition can’t give the user any feedback. If a user isn’t allowed to move forward in a flow because they haven’t completed a required field, a disabled “next” button won’t tell them what’s wrong. An enabled button that, upon failure to validate, displays a dialog or moves the focus to the error, will tell them what’s wrong. The user needs to know what’s wrong.

Third, disabled buttons don’t get keyboard focus, so users on assistive technologies might not know that whatever option that button is offering is available. They may fill out a form and go hunting for the save button unable to find it because they’re unaware they’re in an error state.

Don’t disable buttons if you don’t absolutely have to. Not just for serial processes, but for almost anything.

Here are a few examples of when we do disable buttons:

  • Disable a button if it’s part of a set of actions, but doesn’t apply right now. For example, when we paginate a table, the Previous button is disabled on Page 1, but enabled on Page 2.
  • Disable a button if it’s part of a component or larger container that’s also disabled.

Otherwise, enable buttons and provide appropriate contextual feedback on what prevents the button from doing what the button’s supposed to do.

Options

Types

Sizes

States

Variants

Modifiers

Content standards

NOBODY LIKES TO BE SHOUTED AT. ALL CAPS IS COGNITIVELY HARDER TO READ, TOO. DON’T MAKE ALL CAPS BUTTONS.

Animation standards

Interactions

Presentation

Placement

Hierarchy

Alignment

Composability

Responsive behavior

Spacing

Accessibility guidelines

Additional Resources