Version 5.1.1

Slider

Sliders allow users to quickly select a value within a range. They should be used when the upper and lower bounds to the range are invariable.

Anatomy#


Diagram of a Slider's anatomy, including label, track, handle, fill, and value.

Options#


Example of a Slider with a label.

Label#

Sliders should always have a label. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These sliders should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).

Examples showing both top and side label variants of Slider.

Label position#

Labels can be placed either on top or on the side. Top labels are the default and are recommended because they work better with long copy, localization, and responsive layouts. Side labels are most useful when vertical space is limited.

Example of Sider values with appended unit text.

Value and value unit#

The value is the number selected within the range of the slider. This can have a value unit appended to show the unit of measurement, such as "%" or "px".

Examples of Sliders with varying widths.

Width#

The width of a slider can be customized appropriately for its context.

Example of a Slider with a filled track.

Fill#

The track of the slider can have a fill. By default, the fill originates from the left side of the track.

Example of a Slider with the start point of the fill offset.

Fill start#

If the value represents an offset, the fill start can be set to represent the point of origin. This allows the slider fill to start from inside the track.

Example of a Slider with a gradient track fill.

Gradient#

A gradient can be added to the track of any slider to give more meaning to the range of values. Tracks with a gradient can also have a fill. A gradient track should not be used for choosing a precise color; use a color slider, color area, or color wheel instead.

Example of a Slider with an input field for setting precise values.

Editable#

In situations where users should be able to precisely input a value, the value can be editable within a text field.

Example of a disabled Slider.

Disabled#

A slider in a disabled state shows that an input exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that a slider may become available later.

Table of options#

From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.

PropertyValuesDefault Value
label
text / nothing
label position
top / side
top
value
number
0
value unit
text
width
number
has fill
yes / no
no
fill start
number
0
has gradient
yes / no
no
is editable
yes / no
no
is disabled
yes / no
no

Behaviors#


Slider showing size of 24, with handle in focus.

Keyboard focus#

A slider can be navigated using a keyboard. The keyboard focus state takes the slider’s visual hover state and adds a blue ring to the slider handle in focus.

Examples of Sliders with placement of the value following placement of the label.

Value placement#

The value follows the placement of the label: on top when the label is on top, and on the side when the label is on the side. There is an exception to this rule when the value is editable, shown within a text field (standard or quiet style); in this case, the editable input is always placed on the side. This editable input should be labelled using "aria-labelledby" or "aria-label" as well.

Example of a Slider with overflowing label text.

Text overflow#

When the label is too long for the available horizontal space, it wraps to form another line.

Usage guidelines#


Include a label#

Every slider should have a label. A slider without a label is ambiguous and not accessible.

Example of a correct Slider that includes a label.
Example of an incorrect Slider which has no label.

Review label-less designs#

In rare cases where context is sufficient and a label could be absent, make sure to have the design reviewed and approved by an accessibility expert. These should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).

Example of a Slider without a label that passed inclusivity review as an exception.

Allow a hot text option when needed#

In addition to dragging the handle, sliders can provide more ways to change the value (known as “hot text”) either by clicking on the value text and dragging up/down, or by scrolling up/down while hovering over the value text.

Example of a Slider with hot text enabled.

Show value units to help provide context#

Slider values can be shown with a unit when it helps provide context (e.g., “%” or “px”). When the value is shown within a text field, the unit disappears on focus.

Example of a Slider with units included for context.
Example of a confusing Slider that does not include units for context.

Prefix positive/negative values#

If the value ranges from negative to positive, prefix the value with a plus (+) or minus (-) sign. When the sign is shown within a text field, it remains visible on focus. When the sign is shown outside the text field, there should be a space between the sign and the numerical value for readability.

Examples of Sliders with correct implementation of positive and negative prefixes.
Example of poorly implemented Sliders that are missing positive and negative prefixes.

Internationalization#


Example of Sliders in RTL configuration with mirrored layout.

RTL#

For RTL (right-to-left) languages, the layout of the slider is mirrored. The label is right-aligned, the value is left-aligned, and the fill progresses from right to left. Keep in mind that the placement of the percent sign differs depending on the locale.

Keyboard interactions#


KEYINTERACTION
Up or Right ArrowIncreases the value
Down or Left ArrowDecreases the value

Changelog#


DateNumberNotes
Apr 13, 20205.1.1
  • Updated keyboard focus state to be more accessible
Aug 22, 20195.1.0
  • Added text overflow behavior
Apr 20, 20195.0.0
  • This component is now individually versioned (individual versions of existing components start at 5.0.0)
  • Added RTL (right-to-left) guidelines

Design checklist#


All interactive states

Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).

Multiple options

Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)

All color themes

Works properly across all four color themes (lightest, light, dark, darkest).

All platform scales

Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).

Defined behaviors

Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.

Usage guidelines

Includes a list of dos and don’ts that highlight best practices and common mistakes.

Accessible contrast

Follows WCAG 2.0 standards for contrast (AA).

Internationalization guidelines

Works properly across various locales and includes guidelines for bi-directionality (RTL).

Keyboard interactions

Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.

Design tokens

All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.

Generated UI kit

Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.