Select element's default role of "listbox" is odd

[carmacleod]

The default role for the select element in the spec is "listbox". This has an odd feel to it, because it behaves a lot more like a "read-only combobox" from desktop days.

The ARIA in HTML spec says the same as the HTML spec:

HTML language feature	Implicit ARIA semantics - should not be used	ARIA roles, states and properties which may be used
select	role=listbox	Role: menu, global aria-* attributes and any aria-*  attributes applicable to the listbox or menu role.

The Accessibility API Mappings document recommends either listbox or combobox for select:

1. "select (with a multiple attribute or size attribute having value greater than 1)"
   https://w3c.github.io/html-aam/#el-select-listbox
   http://w3c.github.io/aria/core-aam/core-aam.html#role-map-listbox
2. "select (with NO multiple attribute and NO size attribute having value greater than 1)"
   https://w3c.github.io/html-aam/#el-select-combobox
   http://w3c.github.io/aria/core-aam/core-aam.html#role-map-combobox

So a plain-old select (with no multiple or size > 1 attributes) really should have a default role of "combobox".

An additional inconsistency is that Mac calls it a "popup menu".

There seems to be some "fuzziness" around what select should map to, and what a "read-only combobox" should be, as noted in this ARIA Authoring Practices Guide issue.

Would be nice to have consistency across all the specs/docs. Starting with the HTML spec, I think that it should say the following (precedent for the sentence format is in some of the input element specs, i.e. type=search, tel, url):

Allowed ARIA role attribute values:
combobox with no multiple attribute or size attribute having value greater than 1 (default - do not set) or with multiple attribute or size attribute having value greater than 1: listbox (default - do not set) or menu.

[tyronem]

I had a form with a select that was dynamically assigned an aria-describedby (for form validation). While using VoiceOver on macOS Sierra, the select was read back as a menu item, and the associated content that contained the error would not be read by VoiceOver. Once I added a role of listbox to the select, VoiceOver read back the associated content.

VoiceOver on an iPhone running OS 10 does not behave this way. It feels strange to assign a role to a select dropdown - it is semantically correct, but VO ignores all aria-labelledby and aria-describedby tags unless you add a role of listbox or combobox to it.

[LJWatson]

Ping @joanmarie, @jasonkiss, @stevefaulkner

[SiTaggart]

Yeah, I'll plus one this +1.

It seems to be quite a strange change by making listbox the default role of a select element, where it's been identified as a combobox by assistive technology (on a PC at least), in web and Desktop software, for so long.

I get that a multiple select would have a default role of listbox as it seems visually and functionally appropriate.

Just seems that instructing AT vendors to change its identification of default select inputs to a listbox, would cause a jarring experience for users, where millions of websites they've used forever, suddenly have listboxes instead of comboboxes. Plus the same looking type of control would identify differently, between native and web apps? would that not be strange for sighted, AT users?

[mcking65]

I agree with the general sentiment of this thread that we need to resolve some issues with consistency across platforms. However, as a screen reader user who has for decades been frustrated by the vagueries caused by the inconsistent use of terms, I disagree with the technical solution proposed here.

In fact, I propose just the opposite mapping in w3c/html-aam#46.

Keep in mind that the most important thing the ARIA role does is communicate an interaction pattern. And, the most important recipient of that information is the assistive technology. It is then the responsibility of the assistive technology to make the cryptic role identifier with its associated states and properties understandable to the user.

The purpose of the ARIA mappings is not to describe visual styling or presentation. That said, it is helpful to certain categories of users if the styling used on an element does not directly conflict with the general sense of the type of element communicated by the role.

HTML select@size=1 and select@size=2 have exactly the same functions and keyboard interaction. The primary difference of @size=1 defaulting to a collapsed state does not impact keyboard operation or the functionality provided. In both cases, browsers implement the type of interaction associated with a single-select listbox as described in the ARIA listbox pattern. Because the interaction patterns are the same, I am certain there will not be any issues with elements like the category selector on amazon.com changing from a combo to a listbox; it already works like a listbox even though some screen readers call it a combobox.

So, fixing the HTML mapping of select so it is always listbox, regardless of presentation, will at least stop screen readers from calling elements that do not have combobox features from being called comboboxes. And, if we add aria-expanded to listbox, we could even accurately represent the difference between @size=1 and @size=2. That is something we could potentially do in ARIA 1.2 given that it is focused on HTML mapping parity.

