Attempt to implement AccessKit inside the window crate #5995
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As the PR title suggests, this is neither fully working nor complete. I think it can be a starting point nonetheless.
Relates to #913
Current status
The
async
example is working correctly on Windows. I tested it on Windows 11 with NVDA and Narrator (two free assistive technologies).Issues encountered
WindowEventSender
cannot be shared so when accessibility-related events come from the system, I had to place a message into the window loop so the event could be dispatched to the app later. Although not elegant, this approach can work on Windows, and probably on X11 as well, but I think there would be no way to replicate it under Wayland. I haven't really checked on macOS.WindowEvent
: when accessibility is first requested, I had to instruct AccessKit to generate a placeholder accessibility tree, until I can push the real one later. Another option would be to have a dedicated callback onWindow
to build the initial accessibility tree, but then the entire app state must be shared.WindowOp::update_accesskit_if_active
cannot take the app state in its closure because its signature impose new restrictions that clashes with, for instance, theglium::Context
in theasync
example. This also mean that theWindowOp
trait is not object safe anymore, which will be an issue with the real wezterm app.Overall, adding accessibility support to the windowing crate of wezterm would first require some architectural changes. I hope that this proof of concept can help shape the future of a nice, accessible, terminal emulator.