<select> popup naming

[gregwhitworth]

Hey everyone,

I've done analysis across both dropdowns and select components from the naming matrix of the sub parts (not just the top level names). You can see it here

Here is my initial proposal:

• select
  • button
  • popup
    • optgroup
      • option

The main one I'd like to discuss right now is dialog. I considered a few different names, all of them have pros/cons. Listed in order of my preference.

• dialog: This effectively represents what this container is. It is a non-modal dialog in the majority of use cases for a select. There are two negatives:
  • There already is an HTML dialog element which wouldn't be a problem but it is marred by accessibility issues and as such hasn't been widely adopted. It also has the open state on the dialog, which makes sense but the select will need this state as well. This is less of a problem but we should ensure that if open is set on the dialog then this propagates to the <select> as well.
  • Dialog does imply appearance. While the majority of cases it is a dialog, in a multiple state it may be set in page and isn't shown above other content (the inherent expectation of a dialog).
• popup: This has the same negative as dialogue in the sense that it implies appearance. This doesn't have the bug burden of dialog however. Another benefit is that within ARIA they have aria-haspopup which select will need in relation to this container anyways so the naming is consistent here.
• listbox: This wasn't used by a single framework as the name for this container but it is specifically what this container is per the definition in ARIA . That said, the listbox is also what the <select> overall is and so resolving the duplicity of the two seems complicated.
• menu: This bubbled up primarily in frameworks that combine their <select> with <dropdown> menus. This isn't a bad name but the menu element already exists and semantically means that it is a generic list of items, usually a menu with links for example.
• datalist: @chrisdholt brought this one up and it's a good one. The datalist element currently does what this container is doing which is to contain options and show them in a popup/dialog. Only negative I can see is the naming but I'd need to look at the implementation and potential API implications.

NOTE: I'm not 100% sold on button either even though from invocation perspective that's exactly how it behaves in the frameworks and across UAs. It does allow for traversal even in a closed state so I'm open to other naming suggestions for that as well.

[chrisdholt]

Great writeup @gregwhitworth - I know that native platform controls for inputs (such as next, number, etc) include a "list" attribute which is the id of a <datalist> element within the document. I wonder if that should be considered here as well? Although, it may have some of the complications listed above.

My primary concern with using "dialog" here is that I would likely never use an actual dialog to compose this which creates somewhat of a mental block in my mind. It doesn't mean I can't get over it, it just seems like a very odd use case (would we expect a role of dialog on this?). Regarding those which imply appearance - I think these likely feel a bit more intuitive, but that's likely primarily because we often default to appearance when describing parts of controls.

I'm somewhat partial to listbox here. If we were to remove the button from the equation to invoke the select and it was simply persistent element, we would have a listbox. From a purely "what it is" standpoint, I think that makes the most sense to me but I understand the complications this presents based on the fact that the select (with "button") is also a listbox.

[gregwhitworth]

@chrisdholt valid feedback regarding datalist and that could be leveraged here and is overall solving the same problem so I do think it should be added, I'll add it in.

I'm intrigued at this statement:

My primary concern with using "dialog" here is that I would likely never use an actual dialog to compose this which creates somewhat of a mental block in my mind.

Why is that? When I go over to most of the definitions across frameworks for their dialogue it means a window that pops above content. Most have some way of denoting either modal or not.

I'm somewhat partial to listbox here

Same here, I actually had a mockup with listbox in there but the more I thought about it the more confusing it seemed to me since a select is a listbox. It would be like nesting <select>(s).

[chrisdholt]

@gregwhitworth I think the primary reason is that often times as frameworks we're trying to get as close to replicating the behavior of the native control as possible. We've had quite a bit of feedback to this extent from our accessibility teams. The expectation is that it is read as and behaves just like a listbox as that is what select is. If I were to add a layer in there for dialog, that would create issues with AT - especially if I were to place my select inside a dialog. Then as an AT user I might hear that I've entered a dialog and now another has been invoked and I'm then moved to a listbox. That's primarily the rabbit trail my head goes down.

In the case of listbox, I think the real culprit here is the button because on the platform the entire control is conveyed as a listbox and not a button + listbox. The button provides a great convenience by making the listbox transient for sighted users, but when I'm navigating through via keyboard I don't necessarily get that context - it's just a listbox. It kind of feels like the entire problem with nesting selects is due to the fact there is a button :)

[hober]

I don't have a strong opinion about the name of the thing that contains optgroups. That said, the term should be generic enough that it applies to existing <select> controls on popular platforms (including iOS, whose <select> is pretty distinct).

[zcorpan]

https://w3c.github.io/aria-practices/#combobox might be useful for this. A <select> is called a select-only combobox by aria-practices:

If a combobox does not support text input, it is referred to as select-only, meaning the only way users can set a value is by selecting a value in the popup.

It further uses "button" and "popup" for terminology, though the popup can be of the roles listbox, grid, tree, or dialog.

The ARIA structure for a combobox is:

• role=combobox aria-controls=foo
• role=button aria-controls=foo
• role=listbox id=foo (the popup)
  • role=option
  • ...

That is, the combobox, button and popup are siblings. This structure was changed from ARIA 1.0, where comboboxes used aria-owns (or containment) instead of aria-controls. See w3c/aria#1051

I don't know if the anatomy here needs to match the ARIA anatomy?

[gregwhitworth]

Thanks @zcorpan - our anatomies are matching currently as the popup and the button are siblings and ARIA ironically is where I got both listbox & popup from. For now I'm going to leave the button labeled as such.

Ultimately, it seems that we go full circle however in that all of them are technically valid.

[LJWatson]

It's worth mentioning that screen readers do not recognise the button that appears as part of a <select> element's visual presentation. From a screen reader user's point of view there is a single thing identified as a "combobox" that has options that can be navigated and selected using the up/down arrow keys.

AFAIK none of the ARIA combobox variants exactly duplicate this experience for screen reader users.

[gregwhitworth]

@LJWatson Thanks for the feedback. I'd have no expectation that the anatomy will have any impacts on the way in which a combobox is consumed by an AT and for the user. Technically under the hood we already have these parts and I'd expect the experience to remain the same as they are today even with their definition. Especially for already standardized components we have a built in expectation that we not regress the experience, only improve it. Sounds like as long as we retain the functionality from an AT perspective then you're ok with the proposed addition in structure and naming?