Docs

Documentation versions (currently viewingVaadin 25 (prerelease))

Button

The Button component allows users to perform actions. It comes in several different style variants and supports icons, as well as text labels.

The Button component allows users to perform actions. It comes in several different style variants and supports icons as well as text labels.

Source code
ButtonBasic.java
button-basic.tsx
button-basic.ts

Buttons with Icons

Buttons can have icons instead of text, or they can have icons along with text.

Source code
ButtonIcons.java
button-icons.tsx
button-icons.ts

Use icons sparingly. Most actions are difficult to represent reliably with icons. The benefit of icons plus text should be weighed against the visual clutter they create.

Icon-only buttons should be used primarily for common recurring actions with highly standardized, universally understood icons (e.g., a cross for close), and for actions that are repeated, such as in lists and tables. They should also include a textual alternative for screen readers using the aria-label attribute (see the first two buttons in the previous example).

Additionally, tooltips can be added to provide a description of the action that the button triggers (see the Close button in the previous example).

Note
Icon-Only Button Style Variant
Use the icon / LUMO_ICON style variant on icon-only buttons to reduce the white space on either side of the icon. The Flow Button component automatically applies the icon variant if the icon is the only child of the component.

Buttons with Images

Images on buttons can be used like icons. See the icon usage recommendations for more information.

Source code
ButtonImages.java
button-images.tsx
button-images.ts

Disabled

Buttons representing actions that aren’t currently available to the user should be either hidden or disabled. A disabled button is rendered as "dimmed".

Source code
ButtonDisabled.java
button-disabled.tsx
button-disabled.ts

Focus & Hover

By default, disabled buttons are not focusable and cannot react to hover events. This can cause accessibility issues by making them entirely invisible to assistive technologies, and prevents the use of Tooltips to explain why the action is not available. This can be addressed by enabling the feature flag accessibleDisabledButtons, which allows you to focus and hover on disabled buttons, while preventing them from being triggered:

Source code
Flow
# Add this line to src/main/resources/vaadin-featureflags.properties
com.vaadin.experimental.accessibleDisabledButtons=true
Lit & React

Alternatives to Disabling

The most obvious alternative to disabling a button is to hide it. This reduces UI clutter, but can cause confusion since the user won’t know where to watch for the button once the action it represents becomes available. There’s also a risk of undesired layout shifts in the UI when the button appears.

Another option is to keep the button visible and enabled, but show an error, e.g. using a Notification, when it’s clicked. This option is best combined with some custom styling of the button to give the user a hint that the action is unavailable.

Prevent Multiple Clicks

Buttons can be configured to be disabled when clicked. This can be useful especially for actions that take a bit longer to perform. Not only does this avoid the need for special handling of additional clicks while the action is in progress, but it also communicates to the user that the action was received successfully and is being processed.

Source code
ButtonDisableLongAction.java
button-disable-long-action.tsx
button-disable-long-action.ts

Focus

As with other components, the focus ring is only rendered when the button is focused by keyboard or programmatically.

Source code
button-focus.tsx
button-focus.ts

Auto Focus

Buttons can receive keyboard focus automatically when the UI in which they appear is rendered.

Source code
Java
Button button = new Button("Button");
button.setAutofocus(true);
Java
HTML
HTML
HTML
HTML

Keyboard Usage

A focused button can be triggered with Enter or Space.

Best Practices

Below are some best practice recommendations related to buttons and their labels.

Button Labels

A label should describe the action, preferably using active verbs, such as "View Details" rather than "Details". To avoid ambiguity, also specify the object of the verb, such as "Save Changes" instead of "Save". They also should be brief, ideally less than three words or twenty-five characters.

Button groups representing options, such as the buttons of a Confirm Dialog, should state what each option represents (e.g., "Save Changes"). Don’t label a button "Yes" since that requires the user to read the question being asked. It’ll increase the risk of selecting the wrong option.

Use ellipsis (i.e., …) when an action is not immediate, but requires more steps to complete. This is useful, for example, for destructive actions like "Delete…​" when a Confirm Dialog is used to confirm the action before it’s executed.

ARIA Labels

The aria-label attribute can be used to provide a separate label for accessibility technologies (AT), such as screen readers. This is important, for example, for icon-only buttons that lack a visible label.

A button with a regular, visible label can also benefit from a separate aria-label to provide more context that may otherwise be difficult for an AT user to perceive. In the example here, each button’s aria-label specifies which email address is removed:

Source code
ButtonLabels.java
button-labels.tsx
button-labels.ts

Buttons in Forms

Buttons in forms should be placed below the form with which they’re associated. They should be aligned left, with the primary action first, followed by other actions, in order of importance.

Source code
ButtonForm.java
button-form.tsx
button-form.ts

Buttons in Dialogs

Buttons in dialogs should be placed at the bottom of the dialog and aligned right. Primary action should be last, preceded by other actions. Dangerous actions should be aligned left, to avoid accidental clicks, especially if no confirmation step is included.

Source code
ButtonDialog.java
button-dialog.tsx
button-dialog.ts

Global vs. Selection-Specific Actions

In lists of selectable items — such as in a Grid — that provide actions applicable to the selected item, buttons for selection-specific actions should be placed apart from global actions that aren’t selection-specific. They should be located below the list of selectable items.

In the example below, the global Add User action is separated from the selection-specific actions below the Grid:

Source code
ButtonGrid.java
button-grid.tsx
button-grid.ts
Component Usage Recommendation

Anchor

Use anchor elements instead of buttons for navigation links.

Menu Bar

Overlay menus with items that trigger actions. This can also be used for single "menu buttons" and "button groups" without overlay menus.

8E1BE28B-D5F0-490C-A8FA-82975D9A3B43