Slider accessibility I cannot find a way to define what TalkBack reads when the Slider value is chan...

# compose

[Csaba Szugyiczki]

Slider accessibility
I cannot find a way to define what TalkBack reads when the Slider value is changed. In my example my slider can have 3 values 0, 1, 2 which then mapped to Walking Speed values: Slow, Medium and Fast respectively.

TalkBack reading the percent values of the thumb is not very helpful in this case. Is it possible to override the value read on Slider value change without ruining the functionality of the Slider? (being able to change the value by swiping up or down and by double tap-and-hold then sliding left and right is the basic way a Slider can be used with TalkBack, I do not want to loose this)

[Bryan Herbst]

You’re seeing the output of applying `progressRangeInfo` semantics, which are pretty number-focused and probably not what you want.

You probably want something a bit more custom. I’d start with Modifier.clearAndSetSemantics() to get rid of the progress semantics, and then maybe use a contentDescription with “slow”, “medium”, or “fast” in combination with a liveRegion to ensure that you read out updates as the slider moves

[Csaba Szugyiczki]

If I take this approach, how can I re-add the way a slider value can be modified? (swiping up-down etc)

[Csaba Szugyiczki]

I guess that is supported by TalkBack on nodes that have ProgressBarRangeInfo

[Bryan Herbst]

Yeah, that might be trickier to reproduce, I’ll be honest - I haven’t looked very closely at that functionality so I’m not sure.

In theory you could attach a gesture detector if accessibility services are turned on, but that feels like a lot of work and I’d hope there’s a better way. If no one from Google chimes in here, you could open an issue on the issue tracker asking for guidance (or frame it as a feature request)

[Csaba Szugyiczki]

Thanks for the tip tho’
The answer is around ProgressBarRangeInfo for sure

[Csaba Szugyiczki]

I am actually using my own Slider implementation based on Material, so I was able to provide a label for the setProgress SemanticsAction but that did not seem to make any difference for some strange reason https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]csProperties.kt;l=983?q=SemanticsPropertyReceiver.setProgress

[Bryan Herbst]

Looks like AndroidComposeViewAccessibilityDelegateCompat (which is the bridge between Compose and the accessibility framework) has the bits that wire up the scroll left/scroll right actions to incrementing/decrementing the slider: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]idcomposeviewac&ss=androidx%2Fplatform%2Fframeworks%2Fsupport

[Bryan Herbst]

You might be able to hook into scrollBy semantics?

[Csaba Szugyiczki]

won’t scrollBy only kick in, if the user is scrolling directly on the “View”? Meaning the pointer input has to be within the bounds of my Composable

[Bryan Herbst]

TBH, not sure. Might be worth a try (you might also need to provide a horizontalScrollAxisRange), but overall it does feel like maybe there’s a missing API here.

[Csaba Szugyiczki]

It sure does 🙂

[Csaba Szugyiczki]

Skyscanner just saved my life 🙂 The stateDescription property can be used to override the percent value the Slider reads
https://github.com/Skyscanner/backpack-android/blob/ef36b52dfece0947b08c480151d678[…]main/kotlin/net/skyscanner/backpack/compose/nudger/BpkNudger.kt

[Csaba Szugyiczki]

Thanks for the suggestions Bryan!

[Bryan Herbst]

Oh perfect!!

[c wei]

Hello, I found this thread by search. my question is if the speed is changed from outside, the recomposition will happen and talkback will do again?

[c wei]

if the accessibility focus is still on slider, can we avoid talkback happen again?

[c wei]

the scenario is, user touch to focus on slider, the current speed readout. Then speed was changed with high frequency, the focus was not be moved, the new speeds should not be read to interrupt user. the new current speed only read when next time user touch the slider again.

[Csaba Szugyiczki]

When the user changes the value of a slider, TalkBack will announce the new value, so the user is aware of the result of the change

[c wei]

Thanks. I mean the speed could be from some other source.

[c wei]

when value changed, the slider bar recomposed, could we avoid readout at that time?

[c wei]

I can imagine one direction , but looks not easy to realized.
could we watch the focus Onchange, and use some internal flag to set /clear contentdescription. while the focus of accessibilty seemingly hard to listen in compose.

[c wei]

@Bryan Herbst sorry for interrupt. did you ever handle such talk requirement ?

[Bryan Herbst]

It sounds like you simply don’t like the standard semantics that the slider applies here, so I’d clearAndSetSemantics{} to remove those semantics.

Just my opinion - if I were in need of TalkBack to use an app and something other than my direct actions were to change the state of the slider I would definitely want a TalkBack announcement telling me it changed.

[c wei]

Yeah, I tried nowdays’ Spotify Android app, when focus stay on progressbar, it read the updating progress during playback. Then we could say it’s acceptable.
while on Youtube music app, it just read once when progressbar got foucsed. That’s why I pursue a better experience as youtube music