https://kotlinlang.org logo
#compose
Title
# compose
b

Bryan Herbst

11/02/2020, 3:07 PM
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?
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!
a

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
b

Bryan Herbst

11/02/2020, 11:42 PM
Thanks, that is very helpful!