Skip to main content
BUTTONS

Sliding button

Draft

Sliding buttons are a variation of the standard primary button. By requiring a different gesture to confirm an action, they help reduce accidental taps and reinforce user intent.

Confirm request
Premium
4 min away
→
Confirm Premium

Common alternative names

Swipe button, draggable button

Anatomy​

A sliding button consists of a draggable handle with a predefined icon and a base track with a customisable label. All of the elements below are required.

→
Slide to {action}
Icon
(Required)
Label
(Required)
Sliding button
(Required)
Base
(Required)

Iconography​

Sliding buttons use a single forward arrow icon to convey a clear interaction affordance and maintain consistency across experiences. The component does not support custom icons.

→

Usage​

Use sliding buttons to let users take important actions. They should be used as the last step in a multi-step flow (like confirming a request or completing a transaction) or to introduce friction to confirm a user's intent and prevent accidental button taps (like initiating an emergency call).

Use cases​

Confirm request
Premium · $9.80
→
Confirm Premium
Prevent accidental action

Sliding buttons introduce intentional friction in flows with a prominent primary action. The differentiated interaction pattern helps prevent accidental taps.

Emergency assistance
Your trip details will be shared automatically.
→
Slide to call 911
Confirm intent on costly or irreversible actions

Users must take deliberate, intentional steps to confirm their intent before triggering a costly or non-reversible action like making a payment or initiating an emergency call.

Caution
If the action is not critical, a sliding button may be unnecessary and may add unnecessary complexity to the interface. Use a standard Button instead.

Mobile environments only​

Using a swipe interaction as an action gesture feels natural in a mobile environment.

We discourage using sliding buttons in desktop environments. Trying to complete the task with a mouse or trackpad feels unnatural and is not a widely adopted pattern. Use a standard confirmation dialog or button on desktop.

Behavior​

Users drag on the arrow affordance along the track. Once the arrow reaches a threshold, the sliding button's action is triggered.

States​

StateDescription
PreloadingAn interim state when the component content is loading. Uses a placeholder skeleton.
EnabledHandle rests at the start of the track. Label is visible. The component is ready for interaction.
FocusText and icons use inverse primary. Container uses inverse primary. Outline: 3px focus border using borderAccent.
On dragWhile the handle is being dragged, the label text transitions to a contentStateDisabled fill to indicate the action is in progress.
LoadingA spinner replaces the label and the arrow affordance is removed. Used after the threshold is reached while the action is being processed.
DisabledText and icons use contentStateDisabled. Container uses backgroundStateDisabled. The handle cannot be dragged.

Slide affordance​

The handle's arrow icon is the sole draggable element. On tap, the handle grows by 16px to provide a visual cue that the affordance has been engaged. The user then drags it across the track toward the trailing end.

→
Slide to {action}
Enabled
→
Slide to {action}
On tap, handle grows by 16px

Auto-complete thresholds​

Users can slide the button to complete an action upon passing a threshold. Two threshold levels are provided to support different user types.

Demanding a high degree of interaction precision to complete an action proves difficult to users with physical and motor disabilities, as well as seniors. When choosing which threshold to use, think about who your users are and whether they would find it difficult to interact with the component in the "Hard" slide mode.

ThresholdValue
Low (Easy)Complete more than 20%
High (Hard)Complete more than 80%

Low threshold (Easy)​

When the handle position exceeds 20% of the base width (slidingButton.x > 0.2 * base.width), the action auto-completes. Suitable for non-destructive confirmations where speed and accessibility matter.

High threshold (Hard)​

When the handle position exceeds 80% of the base width (slidingButton.x > 0.8 * base.width), the action auto-completes. Use this for destructive or high-stakes actions where accidental confirmation must be minimised.

Haptics​

(iOS)

EventHaptic patternDescription
FailureFailure (native)On failure, play a Failure haptic pattern after resetting the state of the button.
On touch downSingle nudgeOn touch down, play a single haptic nudge to confirm the affordance has been engaged.
SuccessSuccess (native)On success, play a Success haptic pattern to reinforce the request has been successfully submitted.

Breakpoints​

Sliding buttons should follow the same breakpoint rules defined in the Button documentation: full-width on mobile. This component is not recommended for desktop layouts.

Overrides​

Color​

Background colour customisations of the sliding button are supported but should stick to using primary, high-contrast colours like: InverseBackgroundPrimary, backgroundAccent, backgroundNegative, and backgroundPositive. Ensure your text and icon colours work on top of your chosen background. Ensure your custom background colour is tokenised so it flips in dark mode.

→
Slide to {action}
→
Slide to {action}
→
Slide to {action}
→
Slide to confirm
✓ Do

Distinguish the swipe affordance from the surrounding UI by using a primary, high-contrast background.

→
Slide to confirm
✕ Don't

Don't invert the button styles or use secondary styling on the swipe affordance.

Size​

Avoid resizing elements inside the button, like the icon or sliding button affordance. Try going up or down in size for the entire button instead.

Slide to confirm
Cancel
✓ Do

Keep the sliding button height and the base button height the same.

Slide to confirm
✕ Don't

Don't enlarge or shrink either part of the sliding button.

Examples​

→
Slide to confirm
Default
→
Slide to delete
Danger