BTW, at least in ARIA, which is what we are mapping to HTML, a combobox is defined as the combination of a textbox and an associated popup. HTML selects do not have any textbox functionality.

The other way of making a single select is what you often see on Mac; it is a button whose label changes depending on the selected value. These elements are perfectly described by the ARIA menu button pattern. In this case, you have a button with aria-haspopup set to "menu", which is the same as "true" in ARIA 1.0. Then, the button opens a menu that contains either menuitemcheckbox elements or menuitemradio elements. The item the user chooses becomes the selected value, which also labels the button after the item is activated and the menu closes.

The most confusing issue, though, and one legacy effect that I am dieing to make history is the screen reader announcement of elements that Carolyn is talking about ... I almost hesitate to say the words ... readonly combobox. Fortunately, controls like this are few and far between.

What do you think most screen reader users think when they hear "read only"? They think the control is read only, meaning you cannot change its value. Since an HTML select is significantly different from this kind of control, I think the solution to this is unrelated to this issue. I am hoping to someday soon gather the right people around a table and figure out a good way of tackling that one. In the meantime, it is easy to build one by simply implementing the ARIA combobox pattern and adding aria-readonly="true" to the textbox element.

Finally, as much of this is addressed in the combobox design pattern I have just finished drafting for the ARIA Authoring Practices, please read that and provide feedback.

[SiTaggart]

Sure, I get it. On paper, technically speaking the dreaded "readonly combobox" feels and interacts in a way that is essentially identical to a listbox. I don't feel that means we get to discount it as being a thing, though. For example, you write:

Fortunately, controls like this are few and far between.

I can't disagree more. Folks hate the way a select element looks, and it's always one the first components to be added to a web app UI library, at least in my past and current experiences building component and design systems. There are literally hundreds of open source select like components out there, that don't have type ahead functionality, that shouldn't allow us to make sweeping statements that they don't exist in the real world.

So that leads me to the question of how would you implement something like that if we pretend a readonly combobox, select element replacement, doesn't exist. You hint at replicating the OSX approach of using a menu button, which works fine for those folks on OSX as voice over announces both select and menu buttons as "popup buttons". But for those folks on Windows, I feel you'd be misleading them entirely, as a menu button should take an action on the page, not set a value in a form to persist in a back end. It's an inappropriate component for the job.

That kind of leaves a listbox, but again, I've sat down with a colleague and we can't for the life of us think of a way to manipulate a listbox to look like a select element with a collapsed and expanded state, with an always visible "trigger" with the currently set value.

Suggestions? I'm all ears.

Another thing I'd like to raise if we're going to diverge from calling select and select like widgets, not comboboxes anymore, is the experience folks who use AT but have some sort of vision, will have. For those folks using a Windows machine, they'd be able to see a native combobox in native desktop software, announced as a combobox, and see the exact same looking component on a webpage announced as a listbox or menu button. That to me seems confusing, and somewhat conflicting to what I feel the original idea of ARIA was supposed to achieve, which was a parity, familiar or as near identical experience when transitioning between desktop software and complex web applications.

I'm sure there's some guideline by the W3C (wish I could find it again) somewhere that essentially says "user experience over technical detail", and I feel we're leaning heavily to technically correct answers here.

[mcking65]

@SiTaggart commented

I'm sure there's some guideline by the W3C (wish I could find it again) somewhere that essentially says "user experience over technical detail", and I feel we're leaning heavily to technically correct answers here.

User experience is my number one concern. It is the focus of nearly all my work inside and outside of W3C.

With the way we designed ARIA 1.x, which is admitteddly more practical than ideal, our ability to design and build great user experiences for people relying on assistive technologies depends on ARIA roles reliably representing interaction models.

Sure, I get it. On paper, technically speaking the dreaded "readonly combobox" feels and interacts in a way that is essentially identical to a listbox. I don't feel that means we get to discount it as being a thing, though. For example, you write:

Fortunately, controls like this are few and far between.

I can't disagree more. Folks hate the way a  select  element looks, and it's always one the first components to be added to a web app UI library, at least in my past and current experiences building component and design systems.

Ya, agree. I meant the implementations of select-like thingies that actually include a textbox that is announced as read-only by a screen reader are few and far between. There are pockets of space where they are very common because of a specific toolkit, but the vast majority behave more like an HTML select when accessed with one of the popular screen readers.

