[slider] Component doesn't work on touch+AT devices

[CodySchaaf]

Similar to this issue material-components/material-web#1285

The slider doesn't work for users on touch devices while using AT (e.g. iOS/VoiceOver, Android/TalkBack). The ARIA makes it announce like a native <input type="range">, and gives the hint to users that they can use gestures like "swipe up or down to change the value" (on iOS) / "use the volume buttons to change the value" (Android). However, as the slider can't actually intercept those (just yet anyway, until it uses Accessibility Object Model user action events https://wicg.github.io/aom/spec/#user-action-events), it is essentially broken for these users.

You can see this broken behavior on any of the sliders here https://material-ui.com/components/slider/#slider by visiting them with a mobile device while voice over is enabled.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

On iOS with VO enabled navigating to the slider reads "Swipe up or down with one finger to adjust the value", but for instance on the volume slider it just keeps reading "30%" "30%" and the value doesn't change.

Expected Behavior 🤔

The slider value should change as you "swipe up or down with one finger"

Steps to Reproduce 🕹

Either use this sandbox https://codesandbox.io/embed/material-ui-issue-forked-vn1f1?codemirror=1

Or any of the sliders on https://material-ui.com/components/slider/#slider

Steps:

1. On a mobile/tablet device, with AT running, navigate to the Slider example
2. Set focus to the slider (it should read "swipe up or down with one finger")
3. Attempt to change the value by following the prompt given by the AT (e.g. "swipe up or down" / "use volume keys" depending on the specific OS/AT)

Context 🔦

I'm trying to get the slider to work for accessible users on ios and android

As the linked issue says:

The most robust way to make this universally work, currently, is to actually have a proper <input type="range"> which is either heavily styled, or which is being "piggy-backed" via CSS/JS. See https://codepen.io/patrickhlauke/pen/byWPMX for demo and explanation

Instead of the current implementation that uses a <input type="hidden"> combined with the role="slider" on a span.

Because of the warning here https://w3c.github.io/aria-practices/#slider

Warning
Users of touch-based assistive technologies may not be able to fully operate widgets that implement this pattern because APIs for capturing the necessary gestures and commands from assistive technologies are not yet available. Authors should fully test widgets using this pattern with assistive technologies before considering incorporation into production systems.

The apis are not available to support this version.

Your Environment 🌎

OS: iOS, Android
Browser: All

Tech	Version
Material-UI	next
React	latest
Browser	ALL (iOS, Android)
TypeScript	N/A
etc.

[oliviertassinari]

Interesting. The option to use a native slider was ignored to make customizations easier. But we could still imagine an approach similar to the rating. Use the native slider, but "hidden". In any case, this could require a couple of days of work. Would you be interested in working on it?

w3c/aria-practices#1038

[CodySchaaf]

Yeah I would. The code pen here https://codepen.io/patrickhlauke/pen/byWPMX seems to capture the best of both worlds, although I'm a little concerned about how to support the Multi-Thumb version, which I see you just linked, so probably thinking the same thing. I wonder if you could use multiple hidden <input type="range">, one for each Thumb?

[oliviertassinari]

I wonder if you could use multiple hidden , one for each Thumb?

I have seen this pattern used in the past during a benchmark. However, I can't remember where 😔.

[CodySchaaf]

Hey @oliviertassinari, I think I have something pretty promising over on https://github.com/CodySchaaf/material-ui/tree/fix/slider/fix-a11y-for-mobile

It cleans it up a bit and simplifies things even. The only real edge case I ran into was handling the multi-thumb mode (which could use some better aria labeling, but I think that is an issue that already exists). And the marks && step == null case.

I could use a little direction with the tests. I've updated the ones that made sense to keep, but was having trouble deciding what to do with all the keyboard ones since the browser handles that now and swallows the events. I might be missing something but it looks like trying to manually trigger keydown events doesn't have any affect when targeting an input element.

I did find testing-library/react-testing-library#269 but I think that still requires you to have an explicit handler on the element. So I updated the spots that made sense to use fireEvent.change instead, and marked the tests I think should be removed, or possible modified to use the dragging interactions instead of keyboard. You can find that here CodySchaaf@41da6a6

Let me know if it is easier to just start with a pull request, but I still need to finish looking over the other tests besides the unit tests and make sure those are still good, as well as run through some of the edge cases once more.

Thanks!

[oliviertassinari]

@CodySchaaf This looks like a solid start! I have spent more time looking at the UX than the code. On the code side, I have noticed that we could able to drop the type="hidden" input as it duplicates with the new type="range" input. I'm not sure that unstyled should import system, to consider. Regarding the tests, I agree that many of the current tests are no longer relevant. I would remove all the ones that are now covered by the native input. However, be careful because some tests are using the keyboard actions to test something else, e.g. what happens with a slider range, when two thumbs swap order?