What types of elements should be excluded from <popupdialog> usage?

[mfreed7]

See this comment for more context.

The <popupdialog> element (name TBD) is meant for "general purpose" transient non-modal dialogs, to be used only when there aren't more-specific element types. We need to enumerate those more-specific types, so that this recommendation makes sense.

So the question is: what other elements are similar to popups behaviorally, but semantically different, and made for more specific purposes? These would constitute the list of other types of elements for which developers should not use <popupdialog>.

This is a brainstorming issue, so I'll start with some candidates for this list, with (rough) links to some definitions for each:

• <listbox> - link
• <actionmenu> - link
• <tooltip> - link
• <toast> - link
• <navmenu> - link?

What other ideas do folks have?

[mfreed7]

At the last OpenUI meeting, I took an action item to put together a comparison of the various "popup-like" use cases.

I was able to pull much of the needed information from the OpenUI popup research page, which was nice. I pulled that together with a few other sources (e.g. WAI-ARIA), and constructed this table:

https://docs.google.com/spreadsheets/d/1v4RXKrvp-txG477GNH42gFSzX_HkRYJk-eap6OgAorU/edit?usp=sharing

It lists all of the closely-related UI patterns that I've heard in our discussions, and compares them along various dimensions. I also took a stab at assigning HTML elements to each UI pattern, to try to start the conversation about which elements belong to the "generic" <popup>-type element, and which deserve their own separate element.

To focus the conversation in one place, I did not enable comments on the spreadsheet above - please add your comments here in this thread. I will attempt to keep the doc up to date with the comments here. Again, this was intended to be a first cut at some research on the behaviors, and I'm sure I missed many important things. Please help me find them.

[scottaohara]

some quick comments on some of the aria role assumptions here.

re: navigation menu. what exactly is the use case here? I question if this would actually be a role=navigation, and not instead a list. I'd rather expect a button that invoked this sort of content to already be within a navigation landmark... or not, if it's not actually necessary to expose such items as a nav. A landmark that is hidden by default is not particularly useful.

re: teaching ui - still don't understand why this is being classified as a popup, other than it needing some of the proposed functionality that is being associated with popup. seems it should just be a dialog element?

re: <alert>, toast/popup notification... role=alert is not always the correct choice there, and especially not true if it's going to receive focus (in response to the 'typically not focused").

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] What types of elements should be excluded from <popupdialog> usage?.

The full IRC log of that discussion

