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

Integrate AccessKit #151

Open
DataTriny opened this issue Oct 10, 2024 · 1 comment
Open

Integrate AccessKit #151

DataTriny opened this issue Oct 10, 2024 · 1 comment

Comments

@DataTriny
Copy link

Initially proposed in #121

Users with various disabilities interact with their computer in very different ways, relying on specific input methods (voice recognition, eye tracking, Braille keyboard...) and/or specific output methods (speech synthesizer, Braille display, screen magnifier...).

To support these use cases, all major operating systems came up with the idea of the accessibility tree. This tree is a semantic representation of the content of all user interfaces currently available on the system. The desktop is the root element of the tree, each top-level window is a branch. Widget containers such as panels are also nodes in the tree. Simple widgets such as buttons or labels are leaf nodes. Each node has a role which indicates what it is (button, label, checkbox, panel, window...) as well as properties and states (name, description, enabled state, checked state...). Good behaving applications are expected to expose their accessibility tree to the operating system, which then exposes the whole tree to assistive technologies.

Assistive technologies are any software which query and manipulate the accessibility tree. Examples include: screen readers, screen magnifiers, voice recognition... Automation testing tools also use the accessibility tree to ensure the presence of UI elements and to perform actions on the application being tested.

If the concept of an accessibility tree is common to all platforms, its technical implementation is very different, making it challenging for UI toolkit developers to support some (if not all) of them.

AccessKit is an answer to this problem. It gives UI toolkit developers a cross-platform way of describing their accessibility tree, hiding away the implementation details of each platform. Because it retains the whole tree, it is a good fit for immediate mode rendering UI toolkits like dvui. Its C bindings make it possible to integrate it into projects written in other languages than Rust.

@david-vanderson
Copy link
Owner

Thank you so much for this detailed overview. It answers a lot of questions I had about the scope and intention. I really appreciate it!

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

No branches or pull requests

2 participants