Range slider input

How to test a range slider input

Gherkin Condensed WCAG

Given that I am on a page with a range slider input

1 Keyboard for mobile & desktop

WHEN I use the tab key to move focus to a range slider I SEE focus is strongly visually indicated
Then when I use the up/down/left/right arrow keys I SEE the value is changed one step

2 Desktop screenreader

WHEN I use a desktop screenreader (NVDA, JAWS, VoiceOver) AND I use the tab key to move focus to a range slider
- I HEAR Its purpose is clear
- I HEAR It identifies itself as a range
- I HEAR Its label is read with the input
- I HEAR Its current value
Then when I use the up/down/left/right arrow keys I HEAR the value is changed one step

3 Mobile screenreader

WHEN I use a mobile screenreader (Talkback, VoiceOver) AND I swipe to move focus to a range slider
- I HEAR Its purpose is clear
- I HEAR It identifies itself as a range
- I HEAR Its label is read with the input
- I HEAR Its current value
Then when I swipe up/down in iOS or use the volume buttons in Android I HEAR the value is changed one step

1 Keyboard & screen reader actions

When I use	I see/hear
Tab	Focus moves visibly to the input
Arrow-keys	Increase / decrease value one step

2 Mobile screenreader gestures

When I use	I hear
Swipe	Focus moves to the input
Swipe up/down	Increase/decrease slider value one step on iOS
Volume	Increase/decrease slider value one step on Android

3 Screenreader output for all devices

Reads	I hear
Name	Its purpose is clear
Role	It identifies itself as a range
Group	Its label is read with the input
State	Its current value

A range slider input must meet these WCAG principles.

1Perceivable

Is easy to identify as interactive
Color is not used as the only means of conveying information

2Operable

Is keyboard operable
The click/tap target area is no smaller than 44x44px
The disabled and focus states have a 3:1 minimum contrast ratio against default
The focus indication has a 3:1 minimum contrast ratio against adjacent elements
The focus indication has a minimum area equal to the width of the element and 2px in height

3Understandable

Its purpose is clear in the context of the whole page

4Robust

Conveys the correct semantic role
Expresses its state
Meets criteria across platforms, devices and viewports

Code examples

This is one of the exceedingly rare instances where a custom element makes a lot of sense.

Use a custom element

Custom elements are easier to style reliably across browsers.
Working slider pattern examples

<div id="range-label">
  How much cowbell?
</div>
<div class="track">
  <div id="thumb"
       role="slider"
       tabindex="0"
       aria-valuemin="0"
       aria-valuenow="10"
       aria-valuemax="11"
       aria-labelledby="range-label">
  </div>
</div>

Semantic HTML

While there is a native range input, it is difficult to style reliably across browsers.

<div class="range-group">
  <!-- Input hidden from the screen reader 
    and keyboard to avoid repetition -->
  <input tabindex="-1" 
          value="10" 
          aria-hidden="true"
          class="range-value" 
          id="cowbell-range-value">
  <div>
    <label for="cowbell-range">
      How much cowbell?
    </label>
    <input type="range"
      id="cowbell-range"
      name="cowbell"
      min="0"
      max="11"
      value="10"
      step="1">
  </div>
</div>

How much cowbell?