<gregwhitworth> Topic: [Popup] What types of elements should be excluded from <popupdialog> usage?
<gregwhitworth> github: https://github.com//issues/417
<gregwhitworth> masonf: this is the biggest of the three
<gregwhitworth> masonf: what we decided last time was that it was ok to have a general purpose popup and which usecases it shouldn't apply to
<gregwhitworth> masonf: I tried to enumerate all of the ones that I've heard and put them in a matrix
<gregwhitworth> masonf: and also put some of the semantics in there
<gregwhitworth> masonf: I posted it late, but I'm not sure how best to use the time
<gregwhitworth> q?
<gregwhitworth> masonf: I put together a quick stab based on my own experience - please correct me
<gregwhitworth> masonf: *presents the matrix*
<gregwhitworth> scottohara_: did we actually come to the conclusion that a generic popup was a good idea?
<gregwhitworth> bkardell_: I had a similar takeaway
<gregwhitworth> masonf: I may have had a bias, but I took the action item to explore the area
<gregwhitworth> una: I thought what masonf did as well but maybe I missed something
<gregwhitworth> masonf: we did agree that if there is a generic popup that there should be some usecases that shouldn't be included
<gregwhitworth> masonf: in either event the action item was to do research and see if there was a generic category
<gregwhitworth> masonf: the rows are different UI patterns that I had heard about
<gregwhitworth> masonf: I tried to map them to an aria role
<gregwhitworth> masonf: along the top there are a few behavioral traits and positioned, transient, more than one at a time
<gregwhitworth> masonf: focus & keyboard behaviors
<una> q+
<gregwhitworth> masonf: things that are colored the same thing in the columns have similar behaviors
<gregwhitworth> masonf: the four rows on the far left that are green I think fall into a generic popup
<gregwhitworth> masonf: scottohara_ had a good idea that teaching UI may fit into a dialog usecase
<gregwhitworth> masonf: the remainder did seem to have different semantics, but the behaviors were very close
<gregwhitworth> ack una
<gregwhitworth> una: I'm a little confused
<gregwhitworth> una: I was under the impression that we would use a generic to use it as aprimitive
<gregwhitworth> una: for example to having a more generic popup and having a more concrete element
<gregwhitworth> masonf: there was rarely strong pushback that you don't need aria
<gregwhitworth> q+
<scottohara_> q+
<gregwhitworth> una: are these items going to be different but they're just going to be different aria semantics?
<gregwhitworth> masonf: I think the latter
<gregwhitworth> una: why is this different than input?
<gregwhitworth> masonf: that's brought up as the counter example
<davidluhr> q+
<gregwhitworth> una: I think it's confusing
<gregwhitworth> una: with the same functional capability
<gregwhitworth> una: that's an odd dev experience
<gregwhitworth> una: thank you for that context
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<una> gregwhitworth: would recommend going through the design systtems and component libraries we have for the ones that are basically the same outside the aria role
<una> gregwhitworth: jsut see how many design systems/component libraries produce new components for these
<una> gregwhitworth: similar stance to dominik re: ARIA -- seperate elements for each
<una> gregwhitworth: but one could also argue that you need to know to add the ARIA role as you would need to know the right component to use
<una> gregwhitworth: maybe that was a mistake that there isnt this drastic diff in semantic meaning
<una> gregwhitworth: I'm just trying to merge the two worlds bc I used to think the popup would be a generic element
<bkardell_> let me put my statement here... Input type is problematic because it changes the interface of the element itself. However, if they really do have the same surface and should never not - they could have exactly the same IDL and just be different elements with different default roles.. it doesn't seem like there is much implementation or spec level of difficulty between N elements or 1
<una> gregwhitworth: but i did expect more elements to come that leverage popup
<gregwhitworth> ack scottohara_
<gregwhitworth> scottohara_: I'm going to try and address some of those comments
<gregwhitworth> scottohara_: in a meeting that Domenic and I attended
<gregwhitworth> scottohara_: I'm definately in agreement that we need the functionality. I haven't been sold we need the element itself
<gregwhitworth> scottohara_: we need to be able to have them popup, receive focus, go on the top layer
<gregwhitworth> scottohara_: and a need for different types of sematic elements
<gregwhitworth> scottohara_: a listbox, and a datepicker have a very different functionality to them
<gregwhitworth> scottohara_: they all expose sub semantics
<gregwhitworth> q+
<gregwhitworth> scottohara_: they all work differently and expose to the AT differently
<una> q?
<gregwhitworth> scottohara_: I see it as a big loophole to not use semantic elements that they should be using
<gregwhitworth> scottohara_: they need to put aria on in order to get what they need to
<gregwhitworth> scottohara_: in order to get workarounds
<gregwhitworth> scottohara_: someone can then work around that
<una> That's fine -- i'm on board with seperate elements -- we just need to let developers know the similarities as we educate around these element and if there are any explicit differences
<gregwhitworth> masonf: datepicker is an interesting one actually
<gregwhitworth> masonf: if you look at the things with datepicker and listbox
<gregwhitworth> masonf: depends on different dimensions but they have the functionality
<gregwhitworth> masonf: aria itself puts it into the dialog generic aria role
<gregwhitworth> masonf: maybe we do want a datepicker element but unsure if we do
<gregwhitworth> una: coming from a devrel perspective I'm trying to think of the messaging
<gregwhitworth> ack davidluhr
<gregwhitworth> davidluhr: what scottohara_ was saying resonated a lot
<hdv> q+
<gregwhitworth> davidluhr: the example of divs only having slight semantic differences and the need for landmarks
<gregwhitworth> davidluhr: when it comes to semantic meanings for different elements and having different functionality
<gregwhitworth> davidluhr: even though they have some overlaps
<gregwhitworth> davidluhr: it makes sense to me to have different elements
<una> gregwhitworth: wanted to circle back on datepicker discussion
<gregwhitworth> ack gregwhitworth
<una> gregwhitworth: drastically different than listbox, i do see us needing a datepicker element
<una> gregwhitworth: 2d functionality and subparts are drastically different
<una> gregwhitworth: what we're dancing around: should popup be leveraged as behavioral generic
<una> gregwhitworth: content attributes tie that behavior
<una> gregwhitworth: top rendering could easily be a css property -- default behvaior and rendering characteristics, but the parts within them drastically change
<una> gregwhitworth: popup is outter container
<una> gregwhitworth: datepicker capabilities have spanning scenarios, which drastically changes keyboard and input nav
<una> gregwhitworth: the popup behavior i view is literally a wrapper with 4-5 primitives outlined across the top, bundled w/popup
<flackr> q+
<una> gregwhitworth: do we want to take these 4-5 primitives and come up with a few generic elements that come with it, or a way to attach these primitives to other elements? i.e. focus management
<scottohara_> q+
<una> gregwhitworth: these will by default have diff subparts in the anatomy, not associated w/popup
<davidluhr> q+
<gregwhitworth> ack hdv
<gregwhitworth> hdv: I want to echo una's point of teaching devs
<gregwhitworth> hdv: trying to teach people the different semantic needs
<gregwhitworth> hdv: I think that's the theme with aria too
<gregwhitworth> hdv: we need to figure out what is as simple as possible
<gregwhitworth> hdv: if it's hard to use then people will use it wrong and that negatively impacts end users
<gregwhitworth> hdv: I think we need to find a way to make it easy to teach
<gregwhitworth> hdv: if we want this to be successful
<gregwhitworth> masonf: the point is essentially, getting it right in the end is very important
<gregwhitworth> masonf: which in your experience is easier to teach
<gregwhitworth> masonf: one kind of element to put the right role on
<gregwhitworth> masonf: or different elements?
<gregwhitworth> hdv: it really depends on the kind of categories
<gregwhitworth> q+
<gregwhitworth> hdv: I have people that don't understand the differences between articles and sections for example
<gregwhitworth> hdv: what are they, we need to ensure that they're different
<gregwhitworth> una: to echo that - with popup you get something that's top level that popup in the future
<gregwhitworth> una: it's hard with the many options, you need to know them vs knowing that popup that can be made more semantic
<gregwhitworth> una: there's pros and cons obviously
<gregwhitworth> una: I don't think everyone is using aria roles
<gregwhitworth> masonf: the one that worries me is datepicker
<gregwhitworth> masonf: and someone wants to build a datepicker
<gregwhitworth> una: what if someone wants a shopping app
<tantek> or a date-range picker (like what someone said for flights and hotels)
<gregwhitworth> una: there are more popups than we're listing here
<gregwhitworth> una: there are very different - the utility is the same
<gregwhitworth> ack flackr
<gregwhitworth> flackr: I was on the queue for this exact thing
<gregwhitworth> flackr: is the datepicker always a popup?
<gregwhitworth> flackr: in the popup model
<gregwhitworth> flackr: if we didn't have the generic element we would have the options
<gregwhitworth> scottohara_: to respond to that
<gregwhitworth> ack scottohara_
<gregwhitworth> scottohara_: is this an attribute to allow this similar behavior
<gregwhitworth> scottohara_: or is it like the picture element?
<gregwhitworth> scottohara_: what's easier for developers?
<gregwhitworth> scottohara_: most developers are using aria incorrectly
<hdv> q+ to say can also try and list what are the actual end user 'side effects' for each of the 'types'/ roles / behaviors we're defining, what would go wrong if missing
<gregwhitworth> scottohara_: a generic role with nothing else is not to have that
<gregwhitworth> scottohara_: they would be on the hook to do all of that
<tantek> q?
<gregwhitworth> scottohara_: it is easier to implement all of it
<gregwhitworth> flackr: does a datepicker always want to be a popup
<gregwhitworth> flackr: why is it just a popup
<gregwhitworth> flackr: even menus
<gregwhitworth> s/flackr/scottohara_
<gregwhitworth> scottohara_: there are inline variants
<tantek> I think I see scottohara_'s line of questioning/issues. if we have a "plain" popup, it should have some sort of "meaningful/useful" behavior by itself (with perhaps only text content)
<una> q+
<gregwhitworth> scottohara_: the functionality of that is arrow keys but is there additional comboboxes, etc
<gregwhitworth> scottohara_: that's what I was trying to refer to earlier
<gregwhitworth> scottohara_: it's a bit more complex than that the similarities is that they popup
<gregwhitworth> masonf: it sounds like you're arguing for a generic popup
<gregwhitworth> scottohara_: I could see this an attribute that is applied to that
<gregwhitworth> scottohara_: or a picture type element that is a wrapper
<gregwhitworth> scottohara_: there is no outer semantics to it
<gregwhitworth> q?
<gregwhitworth> ack davidluhr
<hdv> q-
<gregwhitworth> davidluhr: if the interaction is the same then it's the capability. Going back to my earlier statement is a coincidental overlap but it's not garaunteed
<scottohara_> the opposition to the <picture> comparison from the last meeting was that it would be extra effort for authors to have to nest elements.
<gregwhitworth> davidluhr: if a designer chooses to have that visual affordance then that's happening to be a popup
<gregwhitworth> davidluhr: to further the conversation of having seperate tailored elements
<flackr> q+
<gregwhitworth> davidluhr: it's zero config for the developer and for beginner/advanced devs it's convenient
<gregwhitworth> davidluhr: kind of seeing as how folks treat this as a design system level rather than generics
<gregwhitworth> davidluhr: that becomes much more to configure on the other side
<bkardell_> maybe we should figure out mixins
<gregwhitworth> davidluhr: we see this where they create listbox and tooltip and then has a bunch of different configs
<una> gregwhitworth: wanted to go full circle like these things are mutually exclusive - in OpenUI from begining we had datepicker, etc. all as own components
<una> gregwhitworth: we deviated to popup bc the select means a popup, with artbitrary content -- we saw through investigations that the default ones have very basic options but it gets more complex from there
<una> gregwhitworth: i think there still needs to be a generic popup component that echoes all these primitives
<una> gregwhitworth: from the popup behavioral expecttation, i'd have select and listbox have the attribute that makes it pop up
<una> gregwhitworth: rather than having the anatomy be an element of popiup
<una> gregwhitworth: they cant be muutally exclusive - we will have more components in the future
<una> gregwhitworth: default anatomy that contains listbox that has a set of primitives applied by default
<una> gregwhitworth: need to use the slot to replace the anatomy of everything beneath it
<una> flackr: can a generic div have popup applied to it?
<una> gregwhitworth: wasnt saying popup applied to it - but has generic primitives across the top
<davidluhr> Great point about needing to dynamically change whether an element is shown as a popup. I could see responsive design considerations that would benefit from that, which would be easier with toggling an attribute than conditonally rendering a `<popup>` element that wraps other content.
<una> gregwhitworth: to unas point still think there needs to be a generic popup element, but also listbox element with meaningful defaults
<hdv> +1 to davidluhr's point!
<una> gregwhitworth: by default taking popup and applying them to listbox that has a semantic meaning
<una> gregwhitworth: removing top layer would inline it
<una> gregwhitworth: maybe it is just a popup attribute
<tantek> +1 as well to davidluhr's point. This is one of the reasons we tried (ages ago) to "solve this in CSS" rather than in HTML (changing the specific presentation of a control)
<una> masonf: everything you mentioned could also be done with a popup element
<una> masonf: can wrap it around content you'd like to popup and the content you've wrapped becomes the semantics
<una> gregwhitworth: would wrap the listbox with popup, so to replace the element i have to go in from slot level
<una> masonf: your slot would replace the popup
<davidluhr> q+
<una> gregwhitworth: if its an element, it would get wrapped with pop, popup, and listbox
<gregwhitworth> ack gregwhitworth
<una> masonf: seems like you just need to add one more element - not seeing why
<una> gregwhitworth: may need workshopping
<gregwhitworth> ack una
<gregwhitworth> una: I'm kind of with mason on this - we need a generic popup
<gregwhitworth> una: you're going to have to replace the internal content anyways
<gregwhitworth> una: it's the semantic role
<gregwhitworth> una: I'm looking at the google flights site
<gregwhitworth> una: all of them can be defined in this group
<gregwhitworth> una: there's one that is the traditional date-picker
<gregwhitworth> una: there is a price-wrap that has popups on top of the popups
<gregwhitworth> una: us in this room can not enumerate all of the types of popups
<gregwhitworth> una: to make this a component
<gregwhitworth> una: we could have a couple ehre
<gregwhitworth> *here
<gregwhitworth> una: we need a generic element wrapper
<gregwhitworth> scottohara_: quick response to that
<gregwhitworth> scottohara_: even with that multi date-picker wouldn't be a series of datepickers within a dialog
<gregwhitworth> una: isn't that more confusing since a datepicker is different than a dialog
<gregwhitworth> scottohara_: if you have a datepicker side-by-side and it wraps with a dialog then it shows the relationship
<gregwhitworth> scottohara_: how do you represent that semantic to an AT
<gregwhitworth> scottohara_: it's behaving that way
<gregwhitworth> scottohara_: those are the datepickers
<gregwhitworth> masonf: that is what we discussed last time
<gregwhitworth> masonf: popup would have different behaviors
<gregwhitworth> scottohara_: we don't need a popup to have a dialog
<gregwhitworth> una: I may be missing the semantics of dialog
<gregwhitworth> una: it is a informational to the user
<gregwhitworth> una: not for user input
<gregwhitworth> scottohara_: yes, but you can have the user feedback one be input
<gregwhitworth> q?
<gregwhitworth> masonf: it would be from the AT POV but from a behavior POV it would be different
<flackr> +1
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been flackr, gregwhitworth, davidluhr, scottohara_, hdv, una, dandclark, iopopesc, bkardell_, tantek, masonf
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2021/12/02-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye

