Gutenberg: RangeControl: Audit for usability and accessibility improvements

[sarahmonster]

Discussion of #13363 lead the accessibility team to raise some concerns about the accessibility of the RangeControl component:

Without "stop" indicators, it doesn't even communicate the "range" of options available (what's the minimum? what's the maximum?). Yeah, this does not really add anything except a visually pleasing control for users to "play" with. An input is much simpler and safe solution. I think design should explain what the rational is behind using a range slider? Do they have testing data to support better engagement with that control type vs an input?

More context & discussion in Slack here: https://wordpress.slack.com/archives/C02RP4X03/p1550246235055200%EF%BB%BF

See also #12433, #12432, #4420, #12430, and especially #12429. Given that there are a number of different improvements suggested for this component, it might be a good time to consider redesigning this component so as to ensure it's as usable and accessible for as many users as possible, as well as defining clear guidelines for its usage.

Let's discuss!

[joedolson]

In general, I find range sliders have limited use when the desired result is a definite value, or when there are very few available options. If I was manipulating something like a volume control, where hitting a value of 37 or 38 was essentially an insignificant difference, and there are a large number of values to pass through such that incrementing is tedious, I can see that as valuable.

However, when I know that I want a definitely value (e.g. 3 columns), I'm happier just typing in a 3. The slider requires me to explore the available values before I can identify anything, and this isn't a situation where exploring values is useful to me.

This isn't to say that a range control can't be useful, but I think that there needs to be more consideration whether the control is a good choice for the situations it's used in.

[grahamarmfield]

To me this feels a little over-engineered. Wouldn't a <select> element or a radio button group achieve the same result more simply?

There are accessibility concerns also over the range control. I'm not certain it's supported widely enough in iOS with Voiceover to be used in an accessible way.

[bemdesign-er]

As joedolson noted, a range slider can work well when there is a large range to select from and where precision is not required. But in cases where the range is limited and/or precision is required, a normal input field would be a better choice. A normal input field also simplifies the UI/UX and provides the added accessibility bonus of being better supported. Or even a "number" field.

So looking at what this particular control is trying to do, I think a range slider is not the best solution here.

[gregbia]

Despite the use case, I think the reset behavior should be corrected. On reset, the range value should be either the initial position or empty. It is causing usability confusion in many use cases, if the value remains the same and only the range "indicator dot/circle" on the slider moves.

Example 1: I have a range from 1 to 6. My initial position is 3. I set the range to 5. On reset, the range indicator moves back to 3 (which is ok) but the value remains 3. That is confusing to the user.

Example 2: I have no initial position. I set the range to 5. On reset, the range indicator moves to the center (which is ok) but the value remains 3 instead of going blank. Is is again confusing, unfortunately..

[davewhitley]

However, when I know that I want a definitely value (e.g. 3 columns), I'm happier just typing in a 3. The slider requires me to explore the available values before I can identify anything, and this isn't a situation where exploring values is useful to me.

@joedolson — Another perspective is something in between the volume control example and what you describe above. There are moments when one might want to explore values, but the number of values is limited. For example, when making an image gallery, I'm not sure how many columns I'll want until I explore the options. It would be very tedious to type in a number, backspace, type number, backspace, etc. The number input type is helpful but those up/down buttons are often tiny. Using a range slider to explore the options and immediately seeing the changes in the editor is the best experience in that case (assuming there are 4+ column options).

[aduth]

The default browser treatment of a number input with min and max attributes assigned does not indicate that range in any way to the user. If I see a field with 2 as the current value, I can have no sense from that what the minimum or maximum is.

While it's not very clear in its current incarnation, in theory if a slider was restricted to values 1 to 40 and the thumb button was about half-way with a value of 20, I could reasonably extrapolate a maximum of 40. This doesn't apply so well to something like the Columns slider, which is 2-6 ("half-way" is actually 4, but the max is 6, not 8). Displaying the minimum and maximum at the ends of the range could make this clearer. Unsure if there's some precedent for how these ranges can be communicated for number inputs.

[enriquesanchez]

While this may only work for the columns block, I think that instead of using a range slider we can do something like this:

It's a stepped "slider" that visually represents the columns. It provides a min and max value, it indicates the current selected value, and also allows for exploration.

I imagine a component like this can be implemented with radio buttons to maintain usability and accessibility.

[afercia]

Worth noting the Range Control should be evaluated also in the context of the specific functionality it's used for. Sometimes, some UI patterns are just not efficient for the underlying functionality.

For example, I was just testing the RSS block and noticed that, when changing the number of items, an API request happens at each, single, value change in the range control:

While in this specific case the RSS feed is probably cached and the API request is very light, in other cases the Range Control might hammer the server with heavy API requests.

For example, the Range Control in the Latest Posts block settings produces some more serious consequences. On current master, this block has a setting to display the full post content. When it's enabled, the Range Control triggers an API request at each change in the Range Control. The request is pretty heavy since _it includes the whole post content_. Also, just imagine a website with long form posts where each single post might be made of thousands of words for more than 1 megabyte (counting only the post text).

This is the equivalent of hammering the server with potentially dozens of continuous requests in a row. See screenshot below:

Beside the usability and accessibility concerns, I'd tend to think the Range Control should be used (if any) only for "UI" settings and _never_ for settings that trigger API requests.

[afercia]

Food for thoughts, link shared by @bemdesign-er on Slack:

https://designsystem.digital.gov/components/form-controls/#range

The Range slider is meant to choose an approximate number from a range.

When to use the range slider component?

When the range is more important than precision.
For instance, it could be more important for a target price selector to communicate where the target price falls within a certain range than the precise dollar amount selected.

When a relative value is more important than an exact value.
For instance, a volume slider is typically more focussed on the relative loudness of the output rather than the specific decibel level.

When to consider something else
Use a regular text input if a user needs to enter a precise number.

designsystem.digital.gov is the home of

United States Web Design System is an active open source community of government engineers, content specialists, and designers. Our contributors both in and out of government support dozens of agencies and nearly 200 sites.

Besides the accessibility concerns, I'd totally second these usage recommendations. For example, I don't think a Range slider is appropriate to select the number of columns of the gallery.

One more important reference:

Nielsen Norman Group
Slider Design: Rules of Thumb
https://www.nngroup.com/articles/gui-slider-controls/

[davewhitley]

I agree that a slider is best used to choose an approximate number from a range.

I agree that when the range is limited and an exact value is important, then another UI pattern might be a better choice.

I don't agree that using a text input is always the best option for selecting an exact value for reasons already noted above in previous comments (can't easily see min/max and tedious for mouse users)

@joedolson:

However, when I know that I want a definitely value (e.g. 3 columns), I'm happier just typing in a 3. The slider requires me to explore the available values before I can identify anything, and this isn't a situation where exploring values is useful to me.

I'm interested to hear if there are disadvantages with the slider + text input approach _in general_. I I don't think it's required that you use the slider in that scenario, and the user has the option to use the text input.

I agree that for 3 values, using a slider is not ideal. We should do something similar to what @enriquesanchez proposed earlier. Although, for anything ~4 and above I find the slider very helpful when it causes a visual change in the editor or in the UI it's affecting. So for this specific case (adjust columns), I personally find the sliders wonderful to use, because they allow me to simply click/drag and quickly see all the result of all the values for that setting.

[karmatosed]

Closing this as now iterating in new issue to tackle issues from ground up. #19845 for reference.