Button

Buttons allow users to take action.

Sizing

A Button can be sized based on its content or based on its containing element.

Content-based

A Button can be sized based on its content. This means that the total width is the sum of the content (an optional icon + label) and the Button padding. Therefore, changing the label will decrease or increase the width.

This is the default sizing we use for all our viewports widths, except for the smallest (mobile) range and mobile apps. However, there can be exceptions on larger viewports that require container-based sizing.

Container-based

As the title suggests, a Button can also be sized to cover the entire containing element (using Fill container for the horizontal sizing in Figma). This is standard for our smallest (mobile) viewport range and mobile apps where sufficient touch target area's are important or when the small viewport requires Buttons to be vertically stacked.

However, as mentioned there are use cases on larger viewports as well. For instance, when the context requires vertically stacked Buttons, such as within a (small) containing content area like a Card, or a login form.

Alignment & positioning

Button content

We support different content alignment, which is especially important when you use container-based sizing. Make sure to be consistent with your choices and try to prevent using different kind of alignment per page/ view.

Buttons can also contain an optional icon (or even contain only an icon). A left icon has a different use cases than a right icon. Follow these guidelines to apply them correctly.

1	Label only (centered)
2	Left icon + label (centered). Note: does not work when multiple Buttons with icons are vertically stacked. In case of content-based sizing center or left alignment does not make a difference
3	Label + right icon
4	Left icon + label: when multiple Buttons with icons are vertically stacked

Page content

The position and order of Buttons on a page is often a topic of discussion (and confusion). In general, we apply the following rules in terms of positioning and order.

Full page designs should position the Button on the left side of the page, along with the page content, where the Primary Button comes first (far left). This is where your users' attention has been focused, while either reading or adding information to a form.

Note: there is one exception for the Button order — when a "back" (or "previous") and "next" action are displayed besides each other the order is "back" first and "next" last.

In small boxes like Modals or Dialogs, or other contained elements, Buttons are aligned from the bottom right, where the Primary Button comes first (far right). This could improve the flow, as the box "ends" with its conclusion. Also, you could argue that the primary action is the choice that moves the user forward, whereas the other one might move the user back or is the less-used option. This is often the case in modal windows, where the primary action serves like a "next" action and should be aligned right. This only applies to contained elements where the maximum width is limited.

Full width buttons (container based sizing) are vertically stacked, where the primary action comes first.

Button combinations

A combination of Buttons communicates a hierarchie of actions.

Primary Button	Combine with a Tertiary Button when there are multiple actions. Combine with a Text Button when there should also be an alternative (but low emphasis) or a dismissal/ cancel action
Secondary Button	Just like a Primary Button, combine it with a Tertiary or Text Button.
Tertiary Button	Combine with a Primary or Secondary Button.
Text Button	Combine with a Primary or Secondary Button. Do not use in isolation.

How to apply icons

Icons can be used in all Button variants if this has an additional value to the user interaction. Fore more generic or familiar kind of actions it can provide instant recognition about the kind of action or interaction it triggers. For example when the action is to search, save, download, print, add or moving forward or backwards. A button could also have an icon only, without accompanying label. However, this should be carefully applied and only works for some cases. Read more about it on our Icons page.

There is a difference between a left and right icon. A left icon adds more weight to the label and is a visual representation of the action. A right icon represents the kind of interaction the Button triggers, like going to the next step or loading (more) content on the page.

The color of the icon must be the same as the Button label and icons are consistently displayed at 24 x 24px (bounding box).

Icon Buttons

Buttons without labels should be used sparingly. However, there are instances where pattern familiarity and the icon alone convey enough meaning. For example, a close button, previous and next arrows, or a magnifying glass that represents search.

When icons are used without labels then they need to be clear to understand. Abstract icons need to be learned and add extra cognitive burden on our users.

Icon-only buttons need to include an accessible name for some assistive tech users, such as visually impaired users, to understand the purpose. Communicate this information to the developer.

Disabled Buttons

Disabled buttons often create accessibility issues and general usability concerns, so we do not promote the use of disabled buttons in Aero. Common concerns are:

Weak contrast. Disabled states do not need to meet the WCAG contrast guidelines, but buttons with weak contrast are not easy to perceive before completing tasks to enable them.

Screen reader navigation. In testing, disabled buttons may be missed by some screen reader users. This pattern is especially problematic when interacting with long forms.

Feedback. Often, disabled buttons do not give any feedback after interacting with them.

Unnecessary friction. These states add friction. In the case of a long form, a visitor may need to go back through the form to find a missed field before the button becomes enabled.

Instead of disabling buttons, all buttons should appear visibly enabled, and an error shown in the instances that an action needs to have been performed before submission. For example:

Checkbox. If a checkbox needs to have been checked before submission, then an error should appear to show this.

Form fields. If a form field has been filled in incorrectly, or a required field has been missed, then an error message should appear to show this.

Content

Button copy should include, and in most cases start with, a strong active verb to show that the button represents an action the user is taking. They should always be written in sentence case and clearly describe the action. In some cases, that might mean that you need to use more words. For example: ‘Add passenger’ and ‘Submit refund request’ are clearer than ‘Add’ and ‘Submit’, and focus on what the user is actually doing. Remember to keep it concise, as buttons should not exceed 30 characters and should be on one line only. Do not use punctuation marks or emojis.

Try to avoid using first-person pronouns, such as ‘my’. For example: ‘Cancel my booking’ should be ‘Cancel booking’, and ‘I want to log in’ should simply be ‘Log in’. If you must, keep in mind that the user should be the first person. Do not use ‘your’ or ‘our’ for example, as the user is taking the action.

If you use a verb in the title or body copy, make sure to use that same verb in the button copy. Examples of our standard buttons are:

‘Continue’ when the button takes the user to the next step in a multi-step process

‘Sign up’ to create an account

‘Log in’ to log in to an existing account

‘Log out’ when a user is logged in to their account

‘Cancel’, usually as a secondary action to close a process

On full-page designs, the primary action should be on the left, except when using ‘Back’ and ‘Continue’ next to each other. In that case, the primary ‘Continue’ action will be on the right. In all other cases, such as dialog boxes, the primary action should also be on the right.

For details on Dutch verb usage, please see the Dutch editorial chart.

Buttons vs. Links

Buttons should not be confused with Links. The purpose of a Button is to trigger an action. The purpose of a Link is to take the user somewhere and are used as in-site navigation between pages. Be careful not to confuse these component with each other — especially a Text Button which looks very similar to a Link.