TalkBack has a lot of behavior dependent on `Acces...

# compose

[Bryan Herbst]

TalkBack has a lot of behavior dependent on `AccessibilityNodeInfo`’s class name, and there’s some functionality in in Compose’s accessibility layer to map specific semantics to View classes (e.g. ProgressBar or SeekBar when SemanticsProperties.AccessibilityRangeInfo is present).

However, this is missing for some prominent components such as Button, with no public API to influence that behavior. This behavior is also a bit clunky given that it relies on labeling Compose widgets as specific View classes.

Is there a plan to surface something to support this? Is the TalkBack team exploring ways of decoupling TalkBack from the View APIs to better support Compose in the future?

[Bryan Herbst]

Alternatively- is the recommendation to just put “button” in the accessibilityLabel if we want TalkBack to say “button”?

[Bryan Herbst]

@Alexandre Elias [G] I know you’ve talked about accessibility in here before and might have some insight!

[Alexandre Elias [G]]

We will definitely make Compose Button have the same behavior as Android Button in TalkBack by the time of Compose 1.0 release, and add whatever core public APIs are needed for third-party Buttons to have the same behavior

[Alexandre Elias [G]]

Yes, TalkBack is planning to decouple their behavior from classnames. I was talking to them last week about it

[Alexandre Elias [G]]

As a general rule, our plan is to use semantic traits/actions instead of element categories whenever possible. However, in the specific case of Button, we haven't been able to come up with any particular semantic trait that distinguishes one from a general clickable, so we will probably need to introduce a new minimalistic disambiguation system to replace classnames

[Bryan Herbst]

Thanks, that is very helpful!