[Popup] is the "anchor-popup hierarchy" used to create the browser's accessibility tree?

[carmacleod]

The Anchoring section of the explainer says:

1. It enables a hierarchical relationship to be established between the popup and its anchor element separate from the DOM hierarchy.

It would be nice if this hierarchical relationship was used to construct that portion of the accessibility tree, so that even if the popup is placed somewhere else in the DOM, it would still follow its anchor in the accessibility tree, which would be the logical and most useful place to find it when a screen reader user is using their reading/virtual cursor.

[aardrian]

While I think aria-controls is intended to address that, no screen reader currently exposes it to users (and JAWS removed/hid support in April 2019). At the very least we need to understand why screen reader vendors (and their users) decided it was not valuable enough to support. If it was because of mis-use, then relying on it here could result in poor SR support for the <popup> or a poor broader experience when aria-controls is exposed to users in other contexts.

I am also not sure I am a fan of encoding ARIA into a new HTML element.

[carmacleod]

@aardrian
Thanks for making me explore this a bit more - I realized there's a flaw in my thinking. :)

What I thought was that when a popup is shown, user agents could insert the popup's structure into the accessibility tree immediately following the popup's anchor (for easy access with virtual cursors). Of course, I figured the UA would send all of the appropriate a11y-tree-modified events (2nd table) so that AT would know, and then remove the popup structure from the accessibility tree (and send events) when the popup is hidden.

What I realized is that while that would work for anchors that are in the normal document flow, and it would even work if an anchor is contained within certain portions of a complex component such as a td in a table or li in a list (i.e. the parts that can contain flow content), it breaks down completely when the anchor is integral to the complex component's structure. For example, if the anchor is the tr or td in a table (as in the explainer's table row context menu example), or the li in a list, then squashing a popup's a11y structure into the accessibility tree between table rows would completely mess up the table.

So I withdraw my suggestion, and will close this issue, but first:

I am also not sure I am a fan of encoding ARIA into a new HTML element.

I'm not quite sure what you are saying with that sentence? Do you mean you wouldn't require authors to explicitly add aria-controls to a new HTML element? I don't think anybody wants that.

However, any new HTML element will need to be mapped to an implicit role, and any new attributes will also need to have some kind of implicit mapping, in order to be useful to AT. So it's possible that aria-controls may be an appropriate implicit mapping for the anchor attribute. Which of course brings us right back to: What to do about aria-controls. :)

[aardrian]

Thanks for making me explore this a bit more - I realized there's a flaw in my thinking. :)

Always happy to be a useful idiot.

...then squashing a popup's a11y structure into the accessibility tree between table rows would completely mess up the table.

I totally missed that in the explainer. Yeah, that is a huge issue. That also leans on a false (but pervasive) belief that it is ok for any element anywhere in the tree to be made interactive simply by adding event handlers.

I think you should leave this issue open but ask where in the accessibility tree it will be inserted. Nearest ancestor where it is legal? First legal descendent? Uranus?

Do you mean you wouldn't require authors to explicitly add aria-controls to a new HTML element? I don't think anybody wants that.

That is what I am saying. The explainer shows an example of a pop-up menu:

<button aria-haspopup="true" aria-controls="menuPopup" id="menuButton">Menu</button>
<popup id="menuPopup" role="menu" anchor="menuButton">
    <!-- Markup for menuitems goes here -->
</popup>

Because there is no dedicated trigger element (attribute?), ARIA is necessary here. I am not sure how to get around the ARIA in this context.

Similarly, while true is a valid value aria-haspopup (and maps to menu), the values are supposed to map to the role of the target. In this example aria-haspopup="true" is fine, but aria-haspopup="menu" is better. When this pattern is inevitably used for tool-tips, then ARIA needs to be updated to allow tooltip as a valid value of aria-haspopup — unless I am missing something.

Anyway, a dedicated trigger element (or attribute) might mitigate that. From another issue, I mulled over this construct (to also remove the need for reliance on JS):

<button for="Foo" open>
<popup id="Foo">
  Hey there.
</popup>

And to your point about aria-controls, I raised that in another issue.

[melanierichards]

Thanks @carmacleod for opening this issue, and sorry it took me awhile to get back to you…working my way through a long list. :)

"Should anchored positioning hoist the popup to a different part of the accessibility tree?" is something we've discussed a bit internally and need to call out in the explainer as an open issue for further discussion. Two things simultaneously true:

1. Our hope is that the top-layer positioning of popup, which wouldn't be clipped by ancestral elements, reduces the likelihood of authors stuffing popups at a strange point in the DOM. Getting around these positioning snafus is a large reason why you find a lot of these popups at the end of a document as the direct child of the root element, thus causing accessibility issues…hopefully this proposal means this practice is no longer necessary. :)
2. It might make sense to hoist this element into a different point in accessibility trees based on the anchor-popup relationship. There's some complexities to think through there, hence why I think this would be a good open issue for further discussion in standards...as an alternative we could try and bake the controller relationship into intrinsic mappings for TBD declarative invocation (replacing the aria-controls relationship in the example) and work with AT to get better support for that.

FWIW and related to this discussion: I would want such a declarative invocation attribute to be applicable only to interactive elements (perhaps a subset of these). It seems ok to provide more flexibility around invocation through the JS API (i.e. sometimes the logic for showing a popup may not be driven off of interaction but off of time or some other internal app logic), but if the platform handles scriptless invocation that should only be done on elements where that would be sensible and expected.

[melanierichards]

Thanks again for asking, @carmacleod! I've ported this discussion over to openui/open-ui#328.