So that leads me to the question of how would you implement something like that if we pretend a readonly combobox,select  element replacement, doesn't exist.

There are several good ways. It's worth saying first, though, that it is important that we not let ARIA and accessibility unnecessarily box designers and engineers. That said, there is no perfect way with today's ARIA to create the flavor of this kind of element that includes a read-only text field with a caret that can be used for selecting text and possibly deleting the value of the field. We can make that flavor, but it will have the severe downside of being announced as a "read-only combobox" or something similar.

You hint at replicating the OSX approach of using a menu button, which works fine for those folks on OSX as voice over announces both  select  and menu buttons as "popup buttons". But for those folks on Windows, I feel you'd be misleading them entirely, as a menu button should take an action on the page, not set a value in a form to persist in a back end. It's an inappropriate component for the job.

I don't agree that such an implementation is inappropriate or misleads Windows users.

1. Menus with menuitems that change values are prevalent on all platforms. In Windows, consider the spell check option in the context menu of Firefox, The Firefox view menu, many color pickers on Windows, the format menu in Notepad, etc.
2. Regardless of native precedence, the purpose of the ARIA role is to communicate the interaction model, not the purpose of the component. The label of the component communicates its purpose.

The menu button pattern can perfectly communicate the interaction model for select widgets regardless of platform.

That kind of leaves a listbox, but again, I've sat down with a colleague and we can't for the life of us think of a way to manipulate a listbox to look like a  select  element with a collapsed and expanded state, with an always visible "trigger" with the currently set value.

While the listbox pattern lacks one of the beneficial escape key behaviors that the menu button affords, it is an equally viable approach. I wonder what is tripping you up. Simply build the component you describe and then give it the listbox role. As long as your component has the interaction model, roles, states, and properties that are associated with the listbox pattern, it is a listbox. Basically, make it work exactly like HTML select@size=1.

Then, you need only two enhancements to the typical listbox pattern as currently described in the ARIA Authoring Practices. First, add a non-focusable, interactive icon next to the listbox that serves as your clickable expansion element. Then, whenever the list is expanded to show more than the current value, set aria-expanded to true; have it be false otherwise.

I guess we should build this for the ARIA Authoring Practices. The current listbox pattern is at:
http://w3c.github.io/aria-practices/#Listbox

Another thing I'd like to raise if we're going to diverge from calling  select  and  select  like widgets, not comboboxes anymore, is the experience folks who use AT but have some sort of vision, will have. For those folks using a Windows machine, they'd be able to see a native combobox in native desktop software, announced as a combobox, and see the exact same looking component on a webpage announced as a listbox or menu button. That to me seems confusing, and somewhat conflicting to what I feel the original idea of ARIA was supposed to achieve, which was a parity, familiar or as near identical experience when transitioning between desktop software and complex web applications.

I agree that we want ARIA to help people use GUIs on the web by making them feel native.

I would not recommend styling a web component like a select or native combobox and then calling it a menu button. If you are going to use the menu button pattern, it should most definitely look like a button that opens a menu.

On the other hand, if you are going to style like some kind of field with a dropdown list, those type of things in native Windows are not all comboboxes. They very well could be a listbox or an edit with a popup or some type of split button. What is more important than appearance is that the assistive technology knows how to help the euser operate the thing. But, if you want to go there, I would love to see more consistency on Windows and maybe someday have agreement that native Windows Comboboxes are components that include both an edit field and a popup. What is more likely, though, is that ARIA 2.0 will support some type of control pattern model so that assistive technologies need not depend so heavily on element roles.

[stevefaulkner]

So a plain-old select (with no multiple or size > 1 attributes) really should have a default role of "combobox".
the listing of the listbox role for select in this state is a bug in the ARIA in HTML spec. Fixed via w3c/html-aria@e0a988a
need to update HTML spec to match, then will close this issue

[stevefaulkner]

HTML spec update 8ec3037 fixes this

[hax]

I am caught by this issue, and I totally agree with @mcking65 . It's confusing for web front-end programmers to understand why html select element is mapping to combobox. And "readonly combobox" is a very bad term. Most will expect the whole widget is readonly but it seems in the context of this issue it means the textbox of the combobox is readonly but the listbox of the combobox is not readonly. This is very confusing.