[domenic]

It's a bit disappointing to see the discussion seems to be going in circles, continuing to revisit old ideas like using popup as a non-semantic wrapper element around more-specific semantic elements. People even continue to bring up the analogy with picture, which I tried to be clear about is not a good analogy---picture is a hack around the fact that art direction for images needs to interact with the preload scanner in a declarative and backward-compatible way, and not a precedent to be used for future features that don't have the same constraints.

I was initially really heartened to see Mason's breakdown in the spreadsheet, and interested in getting into some of the detailed discussions. Indeed, I thought the breakdown was really helpful in how it revealed the dramatically different focus behaviors, invocation behaviors, and keyboard behaviors. (The spreadsheet even understates that case, marking many things "green" which in reality behave differently and probably shouldn't be grouped together.) That made it clear to me that our previously-agreed-upon path forward of splitting this up into multiple non-overlapping elements was going to work out well, and bring utility for developers.

But if people are still coming back to trying to make a generic popup element that serves all these use cases, even three weeks after this thread started (and three months after the original concern was raised), I'm getting a bit discouraged.

It's possible I'm just not interpreting the meeting transcript correctly, and if so, I apologize! But I was hoping it would concentrate on concrete questions like "are teaching UIs a good fit for a new element or is dialog good" or "are dismiss semantics for selectmenu actually light-dismiss on all platforms or do we need to vary them per-platform" or "should we split pickers out from generic popups due to their different focus and keyboard behavior". Those would be really worthwhile questions for this group, I think!

[scottaohara]

Per @domenic's comment, I'm reading over the minutes and I want to clarify some of my points, as maybe I was unclear.

My reference to the picture element was, as my previous time bringing it up, the only way I could see popup being an element - a container that represented nothing but its allowed descendant elements, and like the picture element, not allow for aria-* attributes to be specified on it. I recall @domenic and @melanierichards not being sold on the idea (which I briefly alluded to in the IRC chat), but at the time I didn't interpret that as a flat out "no". So apologies for my misunderstanding / bringing up that line of discussion again.

