Range slider input - Web accessibility testing checklist

How to test a range slider input

Gherkin Condensed

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

1 Keyboard

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 screenreader 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

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 WCAG principles:

1 Perceivable

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

2 Operable

Is keyboard operable
The purpose of can be determined from the text alone - 2.4.4 A
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

3 Understandable

Its purpose is clear in the context of the whole page

4 Robust

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?

Web Range slider input