IssueTracker

I haven't tried this feature before, but it appears that you'd want to trigger it at the decor View level. We won't likely implement it beyond the ComposeView level in the near future.

Please try that and see if it satisfies your needs.

activity.window.decorView.filterTouchesWhenObscured = true

DecorView or the outer ComposeView is a good short term option, but doesn't provide the best user experience. On older devices, there were popular overlay apps for things like "blue-light" to make the screen easier on the eyes.

Not having finer grained control on which UI elements are sensitive would mean any taps on the screen are not processed without good explanation (scrolls, links, non sensitive content, etc...).

Many apps typically only protect UI elements that change user or device state (posting to social media, installing an app, making a purchase, etc...). Typically on the button on the screen.

Would be nice to have this improvement in Compose at a later date :)

Compose doesn't have the same system of short-circuiting events as Views. However, I think you can create a modifier to mark the PointerInputChanges as consumed on Initial, then unmark it on Main, then mark it again on Final. This should disable gesture detectors in the hierarchy below the modifier. It would have to be Android-specific and we would have to access to the MotionEvent. Whether this means we expose the MotionEvent in the PointerEvent or implement this in compose:ui:ui is TBD

Just to make sure I understand the use case end-to-end, is this purely to make screenreaders speak the title when the modal dialog appears? Or something else?

Yes, pretty much. We want the title of the modal to be announced when it is displayed.

Is my understanding correct that using Modifier.focusable and Modifier.focusRequester() would be the desired solution here? (At least for the specific case where you need to change accessibility focus)?

Alex, confirming to make sure I'm not missing a feature request here - is this related to navigation events not selecting initial accessibility focus correctly?

Thanks,

Sean

Hi Sean, thanks for asking :)

Yeah, that is one example. For instance, when you navigate to a new screen, maybe you want to have accessibility focus on a specific text view. Currently what we do do achieve this is using Modifier.focusRequester. And maybe this is OK?

The thing that throws me off is that there are separate concepts of "view focus" and "accessibility focus". And it seems like Compose only supports "view focus", but not "accessibility focus".

I'm not an expert at focus to be honest, so whether or not there needs to be a distinction between the two I guess I can leave up to you all :)

Yep, we're figuring this one out.

Basically from what I understand today (I'm still learning too) accessibility previously used the Activity as a signal for initial focus, but there's not a similar signal for single-Activity apps. Trying to figure out the right path forward on this one as we ingest.

Thanks for the details!

Any update on this???

It's an active work item, but no definitive timeline to share at this time.