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?