[Popup] Semantics

[erikkroes]

The explainer mentions that there's a freedom for the author to set semantics, but is there a default semantic role for the popup?

I can imagine the default implicit role to be role="menu", and a default implicit aria-haspopup="menu" on the invoker. This would imply limited options for content (when the author doesn't change the role) but seems to cover the use cases shown in the explainer.

• https://www.w3.org/TR/wai-aria-1.2/#menu
• https://www.w3.org/TR/core-aam-1.1/#role-map-menu
• https://www.w3.org/TR/core-aam-1.2/#details-id-42

[stevefaulkner]

I suggest a less specific role as I can imagine popup being used for a variety of content (i can see it being the native tooltip that HTML deserves)

[melanierichards]

What Steve said 😁

We're showing a lot of action menus as examples, but the base role would imply fairly generic popup-y semantics. In short term, semantics can be made more specific with ARIA. Long-term, we should consider which of these more specific paradigms makes sense to up-level into new, purpose-built elements. <popup> would still be useful then, as there's such a broad range of use for popover UI that the platform is unlikely to cover every last use case with new elements.

[Malvoz]

Referring to this paragraph in the explainer:

This popup attribute will apply accessibility semantics equivalent to aria-haspopup="true" and aria-controls="menuPopup" on the button

If the implicit role is a less specific one as opposed to menu (as suggested in #436 (comment)) then supposedly aria-expanded is a better fit than aria-haspopup, because aria-haspopup="true" is treated as aria-haspopup="menu" according to the aria-haspopup definition.

[melanierichards]

Thanks @Malvoz! aria-expanded would be relevant as well, not sure why I omitted it...possibly because aria-expanded and aria-haspopup effectively have the same mappings into the accessibility API I am most familiar with. 😝

aria-haspopup="true" has that behavior as a fallback for ARIA 1.0 guidance to authors, which we wouldn't need to worry about here as we are adding something net-new to the platform. However, it does raise interesting questions about the suitability of mapping similarly to aria-haspopup, given that ARIA property expects only menu, listbox, tree, grid, or dialog popups. Additionally, I would say it's inappropriate to mutate an accessibility mapping for an HTML property based on an ARIA role applied to a target element...so we'd probably need to a) not map this after all or b) always map it generically (similarly to how aria-haspopup="true" is expressed in the Core AAM, which doesn't document the menu back compat for whatever reason). There could be additional elements in the platform that are purpose-built for specific popup-esque use cases, and relationships with these could get more specific mappings.

[melanierichards]

Thanks again generally to this crew for weighing in...now tracking the need for accessibility mappings in openui/open-ui#329!