Slider: Rating Slider Example

[jongund]

I have created a new rating slider example based on the discussion at the 6 April 2021 meeting.

Features:

• Uses SVG graphics elements
• Has high contrast support
• Code to use APG coding practices
• Uses pointer events
• Uses aria-hidden=true on SVG element
• Sets the CSS property forced-color-adjust to auto on the SVG element.
• Using stroke-opacity and fill-opacity instead of transparent values for setting stroke and fill colors for the SVG rect used for focus ring for high contrast mode.

Preview rating slider example

Review checklist

• Editorial review by @mcking65
• Functional review by @smhigley
• Visual design review by @smhigley
• Accessibility review on Windows by @shirsha
• Accessibility review on MacOS by @carmacleod
• Accessibility review on iOS/iPadOS by @jongund
• Accessibility review on Android by @a11ydoer
• Code review by @jesdaigle
• Test review by @jesdaigle

[jongund]

Works on iOS using touch interface and also works with VoiceOver which announces the current and changes the number of stars.

[a11ydoer]

Works on iOS using touch interface and also works with VoiceOver which announces the current and changes the number of stars.

Yes, I had a problem with iOS device for the example. Thanks so much, Jon.
I am also in the process of looking into/asking around WCAG touch target rule.

[a11ydoer]

New double A WCAG 2.2 target size success criteria.

https://w3c.github.io/wcag/understanding/target-size-minimum.html

"Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor."

Therefore, the rating slider example does not have a conflict with WCAG target size rule.

My big thanks to Alastair Campbell, @alastc for this info.

[smhigley]

Visuals + a quick skim of the code look good to me.

Potentially in the future we could include a lighter shadow-fill effect on hover, but it's definitely not necessary before merging now 👍

[carmacleod]

+1
Works well with VoiceOver in both Safari and Chrome on macOS.
5 stars! :)

[alastc]

Be careful with a lighter fill-effect, that can be an issue with non-text contrast, we even have that example in the docs.

[shirsha]

My only concern is when screenreader user navigates in browser mode there is no way for them to know that there are five stars.
When no stars are selected it will narrate it as "slider no stars"

The aria-valuetext changes only when the user tabs to it in focus mode ( aria-valuetext="none of the five stars" ), otherwise it will be "two stars", no stars etc.

[jongund]

Be careful with a lighter fill-effect, that can be an issue with non-text contrast, we even have that example in the docs.

Thank you for the reference, we are using a solid fill.

[jscholes]

@jongund This is looking good; thanks for your work on it. My only two concerns revolve around the wording of the default/zero value, and the changes that happen on focus/blur:

1. By default, the slider is set to 0, and aria-valuetext reads: "none of the five stars". This wording feels a bit awkward, specifically the inclusion of the word "the", and the inconsistency between "none" and "0". "0 of 5 stars" would be fine IMHO.
2. I don't know that the change to aria-valuetext on focus/blur is really necessary. If aria-valuetext was always to include the max, it would reduce the complexity of the implementation and provide a uniform experience regardless of how users navigate to/encounter the slider. I'm thinking "0 of 5 stars", "3 and a half of 5 stars", etc., at all times. Thoughts?

[mcking65]

@jscholes wrote:

1. By default, the slider is set to 0, and aria-valuetext reads: "none of the five stars". This wording feels a bit awkward, specifically the inclusion of the word "the", and the inconsistency between "none" and "0". "0 of 5 stars" would be fine IMHO.

I agree with this.

@jscholes wrote:

2. I don't know that the change to aria-valuetext on focus/blur is really necessary. If aria-valuetext was always to include the max, it would reduce the complexity of the implementation and provide a uniform experience regardless of how users navigate to/encounter the slider. I'm thinking "0 of 5 stars", "3 and a half of 5 stars", etc., at all times. Thoughts?

We made this change to be consistent with the seek slider where I believe we have general agreement that hearing the maximum value repeated every time the value changes creates excess and even distracting verbosity, making cognitive focus on the task of setting a new value more difficult. In the case of a seek slider, we should also keep in mind that excess verbosity detracts from media that might be playing while users are performing the seek task.

So, the behavior we are proposing as ideal is to ensure that valuetext communicates the maximum when the page is loaded and any time the focus moves into the slider. To be sure that a reading cursor picks up the correct valuetext after focus moves away, the max is added to valuetext on blur.

While this approach to minimizing distracting verbosity when communicating the maximum value via valuetext is a bit more complex than necessary for the rating slider, I think there is some value in consistency in guidance. Trying to explain when this small bit of fine tuning is really valuable verses a nice-to-have is more likely to create confusion.

[jongund]

@jscholes
Updated aria-valuetext labels when no stars are selected.

[mcking65]

Editorial changes and review complete.

[a11ydoer]

• It still has a lag to activate the rating slider("tap to activate")
• Rating was read as percent like other sliders in Android, Talkback. This is not necessarily incorrect but it would be more correct to read this is "star" rating reflecting the visual design.
  

[jesdaigle]

Code and test review look good.