IssueTracker

Thanks Alex.

The reason they are non null is because we decided before that this is ok to provide states for both Row(Modifier.selectable(...)) and a RadioButton and both of them being visible for a11y as well is ok and on par with android if I recall correctly. Also we want to encourage the behaviour where you can tap both Row and RadioButton and get different ripple effect (big bounded ripple for Row and small unbounded for the RadioButton).

Having null onClick is not an easy design change since it might imply to people that passing a nullable onClick should disable the RadioButton and resulting with different UI.

I will doublecheck with UX team if we should make it possible to ripple on the RadioButton only when you tap the Row itself, but IMO in this case it will go against the nature of the ripple being a responsive tap indicator under your finger.

Stay tuned :)

The reason they are non null is because we decided before that this is ok to provide states for both Row(Modifier.selectable(...)) and a RadioButton and both of them being visible for a11y as well is ok and on par with android if I recall correctly.

Hmm, interesting! The reason why I filed this bug actually was because I was trying to exactly replicate the behavior of android.widget.RadioButton.

1. When using android.widget.RadioButton, it will never show a ripple for the entire row. Even if you click on the RadioButtons text, it will only show a ripple on top of the RadioButton icon. (See the radiobutton-ripple.mp4 video below, which shows the behavior of a android.widget.RadioButton view in a non-Compose app).

2. When using android.widget.RadioButton w/ TalkBack, it will focus the entire thing (the radio button icon and the text). When swiping through the screen, the individual radio button icon won't ever gain focus individually. (See the radiobutton-talkback.mp4 video below, which shows the behavior of a android.widget.RadioButton view in a non-Compose app).

My main goal here is to create a Compose layout that is exactly identical to a layout you would otherwise create with traditional views, because I don't want there to be any UI inconsistencies between compose widgets and traditional views in our existing app. So perhaps that is why UX may feel differently about the behavior. :)

Either way, I'll leave it up to you to decide what is best for the material library (I'm not actually affected by this, as I've created my own custom RadioButton for my own design system library, but figured I should file the bug just in case anyways!)

OK, reporting back on this... I actually found out a way to do this w/o the need for a nullable click listener.

TIL you can hide things from talkback with Modifier.semantics { hidden() } :)

Please feel free to close this bug!