Slider error validation

[thefirstartist]

Slider validation

In Slider component, if I enter a number greater than the max number, I get a red border around the text field but the number remained in the field.

I think the component shouldn't allow users to keep the numbers greater than the max number. It should change the number to the max number (100) if user's data is higher than the max number, or add a validation text below the slider describing the issue with the users data.

[jnm2377]

Thanks for opening this issue. It seems we never created an invalid design for this component when it was first built, and there's some work we need to do around that. Adding this to our backlog.

[aagonzales]

Some quick possible explorations but this will need some more work

[thefirstartist]

Thanks for the quick explorations, Anna. We have a settings page that has multiple number inputs and sliders for the user to modify, the current behavior is that any change that the user does is auto saved/applied without the user having to click on any “Save” button. Is it possible to automatically change the number to the max value and inform the user with the validation text like "The max value is 100"?

[aagonzales]

Is it possible to automatically change the number to the max value and inform the user with the validation text like "The max value is 100"?

I don't know if that's is technically possible in the existing slider, that a question for @carbon-design-system/developers .

But from a UX perspective I think that makes sense to auto-correct both the slider and the input to highest or lowest value and adding a warning (not a error) to the slider informing the user. It makes sense that we wouldn't let the user input a value outside of the range.

The input in slider is there for accessibility reasons and not so that users can enter custom values outside of the range.

[thefirstartist]

@aagonzales Hi Anna, I think the warning icon might not be necessary in the text field. Since it has been auto-corrected, the number itself is valid. Having the warning icon could be misleading. Also, we are thinking that instead of using "Warning, the value....", maybe we should use an informational banner. In most cases it is merely a typo that user makes and an informational message might be more friendly.

[TheSharpieOne]

It previously did what you are asking (prevented invalid input), but that was a horrible UX and was considered a bug that was fixed (see carbon-design-system/carbon#8842) If it is decided to reimplement this feature, then the validation and auto-correction should probably happen on blur to avoid the issue described in carbon-design-system/carbon#8842 But even with blur, what happens when the user is focused on the field uses enter to submit the form? Does it automatically correct before submitting (without the user having time to notice it auto-corrected)? or does it submit the invalid value?

Probably shouldn't reinvent the wheel here. Pop a validation message and let the user decide the best course of action. By doing that, the field stays invalid and should prevent forms from submitting.

[thefirstartist]

@TheSharpieOne

1. Yes, the auto-correction should happen on blur. Users can type whatever they want but should be corrected to the min/max number allowed.
2. In the case that users hit enter to submit the form while still focus on the field, we should give them a modal informing them that the invalid value would be corrected and they can decide either "Submit" or "Cancel." The invalid value should not be submitted.

[tay1orjones]

There's some additional accessibility detail provided by @mbgower in https://github.com/carbon-design-system/carbon/issues/9772 - I marked it as a duplicate and closed it in favor of this issue due to the additional info potential solutions being discussed above.

[tay1orjones]

@mbgower could you weigh in on some appropriate solutions we might explore to improve this?

I'm not sure if this would technically fail 3.3.1 Error Identification and/or 3.3.3 Error Suggestion

[tay1orjones]

Probably shouldn't reinvent the wheel here. Pop a validation message and let the user decide the best course of action. By doing that, the field stays invalid and should prevent forms from submitting.

I agree. I don't believe auto-correction is something to include within the component. This can already be achieved by using the onBlur handler to implement your own custom error handling validation. Additionally there is now a onInputKeyUp prop that can also be used for custom validation if you prefer, https://github.com/carbon-design-system/carbon/pull/11230

I think a reasonable improvement here would be to add an error icon to the input and provide optional helpText. Something akin to this suggestion from @aagonzales - I'm not sure if we'd need the actual slider track and handle to be red though.

[thefirstartist]

@tay1orjones As I mentioned, we have a settings page that value will be auto saved/applied without clicking on any “Save” button. Keeping the invalid value in the text field triggers error modals. I think the better UX approach will be

1. Auto-correct on blur. The data should be changed to the max value 100 when the focus moved to next interactive item. The error icon inside the field is not necessary because 100 is a corrected value and no longer an error.
2. The validation message below the slider should state what is allowed. For example: "Enter a value between 0 and 100."
3. There's nothing wrong with the slider so it should be black, not red.

[jdharvey-ibm]

@thefirstartist Auto-correction on blur would constitute an assumption made by the Carbon team of how a general purpose component is used in certain applications, but not all applications. That is not a decision the Carbon team themselves should make.

It's also very hard for a visually impaired user using a screen reader to become aware that a previously entered value has now been altered (and potentially persisted on a server someplace) as a result of them browsing away from the field in question without modifying it.

The error suggestion laid out by @tay1orjones (and @aagonzales) is transparent, informative, and assumption-less. It assumes you know your data better than anyone else, and it will not self-modify unless you tell it to do so.

I worked on a team where they have a similar settings page with auto-saving like you described, but they rely on the fact that the form components will not be auto-updated in the absence of user action. A change to that effect would "break" their use case.

[thefirstartist]

@jdharvey-ibm

1. We are not suggesting using auto-correction for all components. For this particular component, users should know the max value already. The mistake is most likely a typo and auto-correction is helpful for users. Perhaps Carbon should provide the auto-correct option so product teams can choose what works for them.
2. Screen reader users will be informed when the entry was auto-corrected and the validation text was announced. Auto-correction is going to be a big help to them and reduces the need to deal with warning modals when saving the form.
3. If we allow "180" in the text field, then the slider should show from 0 to 180. If the slider only allow up to 100, there's no reason keeping the typo in the text field and ask them to correct it later.
4. What we have right now is not auto-update either because of the lack of auto-correction in the slider component. When users try to navigate away from the form, they would be warned with a modal asking them to correct. This is especially bad for screen-reader users.

[tay1orjones]

Perhaps Carbon should provide the auto-correct option so product teams can choose what works for them.

@thefirstartist This option, plus any other type of validation or constraint logic, can already be implemented with the component as it stands today via the onBlur prop. Here's an example.

https://user-images.githubusercontent.com/3360588/186974232-3dd68b35-a3de-4155-88a9-b3e35bbdac97.mov

I agree the piece lacking here is as you stated,

The validation message below the slider should state what is allowed.

We need to add helperText and potentially a non-color-only change to the input, such as adding an error icon.

[mbgower]

I definitely think if you're going to autocorrect, you need to inform the user. As @jdharvey-ibm states, auto correcting 111 down to 100 is a huge mistake if the user intended to enter 11. If you make that change without informing the user, that could happen. Taylor's vid seems to address that.

I also think the autocorrect approach ignores the reality that other values could also be input that are errors. For example, with a step of 10 set, Carbon currently (unfortunately) will error out an entered value of 55. The solution for dealing with 'incorrect' entries has to be elastic enough to be consistent in different scenarios.

[thefirstartist]

@mbgower Yes, if we are going to autocorrect, we definitely need to inform the user. I agree that it's a mistake autocorrecting 111 down to 100 if the user intended to enter 111. However, I can't think of a case that user would want to enter 111 while the slider clearly stating that the maximum is 100 and keep getting warning message (either inline notification or modal) when the field is onBlur.

[mbgower]

@thefirstartist I said "11" not "111". Trying to point out that the assumption the number entered was intentional and not a mistype may not be valid.