However, if that comparison is not an acceptable pathway forward, then I'm at a loss for how this could be an element itself, and not an attribute (or css?) which could be applied to specific elements to indicate they can have popup behavior, e.g., listbox, datepicker, menu, - all of which would be welcome static elements that don't always need to be popped up. Or an attribute on a dialog to, for instance, provide a semantic cue / means to provide an a11y api mapping to indicate this non-modal dialog will dismiss if focus leaves it. As then AT could expose that as a hint of the element's behavior.

Deviating a bit, but concerning the idea of teaching ui and popups that largely contain static content, i.e., "more info" popups... There is a note role in ARIA that is being fleshed out a bit more in its definition, and it seems like it could possibly fit these use cases if dialog were not deemed appropriate. A note being an element that contains additional information about another element/section of content, and unlike a tooltip, could have nested interactive elements, such as links. Like elements such as listbox, it would make sense to be either static/in line with other content, or popup.

[domenic]

Thanks Scott; something about your comment really made this click for me and brought out an implicit assumption underlying much of what I've been saying.

However, if that comparison is not an acceptable pathway forward, then I'm at a loss for how this could be an element itself, and not an attribute (or css?) which could be applied to specific elements to indicate they can have popup behavior, e.g., listbox, datepicker, menu

I think this comes down to an interesting question I don't know the answer to: should a popping-up listbox be thought of as a listbox in a dialog, or as a listbox that happens to be presented in a certain way?

The most important angle from which to consider this question is from AT and AT users' expectations. That angle also connects it to the concrete technical question of whether the accessibility tree should say dialog(non-modal) > listbox or just listbox. But it's also an interesting question from the point of view of abstract semantics, and developer teachability and mental models.

If a listbox-in-a-dialog is the right model, then <popupdialog> (role=dialog) with nested <listbox> (role=listbox) makes sense. But if listbox-presented-as-popup is the right model, then <listbox popup> makes sense, and we need to proscribe people from using <popupdialog> for listboxes.

Note that for listbox we need to introduce the listbox role into the tree one way or another. For other cases Mason lists, namely teaching UI, date picker, generic picker, or "generic" popup (not really sure what these are...), the question can be approached from a different angle, since those things don't have a separate role and so should be nested inside a <dialog popup> or <popupdialog> that is responsible for setting the role.

Stated another way, I'm comfortable evolving <popupdialog>... hand-crafted code for a date picker ...</popupdialog> into <popupdialog><datepicker></datepicker></popupdialog> in the future, if we ever get around to a <datepicker> element, because to my knowledge <datepicker> does not have a dedicated role; it's really just a series of many controls each of which have their own role, and that series may or may not live inside a dialog. But evolving <popupdialog>... hand-crafted code for a listbox ...</popupdialog> into <popupdialog><listbox></listbox></popupdialog> only seems tenable if the correct model is indeed listbox-in-a-dialog, and not listbox-presented-as-popup.

My implicit assumption was that listbox-presented-as-popup was correct, which leads to the general direction of this GitHub issue: <popupdialog> could be created and used for specific cases, and proscribed for other cases. If that implicit assumption is wrong, and listbox-in-a-dialog is correct, then we could contemplate speccing and shipping <popupdialog> (or <dialog popup>) earlier than <listbox>, and not proscribing its use as a container for listbox. Probably some people will forget to use role=listbox when implementing their listbox-in-a-dialog, but that's no worse than today where they forget role=listbox when implementing their non-popping-up listboxes. The important thing is that we haven't introduced a new semantic-less element; our new element has dialog semantics.

Maybe that's been the big disconnect between me and others this whole time.

[mfreed7]

Thanks Scott; something about your comment really made this click for me and brought out an implicit assumption underlying much of what I've been saying.

However, if that comparison is not an acceptable pathway forward, then I'm at a loss for how this could be an element itself, and not an attribute (or css?) which could be applied to specific elements to indicate they can have popup behavior, e.g., listbox, datepicker, menu

I think this comes down to an interesting question I don't know the answer to: should a popping-up listbox be thought of as a listbox in a dialog, or as a listbox that happens to be presented in a certain way?

Yes. +1 to this entire post. I think I had similar thoughts, but they didn't crystalize until I read this post. Essentially, from an AT point of view, there is a difference between a listbox in the page and a pop-up listbox. One is in page, and can be navigated to/from sequentially. The pop-up listbox requires more immediate attention, since it's "in a separate window" and is meant "to prompt the user to enter" information (from role=dialog). That distinction (in-page vs dialog) is already denoted by the "dialog" role on the wrapping element. The fact that the thing is a listbox is denoted by the element with role="listbox", and that should be the same whether it sits in the page or in a popup/dialog. In other words, it makes total sense to have a wrapping element that says "my content needs more immediate attention" and a contained element that says "I'm a listbox" or "I'm an action menu" or whatever.

I also very much appreciate the comments on the evolution paths. Going from <popupdialog><div id=hand_crafted_listbox role="listbox"></popupdialog> to <popupdialog><listbox /></popupdialog> should be natural and easy for developers to understand and follow.

[scottaohara]

so using listbox as the example: for standard custom listboxes that are popups now, there is no dialog wrapper. there is an element (generally a combobox) that has an aria-haspopup=listbox and when navigating to that element, it informs the user that a popup can be invoked. so then when the user invokes said popup, they will be moved to and start interacting with the elements of the listbox. Depending on the AT there may be a listbox announcement, or you might just hear that you are interacting with options directly. Point being that there is no dialog semantics in this instance.

However, there are instances of more complex popups where say an element has aria-haspopup=dialog. This dialog then could contain a series of individual controls. a textbox and a listbox, for instance. In that situation a user would be presented with the information that they are going to invoke a dialog of some sort. focus moving to the dialog then allows them to interact with the individual controls of this more complex listbox + other component. Being that the user was informed they were going to enter a 'popup', there is then an implicit understanding that (if they are allowed to) leave the wrapping dialog, then it is likely going to dismiss.

so, per the expectations for the different types of elements, a standard popup listbox would not be expected to be contained in an element that had dialog semantics / mappings. It'd be introducing unnecessary information. A more complex series of controls / information that has popped up... that would make more sense to expose as a dialog as that's an indicator that "something is going to show up here, but it doesn't neatly fit into menu, listbox, tree or grid roles" - as are the current aria-haspopup values.

hopefully that helps clarify expectations on the a11y mapping end as well? And also are there additional roles we might need to define (e.g., formally define datepicker and standardize exactly what sub-elements are expected in such a container?), or at least need to indicate could be roles that might be expected to 'popup'.

[mfreed7]

Let's call this a):

