Addressing Slider Update Concerns

[jscholes]

Thanks to everyone who joined the April 6 call and worked through the concerns raised by the updated thermostat example (PR #1755). The concerns with the current approach are hopefully well-documented there and in the meeting minutes, so I won't rehash them here but happy to answer questions.

After explaining those concerns, the group felt that the current "Fan" slider is a bit of an antipattern. It has four labelled, mutually exclusive values, and a user cannot choose anything between them (e.g. "low and a half" is just not a value that makes sense). A radio group would be a better choice.

The concern, then, is how the APG should explain and demonstrate the difference between sliders and radio groups, and help decide when one is more appropriate than another. Several routes forward were proposed (that are in themselves not necessarily mutually exclusive):

1. Replace this thermostat example with one demonstrating a seek bar/scrubber and volume slider. The seek bar can use aria-valuetext to create a readable string (minutes and seconds) for screen reader users. One slider can use aria-orientation, while the other has the default implied value.

2. Add a radio group example to demonstrate a component collecting survey-style responses (completely agree, partially agree, etc.). And link to it from the continuous slider example(s) to demonstrate the difference.

3. Add two rating-style component examples:

   • One implemented as radio buttons, only allowing hole values (1/2/3/etc. stars) to be selected.
   • One implemented as a slider, allowing half a star to be filled in.

   The group seemed to agree that this third suggestion holds a lot of value because the two examples (slider vs radio) would be conceptually related, as opposed to a video player and survey response component which are completely different. This may help to cement the difference in peoples' minds. The visual behaviour would also rely on star-based imagery rather than explicit labels for every perceivable value.

Note: @jnurthen indicated that the hit area of the slider examples must be increased regardless of the chosen route forward; both of the current thermostat examples are hard to target on a touch-based laptop.

Hopefully I haven't missed anything of note in this summary. The meeting minutes are available at:

https://www.w3.org/2021/04/06-aria-apg-minutes.html

CC @sinabahram, @IsaDC

[jscholes]

Additional comments: a great question was raised at the end of the meeting - if we go with star rating-based examples, how would mouse users fill half a star with the mouse?

There were also concerns raised about the two rating examples (radio and slider) looking pretty much the same from a visual standpoint. How would users know that one was a radio group and the other was a slider, without a screen reader running? Ultimately the keyboard behaviour would be similar or the same - the component would take up a single tab stop and users would then choose a value with the arrow keys. So this may resolve the problem.

[jongund]

Some star rating widget examples with half stars:

• https://demosbs3.krajee.com/widget-details/star-rating
• https://pub.dev/packages/smooth_star_rating

[jongund]

@mcking65
Updated example and documentation for chromium support in High Contrast Mode.