TalkBack has a lot of behavior dependent on `AccessibilityNo kotlinlang #compose

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

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?

Alternatively- is the recommendation to just put “button” in the

accessibilityLabel

if we want TalkBack to say “button”?

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

Alexandre Elias [G]

11/02/2020, 11:15 PM

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

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

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

11/02/2020, 11:42 PM

Thanks, that is very helpful!