iced-rs
draft: Accesskit integration
Starting AccessKit Integration
This PR is to mainly judge the feasibility of integrating accesskit. It is now at a state where the counter example works on MacOs with VoiceOver.
This is intentionally not finished. I'd like to get some feedback if I should continue down this path. Either way, I've learned a lot putting this together.
Current state
Only Button and Text have accessibility support. I wanted to keep the initial scope a little limited. I've tried to reduce the number of breaking changes. IDs are optional, and there was a best effort to make things work when they aren't provided.
General structure
Changes in core add the data types, and trait changes. Changes in
runtime
Current problems
API changes
There are a couple of spots where trait bounds have been added to Message, and I'd like to work towards reducing
that as much as possible. AFAIK, Messages don't actually need to be Sync or 'static, but those are current
bounds in some places.
- Button widget
- run() function
Winit dependency
Since Iced depends on a vendored version of winit and accesskit-winit depends on winit, we'd probably need to vendor
accesskit-winit, or somehow depend on the normal winit. I've currently switched to winit on crates.io via
[patch.crates-io], but that obviously isn't a great long-term solution.
Operation
I haven't been happy with the current implementation of keeping Operation object
safe, while still making the AccessibilityNode generic over the type of Message
that it can emit. I'll definitely be spending more time trying to figure out a good compromise here.
- Type erasure via Box<dyn Any>
Cargo Feature
I intentionally didn't add a cargo feature to toggle accessibility support on or off. This seems easier to do once the hard bits have been figured out.
Since Iced depends on a vendored version of winit and accesskit-winit depends on winit, we'd probably need to vendor accesskit-winit, or somehow depend on the normal winit. I've currently switched to winit on crates.io via [patch.crates-io], but that obviously isn't a great long-term solution.
I've been working on upgrading accesskit_winit to Winit 0.31-beta.2 (https://github.com/AccessKit/accesskit/pull/656). And as part of that work I've added an accesskit_adapter crate which exposes a cross-platform abstraction (heavily based on the existing accesskit_winit crate but) without depending on Winit. accesskit_winit then becomes a very thin layer around accesskit_adapter which Iced could probably just vendor.
Seperately, I suspect with Winit 0.31, Iced might well be able to drop it's Winit fork. It's now possible for users of Winit to set their own ApplicationDelegate, which should enable Iced to implement the features it needs without forking.