so using listbox as the example: for standard custom listboxes that are popups now, there is no dialog wrapper. there is an element (generally a combobox) that has an aria-haspopup=listbox and when navigating to that element, it informs the user that a popup can be invoked. so then when the user invokes said popup, they will be moved to and start interacting with the elements of the listbox. Depending on the AT there may be a listbox announcement, or you might just hear that you are interacting with options directly. Point being that there is no dialog semantics in this instance.

and this b):

However, there are instances of more complex popups where say an element has aria-haspopup=dialog. This dialog then could contain a series of individual controls. a textbox and a listbox, for instance. In that situation a user would be presented with the information that they are going to invoke a dialog of some sort. focus moving to the dialog then allows them to interact with the individual controls of this more complex listbox + other component. Being that the user was informed they were going to enter a 'popup', there is then an implicit understanding that (if they are allowed to) leave the wrapping dialog, then it is likely going to dismiss.

Please help me understand this. (I'm honestly asking.) From an AT user's point of view, what is the material difference between a) navigating to an element that "informs the user that a popup can be invoked" and upon invocation, they are "moved to and start interacting with the elements of the listbox", and b) navigating to an element that presents "the information that they are going to invoke a dialog of some sort" and upon invocation lets them "interact with the individual controls of this" component?

Those seem, naively to me at least, to present the same information to the user. In both cases, they understand that something will "pop up", and typically tells them how to get it to "pop up". When invoked, they get further announcements about where they can go from there, based on what popped up. Even the use of "pop up" doesn't make sense to me for unsighted users. Conceptually, the "dialog" role is described as "an application dialog or window that separates content or UI from the rest of the web application or page." - that's about separation between the main page/flow and something "outside" the page/flow, and likely something needing more immediate attention. It seems mostly unrelated to what it contains. The "listbox" role is about content, and is described as "lists from which a user may select one or more items". So to me, <dialog><listbox></listbox></dialog> makes complete semantic sense: it describes something "separate from the main page" that contains "a list of options". On the contrary, <listbox></listbox> without the <dialog> describes an in-page list of options that I can directly interact with.

I tried out a sample page containing a <select> and a <button aria-haspopup=dialog> connected to a <dialog> element, with Chrome on a Mac, using Voiceover. Both of them show up in the Accessibility Tree as a "Combobox" (not a "listbox", even for the <select>), and both are announced to the user nearly identically. The <select> is announced as a "menu popup collapsed button", while the <button> is a "dialog popup button". Both of them then announce this identically: "to display a list of options, press Ctrl Option Space". From a user's point of view, are these materially different? I'm guessing most users get the most value from that last sentence.

[scottaohara]

i think at this point you may have gotten some of the answers you were looking for outside of this thread, @mfreed7? But to semi-quickly answer, so as to not just leave this thread / your question hanging, I will respond to hopefully clarify A vs B.

A: an element indicates it will invoke a popup - in this example, a combobox where the default expectations is a listbox. Upon encountering the combobox the user knows that it will invoke a listbox (generally), and being a listbox popup it has an expected interaction pattern. There is no need for, nor a desire, to expose a containing element role for this listbox. It's functionality is implicit by the means in which it was invoked, and people know how to interact with it per the expectations that come along with the listbox role (which does presently have variants to how it is announced depending on AT and platform).

