Expanded select elements fail to report being descended of document
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
People
(Reporter: jdiggs, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
Steps to reproduce:
- Launch Firefox with attached test case.
- Launch attached accessible-event listener.
- Press Tab until the select element gains focus.
- Press Space to expand the combo box.
Expanded results: The accessible ancestry of the combo box would be the same for step 3 and step 4.
Actual results: The accessible ancestry of the combo box is different. Sample output:
Ancestors of focused [combo box | ]:
[document web | ]
[internal frame | ]
[scroll pane | ]
[panel | ]
[frame | Firefox Nightly]
[application | Firefox]
[desktop frame | main]
Ancestors of expanded [combo box | ]:
[frame | Firefox Nightly]
[application | Firefox]
[desktop frame | main]
Impact: Orca has a ton of logic which relies upon being able to distinguish widgets which are inside a document from those which are not. As far as the user is concerned, the combo box in step 3 is the same as the combo box in step 4 and should be treated as such.
Reporter | ||
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
This is due to e10s (multi-process). The select dropdown is rendered in the parent process, not the content process. As far as Gecko a11y is concerned, they are indeed entirely separate elements. The challenge is figuring out how to link them together, especially because content and parent are effectively separate trees from the parent's perspective.
Note that NVDA had this same issue in bug 1422176, but NVDA implemented its own workaround. Unfortunately, because of the way content process a11y works, this is going to require a slightly different implementation for each platform.
Updated•5 years ago
|
Comment 3•3 years ago
|
||
Now that we have a unified Accessible hierarchy covering both local and remote, it should be possible to fake return the <select>
element Accessible as the parent of the select dropdown. Doing this in the other direction will be uglier, but I don't think any client depends on that, so we should address that elsewhere if we need it.
Note that Windows won't be able to benefit from this until Cache the World is done. That doesn't prevent this from being worked on, though; it will still benefit other platforms and Windows will get the benefit once CTW is enabled.
The ugly bit here will be creating a LocalAccessible specific to the ContentSelectDropdown. I don't love the idea of matching on id, but I'm not sure what else we can match on. We'll need to restrict this to privileged root documents or similar to prevent spoofing.
Updated•2 years ago
|
Description
•