You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: