[a11y]: Slider step size incrementation creating false negative most likely to be experienced by keyboard user

Package

carbon-components-react

Browser

Chrome

Operating System

MacOS

Package version

whichever one is currently live on carbondesignsystem.com

Automated testing tool and ruleset

keyboard use

Assistive technology

This issue will be encountered by anyone attempting to enter a value into the slider’s text input . Keyboard-dependent users are the most likely group

Description

There is an internal discussion that provides more background. I will quickly summarize here:

The step size increment should not be used as a means of disallowing inputs within the range of the slider. This leads users to encounter errors which make no sense, due to input rules that are not exposed to the user. i also think the error messages do not address the underlying problem. It disproportionately penalizes users who cannot operate a slider or prefer to use the text input.

A slider showing an allowed range of 0-100, but an entry of 55 is showing as an error

• A slider has a visible range, by default 0-100.
• A slider’s value can be set throughout this range by moving the slider or by entering a value directly into the input
• There is an ability in Carbon for an implementer to set a “step size increment” which determines what each increment on the thumb slider will do to the set value (e.g., if the slider has a step size of 10, the slider will move from 0 to 10, then to 20, etc)
• This step size is not displayed in the UI and will never be detected by someone who enters a value in the input

I think there could also be an interesting design discussion on the purpose of the step size increment. Regardless of the range displayed, if the slider is always the same physical length, then there is no more or less effort for a pointer user to adjust the value. So I would assert that the underlying reason for the step increment was to support better keyboard interaction, and that it only need to be factored into the ability for the user to move both by 1s (using the arrow keys) and by the step increment (in Carbon, achieved with Shift+arrow)

IMO, the simple solution to this is to disallow changes of the step (or at the least, to not allow them unless the instructions and errors support that usage), and have a default stepMultiplier of 10.

WCAG 2.1 Violation

3.3.1, 3.3.2, 3.3.3

CodeSandbox example

https://www.carbondesignsystem.com/components/slider/code

Steps to reproduce

1. using the code sample, https://www.carbondesignsystem.com/components/slider/code, change the step value from 1 to 10
2. put the focus on the slider then tab to the text input and enter a range of 55
3. tab off the input. the input will now be in an error state

The visible range allowed is 0-100. 55 is clearly in that range. So there are multiple problems here:

1. The value should be allowed by all labelling and instructions visible
2. There is no error message describing the problem (already opened with https://github.com/carbon-design-system/carbon/issues/9772)
3. The error relies on color (already opened with https://github.com/carbon-design-system/carbon/issues/9772)

Looking at the code, it seems that the step value is currently used to determine the increments in the slider, and the stepMultiplier is used to determine what happens when a keyboard user presses Shift+arrow to increment the slider (i.e., Shift+arrow will cause the slider to move by 40).

<Slider
  ariaLabelInput="Label for slider value"
  id="slider"
  labelText="Slider label"
  max={100}
  min={0}
  step={10}
  stepMultiplier={4}
  value={50}
/>

Code of Conduct

• I agree to follow this project’s Code of Conduct
• I checked the current issues for duplicate problems

[tay1orjones]

It (step) should have NO effect on the allowed values entered in the input field.

This directly conflicts with the html spec for step unfortunately. It has to remain configurable for situations where the desired step is greater than 1 or a float, like 1.5 for instance.

I very much agree though that this step requirement is very confusing because it’s not visually explained anywhere. MDN talks about this briefly in the article for step

In lieu of locking step or changing it’s behavior, we can update the storybook examples to provide a more descriptive label like

Slider (must be an increment of 5)

Also we can update storybook/docs for step to indicate that anytime a step is configured, a descriptive label must communicate the step requirement

[mbgower]

That sounds like an okay approach. I want to re-emphasize that this is only an issue where an actual input is provided. When there is slider-only value setting, a warning/notice on input restrictions isn’t really necessary. The user has no choice 😃

In some ways, Carbon’s implementation of a slider+input has inadvertently caused this. Intended to improve accessibility, but could have opposite effect. 😃