Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Popups should expose their accessibility tree #7209

Open
DataTriny opened this issue Dec 24, 2024 · 3 comments
Open

Popups should expose their accessibility tree #7209

DataTriny opened this issue Dec 24, 2024 · 3 comments
Labels
a:accessibility Support for assistive technologies (mS,bT) bug Something isn't working

Comments

@DataTriny
Copy link
Contributor

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)

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

Environment Details

  • Slint Version: commit d6f83a2
  • Platform/OS: Windows 11, Windows 10
  • Programming Language: Rust
  • Backend/Renderer: winit

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.

@DataTriny DataTriny added bug Something isn't working need triaging Issue that the owner of the area still need to triage labels Dec 24, 2024
@tronical tronical added a:accessibility Support for assistive technologies (mS,bT) and removed need triaging Issue that the owner of the area still need to triage labels Dec 24, 2024
@tronical
Copy link
Member

Makes sense. I wonder how to do that with AccessKit for the case where the popup is not a top-level window (with winit).

@DataTriny
Copy link
Contributor Author

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.

@tronical
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:accessibility Support for assistive technologies (mS,bT) bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants