It should not be an error for focus to point to a missing `NodeId`

[dhardy]

kas::Id is a (compressed) path, which allows tracking focus of unrealised (hidden) entries in a list while virtual scrolling. As such, it is not a bug for Kas's focus to point at a widget which doesn't exist. It is still possible to operate on such an Id by scrolling it back into view.

(No, Kas does not do this by keeping a copy of any widget in focus while scrolled out of view. It would be possible, but would require hacks in widget code, and imply that bugs in widget code can crash a UI when accessibility is enabled.)

Working around this

From the Kas side, I can check whether nav_focus points to a reachable widget (reverting to the root Id if not), but this is not equivalent to the AccessKit check since Kas may have dormant nodes not in the AccessKit tree. To accurately match the AccessKit check I'd need to store a copy of the tree.

The right way?

AccessKit already knows the root NodeId and tests focus; it would be much easier to revert to the root id in AccessKit.

Alternatively, AccessKit might actually try to support operations on unknown nodes. It could at least attempt Action::ScrollIntoView.

Or AccessKit could even keep the Node in its own tree as an orphan in this case. It is likely not wrong given that no more up-to-date representation of the Node is available. (Yes, I'm hesitant to suggest this. But, at least for Kas, it is more correct behaviour than panicking because focus does not point at a known Node.)

[DataTriny]

When the focus moves to a node, assistive technologies will immediately request more information on that node, such as its label. If this node isn't part of the tree anymore, what would we send back? Similarly, putting the focus on the container when the focused node gets off the screen would make for a terrible user experience.

When scrolling an area, if one of its child has focus and goes off screen, you should move the focus to the node that is the closest in terms of coordinates to where the previously focused node was.

[dhardy]

When the focus moves to a node, assistive technologies will immediately request ...

I'm talking about maintaining focus on a hidden node above, not moving focus to a hidden node. So yes, when focus changes, that node should be provided.

[...] you should move the focus [...]

That's not how several existing tools work, e.g. when an input field in a web browser is scrolled off screen and you press a key it will be focussed again. A better example which uses virtual scrolling is a spreadsheet; I just tried Libreoffice and Gnumeric and both continue to accept key input into an off-screen cell without scrolling back (but do if you press Tab).

[mwcampbell]

An assistive technology can continue to query the focused node even after the initial focus change. So, as much as we want to meet toolkits where they are, it's not clear how we would handle such queries if we allow a node that's no longer in the tree to still be set as the focused node.

[DataTriny]

Seconding Matt, so you'd have to find which node exactly triggers the panic you were talking about in the kas PR.

Furthermore, the tools you mention don't count because they all expose the whole accessibility tree to let ATs perform specific tasks on behalf of the users.