We are finding that `ClickableText` has at times has too small of a touch target for our liking. Som...

# compose-android

[Lucas Kivi]

We are finding that ClickableText has at times has too small of a touch target for our liking. Sometimes users feel they are clicking an annotated string of text multiple times before the click action is correctly triggered. Obviously, the API was built to use the index of the clicked character, which is prohibitive to some major update to this component. I am wondering if anyone has any cool solutions to this issue? Other than a major design change.

[ephemient]

ClickableSpan in TextView had the same issue

[ephemient]

that's why Chrome has logic to adjust touches to the nearest link (up to some distance), https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/page/touch_adjustment.cc and so do other mobile browsers

[ephemient]

in general the better solution is to make the whole Text clickable though. https://blog.stylingandroid.com/the-trouble-with-clickablespan/

[eygraber]

I think ClickableText is getting deprecated in 1.7

[ephemient]

Compose 1.7 adds https://developer.android.com/reference/kotlin/androidx/compose/ui/text/LinkAnnotation but the root problem is the same

[Stylianos Gakis]

Does the new API perhaps add any way for us to make the touch target bigger? Or is the click still based on the index of the character clicked?

[ephemient]

it does not

[ephemient]

I do have some code which hooks onTextLayout to determine where all the links are and adds a Modifier.pointerInput which imitates Chrome's fuzzy tap-target search. not in public-shareable state though, and (as I said) it's almost always a better idea to just make the whole text clickable even if only a part of it looks like a link

[Stylianos Gakis]

We do have some texts that are literally more than one screen tall, and trying that out felt quite overwhelming imo. Especially with the ripple going through the entire screen. I know I could move or even disable the ripple there, but still it was a bit uncomfortable sometimes wanting to scroll but you end up accidentally clicking the link not knowing where you're going 😅 or if the link isn't even on screen at that moment but you still go there on click.
Or at worst if there are more than one link, which I don't think we do, but we might in the future 🤷‍♂️
Screenshot for reference

[ephemient]

perhaps you can do what I said above then. get the text paths from the TextLayout, decompose the paths to rects, and do custom hit testing in on pointer input

[Stylianos Gakis]

Yep, that'd be the only reasonable approach for this I think too. Definitely not #1 on my prio list as I don't think I have a very good idea how to do that yet, but would be fun to try out.

[Lucas Kivi]

I was thinking about implementing that “fuzzy tap-target search” method as well. However my designer informed that WCAG has a touch target exception for inline links where the tap target only needs to match line height.
https://www.w3.org/TR/WCAG22/#target-size-enhanced

[ephemient]

tried to untangle from my codebase, so this version is untested but should get the idea across

ClickableTextWithTouchAdjustment.kt