Investigate why we don't create an Accessible for <panel type="autocomplete-richlistbox">
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: Jamie, Unassigned)
References
(Blocks 1 open bug)
Details
Over in bug 1902052, specifically:
https://phabricator.services.mozilla.com/D216113#inline-1199823
we encountered a XUL panel that has type="autocomplete-richlistbox" but no ARIA role. We don't currently create an Accessible for such panels. This caused severe breakage on Windows in this case because this resulted in the label (the first element in the panel) being treated as the root of the pop-up, but the buttons in the panel are not children of the label, so calling IAccessible::get_accChild on the label to retrieve those elements failed. This completely broke any events (including focus!) fired on those buttons. There is a simple workaround - put role="group" or similar on the panel - but we should still look into this at some point.
I'm not quite sure why we explicitly refuse to create Accessibles for autocomplete-richlistbox panels. That was done in bug 1439778, but since that bug was just XBL removal stuff, I assume we had similar behaviour even before that. Most cases of <panel type="autocomplete-richlistbox"> have a role (usually role="group"), but not all. I'm concerned that the cases that don't are broken, such as these two. Unfortunately, I'm not yet sure how to trigger either of those popups.
Most likely, given the potentially severe breakage here, I think we should always create an Accessible in these cases and give it an implicit role of group. If there are really cases where we don't want to create an Accessible, we should figure out why. If they're very specific edge cases, we should perhaps prefer to explicitly use role="none" on those rather than risk breakage slipping through the cracks.
Description
•