B: an element indicates it will invoke a popup dialog. In this case the AT user is forewarned that they will encounter a dialog (but to be fair, that doesn't have to be the case (indicating exactly what type, from a limited set, of element will be popped up) and there is discussion in the ARIA WG about this topic). Invoking and then entering this dialog informs a user that there may be additional content and controls to interact with - because generally the "dialog" role that is the containing element is announced, and this serves as the clue for the user to explore the contents of it. Using a dialog to contain a single control and only that control, e.g., a listbox would be unexpected as there's no reason to need a dialog to contain solely a listbox. The dialog would just add extra noise and uncertainty.

To summarize, and per Domenic's description, A's expectation would be "listbox-presented-as-popup". We do not want a dialog (or any other container "role" to be announced if a listbox is a popup)

For example B: <popup> more than a single type of control or maybe even some static content</popup> would be the expectation. Here, we might need a role to be exposed for the containing element... maybe not in some cases... it kinda depends on what the expected functionality of the content of the popup is, and what the expectations are for containing focus within this popup would be. This is why I've been so unsure about this scenario... but per other conversations that have gone on, I'm hopeful we can have a good discussion on this next time we talk about popup.

I can add more comments on this if necessary, but i hope that at least helps clarify a bit your asks about what I was trying to indicate with A vs B.

[smhigley]

On the call, it was mentioned it would be helpful to have a list of use cases where a default dialog or group role would not be desired. These are the ones @scottaohara and I could come up with in a brief brainstorm:

• navigation menus (desired role: list)
• tooltips (desired role: none or tooltip)
• listboxes
• tree or grid as a combobox popup
• menus (specifically action menu/the menu ARIA role)
• single-form-control popups like a button that opens a volume slider in a video player (desired role: none)
• toasts -- specifically because of the on-open focus behavior of a dialog

Here are some use cases where a non-modal dialog would work:

• a non-modal dialog with mixed content that is tabbed through (this could also work with a default group role)
• dialog combobox popups, like datepicker or color picker

[melanierichards]

Thanks @smhigley and @scottaohara! This matches my expectation, and going further:

tooltips (desired role: none or tooltip)
toasts -- specifically because of the on-open focus behavior of a dialog

I would say these are not <popup>s at all due to behavioral differences, as well as the specific and narrow content model expectations for tooltip. There will be a danger of devs reaching for popup to make a tooltip or toast, so we should think about how to address that need on the platform.

[css-meeting-bot]

The Open UI Community Group just discussed Elements excluded from popupdialog usage.

The full IRC log of that discussion

<melanierichards> topic: Elements excluded from popupdialog usage
<masonf> github: https://github.com//issues/417
<davidluhr> masonf: We talked about issue 417 two weeks ago. I would like to first discuss whether we are ok with having a general purpose <popup> element
<davidluhr> masonf: In the past, some people felt it wasn't desirable, and that we should instead provide dedicated elements for different use cases.
<melanierichards> q?
<davidluhr> masonf: My main argument is there's no way to enumerate all the use cases, and we can debate whether identifiable use cases should have their own elements, but perhaps we still need a general use `<popup>`
<davidluhr> scotto: Mason and I have both spoken with Aaron/Erin (sp?) and one of the issues that came up is the role might be mapped to dialog
<davidluhr> scotto: If popup has generic role, or role of group that's ignored by assistive technology, then sure, the general purpose element might be useful for use cases we haven't defined yet
<davidluhr> scotto: Is interaction model supposed to be, select menu opens, and then dialog role has options, or does select menu open a listbox? If it needs to be an element, it needs a role. If it has a generic role, then it's much more benign, but that doesn't resolve the concern that we don't want to have a generic role.
<davidluhr> scotto: What does popup represent? We can work on accessibility mapping to make sure it's not exposed when it shouldn't be for listboxes, menus, etc., then I wouldn't have a problem with it.
<davidluhr> scotto: But I don't know how a generic role fits in with HTML
<melanierichards> q?
<masonf> q?
<tantek> q?
<tantek> q+
<davidluhr> masonf: Those are good points. It's a good point that there's a distinction between the HTML semantics and the accessibility role for AT users. Dominic seemed happy with the semantics of a non-modal dialog.
<davidluhr> masonf: Dominic was ok with having 2 elements that mapped to the same semantics.
<davatron5000> +1 for general purpose.
<davidluhr> scotto: If it doesn't make sense for dialog to wrap things like listbox, and we need something more benign, then fine. As long as we can figure out how to sell it as a generic element.
<davidluhr> tantek: This is an interesting edge case where a group like Open UI is doing some needed innovation beyond incremental improvements.
<davidluhr> tantek: General culture of HTML maintenance is strong incrementalism
<davidluhr> tantek: There might be some clash there. This group is coming up with stuff that should land in HTML. Our lens of how generic or specific is important.
<melanierichards> q+
<sarah_higley_> q+
<davidluhr> tantek: Avoiding generic HTML elements because they've gone unused is valid. Like `<section>`. How do we avoid creating another `<section>`?
<scotto> q+
<davidluhr> tantek: It seems like `<popup>` has use cases. Let's try some building block elements to see how developers use them rather than avoiding them completely.
<hdv> q?
<hdv> ack tantek
<hdv> ack mel
<davidluhr> melanierichards: We have a suite of popup-y things, and we said we can splinter some off into use-case driven elements.
<una> q+
<davidluhr> melanierichards: Is it a modifier of dialog or something truly new? It might be more specific to table the generic for now and make progress on more specific use cases.
<tantek> I would support the methodology that melanierichards is proposing
<davidluhr> melanierichards: Generic popup would be much further in the future. If we can meet specific use cases, and still see need for generic, then that might be helpful.
<melanierichards> q?
<davidluhr> sarah_higley_: Semantics can be tangential to behavior. With listbox, options can be popup or inline, but functionality remains the same.
<davidluhr> sarah_higley_: If there's intention to build this like a listbox or tree element, or even table, should we avoid having duplicate roles like listbox, listbox-popup?
<davidluhr> sarah_higley_: It makes more sense to attach popup functionality to something with a specific role/purpose, rather than having to wrap something like a listbox with a popup.
<sarah_higley_> ack me
<davidluhr> scotto: To Sarah's point, we'll need the static items, whether they go into a generic popup or not.
<masonf> q+
<davidluhr> scotto: I'm also in favor of the attribute. I want to make sure something can move forward. If we can focus on listbox and make that pop up some how, then great.
<davidluhr> una: I'd be opposed to focus on specifics without considering generic popup. When discussing listbox, we always come up with use case that can't be done without generic.
<melanierichards> q?
<davidluhr> una: We're still not resolving basis of what we're trying to do. If we introduce generic we have to make sure it'd still work with the 6 other specifics.
<tantek> Una's point is a good one. Architecturally we don't want to paint ourselves in a corner with specifics.
<melanierichards> q- scotto
<melanierichards> q- una
<davidluhr> una: If we have specifics, then offer generic later, then people will use tailored versions to try and achieve other use cases.
<davidluhr> una: Devs will have to know difference between sub-types of popup and it was confusing. There needs to be very clear distinction between them.
<davidluhr> una: Best solution seems to be having a generic that you can attach attributes or ARIA to.
<sarah_higley_> q+
<davidluhr> una: We can't separate idea of trying to move forward with more specific components from having a general use popup.
<davidluhr> masonf: +1 to what Una said.
<melanierichards> q+
<hdv> +1 to Una's point that there needs to be a clear way to distinguish so that developers are in a better position to pick the one they need
<davidluhr> masonf: Generic first, or generic last? Generic first makes the most sense, since there are more use cases. We should learn as much as we can from generic first.
<davidluhr> masonf: If we introduce listbox first, and it has attractive behaviors, devs are going to grab it for generic use cases and miss-use it.
<tantek> Misuse a specific element for other purposes? That's a good point to put on the table ;)
<davidluhr> masonf: I don't think we need listbox and listbox popup. If we determine listboxes make sense whether popup or not, that sounds like an attribute on listbox.
<davidluhr> masonf: We've determined functionality for top layer, dismiss, focus management, etc. I don't know if all those make sense if you can attach this as an attribute to anything.
<davidluhr> masonf: It's a lot harder to manage focus with top layer if it can be attached to any other element.
<davidluhr> masonf: As Una said, I'm stronger and stronger for having generic.
<tantek> the "popup" attribute on everything is giving me flashbacks of XHTML2 "src" attribute on everything
<davatron5000> Question: Is <popupdialog role="listbox"> something we couldn't support?
<davidluhr> masonf: I'm sort of ok having text that says the generic shouldn't be used for certain use cases, but it makes sense to start there first.
<melanierichards> q?
<melanierichards> q- masonf
<melanierichards> q- sarah_higley_
<davidluhr> sarah_higley_: Everything Una and Mason said makes sense to me. The semantics still concern me.
<una> q+
<davidluhr> sarah_higley_: I want to get rid of idea that there's general-purpose accessibility semantics that would be useful here.
<davidluhr> sarah_higley_: Adding dialog role to lots of use cases would be harmful and produce weird screen reader behaviors.
<davidluhr> sarah_higley_: Dialog role as a default, is really worrying. If it's generic element and HTML is cool with it having generic role. But if it's dialog or even role="group", it's going to be wrong well over half the time.
<hdv> q+
<davidluhr> sarah_higley_: If WG are cool with div-type semantics, that makes sense from an accessibility perspective, but if it needs meaningful semantics, there are no default ARIA attributes that'd work here.
<melanierichards> q?
<davidluhr> masonf: Some accessibility folks felt `role="group"` would be less helpful? What do you think?
<scotto> sorry, had to step away
<davidluhr> sarah_higley_: I agree, it'd be less harmful. But, it can result in extra verbosity, especially in a double group scenario.
<davidluhr> sarah_higley_: For something like combobox, you don't want a group around the listbox, for sure.
<davidluhr> sarah_higley_: I don't know if it'd interfere with combobox navigation. It may have potential to introduce bugs with many layers of different roles.
<davidluhr> sarah_higley_: It's the same problem with a dropdown menu.
<davidluhr> melanierichards: And we know the combobox pattern has changed 3 times.
<sarah_higley_> ack me
<tantek> the "group" role thing is somewhat reminding me of <fieldset> and how much of a pain it has been
<davidluhr> melanierichards: What I don't want us to lose sight of is the big motivation behind popup is the first place.
<davidluhr> melanierichards: How to support popup support within the listbox control. I'd like to work on generic and specific in parallel. We need a customizable select.
<davidluhr> melanierichards: We want to keep sight of both to create something sustainable, extensible, makes sense for the future.
<davidluhr> melanierichards: We have a set of specific popups that should have tailored semantics. Another subset would benefit from dialog mapping.
<BoCupp> q 4 Melanie: what's the problem with having a customizable select if we introduce a generic popup? Can't the selectmenu element put the right roles on its parts?
<davidluhr> melanierichards: Having both a generic and more specific elements still seems useful.
<davidluhr> q+
<davidluhr> melanierichards: What are thoughts on having generic to show that it's top layer to AT users, and having more specific elements?
<melanierichards> q- melanierichards
<davidluhr> una: I want to speak to Sarah's points. I agree that dialog isn't right role for most use cases.
<davidluhr> una: I think it shows why we need something more generic so they don't use something not meant for the use case.
<davidluhr> una: I think of it similar to a div and landmark elements. You can get more specific with why you created a section of content. Popup is that, but with the UI of appearing in an isolated layer, and then disappearing.
<melanierichards> q?
<melanierichards> q- una
<davidluhr> una: There's room to make it general purpose while communicating the expected interactions.
<davidluhr> scotto: How do you communicate that experience if it's just a generic?
<davidluhr> scotto: It needs to announce expected interactions.
<davidluhr> una: Is it possible to announce that you're entering isolated experience?
<davidluhr> scotto: Yes, it would be a dialog.
<davidluhr> scotto: If you want to have focus trap experience, that's a dialog right now. We'd need to introduce subset of that to have something like "dismiss" or make sure the element indicates that some sort of popup will show up.
<davidluhr> scotto: And contents of popup would need to inform user how it'd work.
<davidluhr> scotto: Combobox generally communicates that a listbox will pop up, which sets expectations for arrow keys, tab to dismiss.
<melanierichards> q?
<davidluhr> scotto: Issue with generic is how does someone know to interact with that content? It could be anything, like multiple listboxes, a datepicker. How do you inform someone how to interact in one use case vs. the other? For example, pressing tab too much dismisses something and now you have to get back to it.
<davidluhr> scotto: Having a generic without more defined role can be difficult.
<davidluhr> scotto: If it's a listbox, we just need a listbox role, we need popup to not get in the way.
<masonf> q+
<davidluhr> scotto: For a variety of use cases, that does sound more like a dialog.
<davidluhr> scotto: To Mason's point, it's a more benign role if it's not named.
<davidluhr> una: That was helpful, thank you.
<davidluhr> hdv: As a summary, we need really good documentation. People get really confused using ARIA, and they use it wrong all the time.
<davidluhr> hdv: All this stuff is in ARIA and in AT. We might end up porting that confusion to HTML. Can we fix it by coming up with something generic that needs ARIA? Or, can we provide more specific things and explain how to use them?
<sarah_higley_> q+
<davidluhr> hdv: We don't have that situation now, and we may not have it with new HTML.
<tantek> are these three examples of "generic" popups? https://twitter.com/slicknet/status/1097584328962240512
<melanierichards> q?
<melanierichards> q-
<melanierichards> q- hdv
<hdv> davidluhr: important to acknowledge some of these use cases may be displayed as a popup, that's almost like a presentational aspect of it
<hdv> davidluhr: the presentation may just be an enhancement to that pattern, but the most important thing is to keep the interaction the same
<hdv> davidluhr: keyboard navigation between some of these use cases should probably be the same so that it is easier for users and specifically assistive tech users
<hdv> davidluhr: that things can appear as a popup is kind of accidental
<davidluhr> masonf: I wanted to respond to what Scott said.
<davidluhr> masonf: We're caught up in what is the role of a generic, vs. should there even be one.
<davidluhr> masonf: I brought up dialog because of color picker and datepicker. AT user needs to know if they're tabbing around dialog that has collection of stuff inside, it's important to know if tabbing closing something.
<davidluhr> masonf: Maybe how we're doing tab trapping needs to change?
<davidluhr> masonf: Color picker and datepicker are good use cases for popup. They're transient, ARIA points to datepicker as example of using `dialog` role.
<davidluhr> masonf: We need to determine the semantics, and then list the uses cases that it would work with. Then, we can see what use cases wouldn't be well suited for this.
<tantek> GDPR/CCPA notices/consent?
<davidluhr> masonf: We should do a generic, that doesn't mean can't also do a listbox. I want to avoid only doing listbox, and doing the generic later.
<davidluhr> sarah_higley_: We don't have good semantics or interaction patterns for non-modal dialog. I'm excited for popup because maybe it'd be less bad.
<davidluhr> sarah_higley_: It might be hard to define generic popup because even most generic use cases don't have defined semantics or behavior even without this element.
<davidluhr> sarah_higley_: There was intention to have inert attribute. I'm curious about what people think about having an element and part of the functionality being broken off into an attribute?
<davidluhr> melanierichards: That'd be good to file an issue for. Clearly we have more discussion. Going back to Mason's issue, if we're going to make a generic thing, what use cases shouldn't be cover, and then we can come back to those use cases?
<davidluhr> masonf: What are the roles that should be precluded? If people can think about that, that'd be helpful.
<melanierichards> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2021/12/16-openui-minutes.html melanierichards
<melanierichards> Zakim, end meeting
<Zakim> As of this point the attendees have been tantek, hdv, melanierichards, masonf, dandclark, scotto, iopopesc, una, BoCupp
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2021/12/16-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, melanierichards; please remember to excuse RRSAgent. Goodbye
<melanierichards> RRSAgent, please part
<RRSAgent> I see no action items
<tantek> I'd like a generic pop-up element so I can block them :P

[mfreed7]

Thanks for the good discussion on this issue today.

Refining the lists provided above, during the last few meeting conversations, and in the OP, it is sounding like:

---

Not for use with <popup>:

• toasts (focus behavior, show/hide behavior, etc. all different from <popup>)
• tooltips (focus behavior, show/hide behavior, etc. all different from <popup>)
• teaching UI (light dismiss does not apply - this looks behaviorally like a <dialog>)

These are more specific UI patterns for which there should be either a separate element (e.g. <listbox>), or for which role=Xyz should be used to correctly set the role:

• listbox (role=listbox)
• navigation menu (role=list)
• action menu (role=menu)
• tree* (role=tree)
• grid* (role=grid)

These are more specific UI patterns for which role=dialog seems correct:

• date picker
• color picker
• other generic "complex" pickers

These are more specific UI patterns for which role=dialog might not apply, and for which role=none or role=group might be better:

• single-form-control popups* (e.g. button that opens just a volume slider)

*I could use some clarification on these. @smhigley, would it be possible to point to specific examples on the web for these? I know what an in-page tree or grid looks like, but I'm trying to better understand the use case for a popup that is just a tree or grid with no other controls. Also, for the single-form-control popups, it would be good to see a "good" example of this as well, to see what the right role should be. Don't these typically come with a few other buttons like at least "Mute"? And in that case, aren't they dialogs?

---

I am starting to get worried that we're not moving toward a solution. If we're unable to come to a consensus on a way forward for this "popup-like" functionality, developers will be stuck using <div>s appended as the last child of <body> with z-index:99999 and a lot of Javascript to get these behaviors. That does not sound terrifically semantic or accessible to me. I'm really hoping we can come to some sort of compromise on this issue, to improve this situation for everyone!

[domenic]

or for which role=Xyz should be used to correctly set the role:

Recall that we cannot introduce a new HTML element which is intended to be used with the role ARIA attribute, per discussions here and in previous threads about how doing so violates the first rule of ARIA. So these elements would need to be in the proscribed list for the popupdialog element.

I agree that it's not clear where this is going, since I saw such pushback in the minutes against our previous agreement to use the dialog role, and only use popupdialog for cases where that is appropriate. It might be time to step back and start considering more outside-the-box solutions, such as CSS or JS primitives. The element approach seems overconstrained between some people's desire for a multi-purpose element and the requirements of HTML language design and accessibility which make such generic elements a bad idea. CSS and JS APIs don't have such constraints and so for those who want a multi-purpose tool (which seems to include you, Mason) they are probably the right path forward.

[scottaohara]

can't link to a real world example, being behind a login, but here's the apg example of grid popup - no wrapping dialog. similarly with a treeview. we have them at microsoft for some comboboxes that have nested levels of available options to them.

an example of a volume slider that can 'popup' when invoked by a button. a cable company i contracted for had one of these that visually looked more complex, but was merely just a single range slider that was heavily styled and light dismissed when focus left. no need for a dialog as that'd just add unnecessary verbosity to a simple control.

Other examples of something like this, which would likely more benefit from popup functionality, would be similar slider controls related to zooming in/out/rotating web-based 3d rendering UI. This would be particularly helpful in context of zoomed in interfaces where standard css positioning might be fine for a larger screen use case, but in the context of a UI zooming up to 400% to meet reflow criteria, UI can be collapsed to ensure that as much workspace is available as possible.

in other words, the ability to make something 'popup' via CSS/JS, rather than requiring an element would be far more conducive to responsive UI, as specifically requiring an element container that exposed an unnecessary role would be unfortunate in either situation.

[gregwhitworth]

It might be time to step back and start considering more outside-the-box solutions, such as CSS or JS primitives.

I wanted to drop in here and second this. I would like to use the <selectmenu> as a concrete example of why I feel this way. If we look at the extensible model that Open UI is built on then we result with the following initial anatomy:

<selectmenu>
    <slot name="button-container">
         <button></button>
    </slot>
   <slot name="listbox-container">
         <listbox>
            <slot>
                <opt-group>
                    <option>
                </opt-group>
            </slot>
         </listbox>
   </slot>
</selectmenu>

In order to add popup functionality with only an element we have to wrap the listbox with popup. Like so:

<selectmenu>
    <slot name="button-container">
         <button></button>
    </slot>
   <slot name="listbox-container">
        <popup>
             <listbox>
                  <slot>
                      <opt-group>
                           <option>
                     </opt-group>
                 </slot>
              </listbox>
         </popup>
   </slot>
</selectmenu>

So now if a developer wants to adjust the listbox to be inline we'll have to replace the markup via a slot when technically they don't have any desire to actually change content model but the rendering. Now I understand that popup comes with additional behaviors as well. But the above is not a good DX, in my opinion. As such I'd recommend that we have them as primitives AND a general element that leverages those primitives. I'm leaning towards CSS as content attributes would result in the same issue described above unless we provide a way for declarative attribute reflection/modification for known children in a shadow DOM but this would complicate slotting etc and be a mess.

So then the UA CSS would look like this:

listbox, popup {
    display: popup
}

This would enable an author to adjust listbox to be inline via adjusting the display value and they wouldn't loose any other controller functionality of a listbox but would remove the behaviors that are required for the generic popup usecases.

I think this aligns with the focusgroup approach outlined by @travisleithead here, and one can then imagine focustrap, dismiss, type primitives. I don't want to boil the ocean here however and solely align on the correct model that we can continue to add to as developer need warrants the investment in unlocking more primitives. This aligns also with @LeaVerou feedback in the tag review.

I'm interested in your thoughts @dandclark since you're actively working on the selectmenu and of course @mfreed7 and @melanierichards

[mfreed7]

Since it sounds like there’s a relatively strong response that this feature should be turned into either an HTML attribute or a CSS property, I have two questions:

1. Just to confirm, neither <div showaspopup> nor <div style=“display:popup”> would have any accessibility implications. Is that correct?
2. Is the WHATWG’s requirement that all new elements be “semantic” purely accessibility related? Or is it just “related”, in that the words used to describe the semantics for a new element should have a roughly-corresponding ARIA role?

[scottaohara]

Retracting my comment here, as the more I think about this, I don't think my comment about being restrictive about particular elements makes sense. I'd support either providing popup functionality through attributes or CSS/JS.

Would there potentially be a11y implications to doing it this way? Sure. But no more so than there are presently a11y implications to using current HTML global attributes or CSS/JS in ways that aren't beneficial for accessibility. There are likely some safe fallbacks that could be mapped for generic elements to make them less likely to be problematic.

But providing these features via attributes/css would likely allow for more flexibility for authors than if restricted to a single element (which as I've mentioned before, would not always expose the expected semantics desired, depending on the content/component(s) it contained). Authors could even apply such attribute/css/js logic to current z-index hack implementations, rather than completely refactor to use an element that would still require polyfills for older browsers.

Not speaking for WHATWG here, but from my perspective from my other accessibility work / ARIA WG member, not all semantic HTML elements have strong accessibility semantics, nor do their semantic definition have to relate to a specific ARIA role. I'm going to pause on going any further on this topic for now though.

[jonathantneal]

Ahoy 👋

This issue is labelled for discussion in the next teleconference. @mfreed7, as an editor of the proposal and the creator of this issue, would you be available and interested in discussing this in the teleconference for additional feedback?

If so, would this week or next week would best for you? Or was this issue already discussed? I’m unsure.

I’m unsure of its status, also, because I have read thru #455, and it seems like there’s an alternative approach that may or may not negate this. Again, I’m unsure.

[mfreed7]

I think it's safe to close this issue, as it relates to the "old" <popup> element proposal.