Access keys and restricting to the visible sub-tree?

[dhardy]

Hi! This question relates to integration with https://github.com/kas-gui/kas/

Visible sub-tree

Presumably it is expected to list only visible children? (Especially in UIs with large widget trees.) This of course implies that some nodes will need more frequent updates, but is still likely to perform better (esp. worst case) than including the entire widget tree.

If a node is added to the tree, then later removed from its parent due to being hidden, then made visible once again, will the node itself remain in the tree (avoiding the need to re-build it)?

Access keys

Examples: Alt+F to open the &File menu, or 1 to trigger the corresponding key on a calculator widget.

Do these have any relation to accessibility? Might they conflict with an accessibility tool's own keys? Is this something an accessibility tool would provide itself? If so, something like keyboard_types::Key would be needed to specify the access key.

(I ask in part because the best way to support access keys when not using an accessibility tool may be to use a bulit-in pseudo-accessibility layer configured in a similar way. But this might be less desirable if such keys should still function with an accessibility tool enabled.)

---

The relation between the two parts is that only access keys from the visible sub-tree should be enabled (e.g. menu items should not be accessible while the menu is closed). I don't know whether any other facets of accessibility should be restricted in the same way?