[mwcampbell]

Ugh, yet another GUI toolkit. Let's spread the work of implementing and debugging accessibility even thinner.

I understand that by drawing its own widgets on desktop, Compose can provide greater parity with Android. But that benefits developers at the cost of some users.

I think what I would have done is implement the widgets on the web platform and use CEF for the whole application, not just the browser widget. Then they could also target web applications through Kotlin/JS, though potentially with an oversized JS bundle. It would also be important in that case to avoid the pitfalls of Flutter for Web, e.g. requiring the user to press a button to turn on full accessibility.

Speaking of CEF, making their embedding of that accessible is going to be particularly problematic, because they're using it in off-screen rendering mode, so they can render the page to a bitmap and draw that onto their own canvas. That means they don't benefit from Chromium's mature support for platform accessibility APIs. CEF does expose Chromium's cross-platform accessibility tree (thanks Adobe!), but then it's up to you to expose that to the host platform. Windows screen readers in particular have special support for Chromium's Windows accessibility implementation, allowing users to use special keyboard commands when browsing web pages. Unless Compose's accessibility implementation is a bug-for-bug emulation of Chromium's, Windows screen reader users won't have the usual level of access to web content.

[romanovcode]

What's even worse - It's Java UI kit.

[mwcampbell]

I know I ranted a bit, but this comment is a shallow dismissal that contributes nothing to the discussion.

[trinix912]

Not trying to troll or anything, but what's wrong with Java UI kits?

[dector]

Nothing.