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
When a popup element is shown, its accessibility tree doesn't seem to be merged with the parent one. I would expect that the root element of the popup would be added as a child of the element which contains the popup.
This is not even a case of keyboard focus not moving properly, the child elements of any popup are not part of the accessibility tree, even if they are configured to be.
Reproducible Code (if applicable)
The issue can easily be reproduced with the todo example:
1. Open Accessibility Insights for Windows
2. Run the todo example: `cargo run -p todo`
3. Click on the Close button of the example window to make the confirmation popup appear
4. Observe in Accessibility Insights that the content of the popup cannot be found
I'm working on supporting combo boxes in AccessKit. Not being able to interact with the list of possible choices that appear when expanding the combo box is a blocker.
The text was updated successfully, but these errors were encountered:
It depends on the content of the popup: In the case of the todo example, since the popup is used to show a modal dialog, it should add a new element of role Role::Dialog as a child of the element containing the popup. As for combo boxes, it should add an element of type Role::ListBox (I'm working on this part but I can't see my changes due to this bug).
I can see that when the focus is requested inside a popup, the AccessKit adapter is notified about this but no tree update gets generated since all elements appear to have AccessibilityRole::None. I'm not even entirely sure which element actually gets the focus.
Ahhh I see. This makes sense but will require some additional work. The popup is not part of the same item tree (and accesskit tree), but we may need a way to make the association of the item tree of the popup belonging to a certain accessible element, so that we can build the AccessKit tree for this tree. Maybe an accessible-popup: the_popup_name; type of property.
Last resort is that we have a call/discussion in January in our public mattermost.
Bug Description
When a popup element is shown, its accessibility tree doesn't seem to be merged with the parent one. I would expect that the root element of the popup would be added as a child of the element which contains the popup.
This is not even a case of keyboard focus not moving properly, the child elements of any popup are not part of the accessibility tree, even if they are configured to be.
Reproducible Code (if applicable)
Environment Details
Product Impact
I'm working on supporting combo boxes in AccessKit. Not being able to interact with the list of possible choices that appear when expanding the combo box is a blocker.
The text was updated successfully, but these errors were encountered: