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

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.)

Start by tracing AccessKit’s existing handling of the root and focus NodeId, especially the check for unknown nodes and the Action::ScrollIntoView path. Compare the proposed fallback, unknown-node support, and orphan-node alternatives before choosing a behavior. Done means a missing focus target no longer causes an erroneous failure and the selected behavior has coverage.