Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempt to implement AccessKit inside the window crate #5995

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

DataTriny
Copy link

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

  • The 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.
  • There is no way for the app to respond to a 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 on Window 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, the glium::Context in the async example. This also mean that the WindowOp 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.

@wez
Copy link
Owner

wez commented Sep 22, 2024

I don't have any context on accesskit and no bandwidth to look right at this moment.
I will note that we currently push things into the window that accessibility adjacent functions like the IME need:

wezterm/window/src/lib.rs

Lines 311 to 314 in 1c4fdd3

/// inform the windowing system of the current textual
/// cursor input location. This is used primarily for
/// the platform specific input method editor
fn set_text_cursor_position(&self, _cursor: Rect) {}

win.set_text_cursor_position(r);

Could we do something similar for accesskit?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants