Update 'combobox' spec as per html spec/html-aam mapping for <select> element

[iamrafan]

The current combobox spec says

Combobox is a composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.

It states a combobox always requires a textbox as a child, except when role combobox is used on input elements

The ARIA 1.0 specification describes a combobox pattern where a text input element has the combobox role and owns a listbox element. User agents, assistive technologies, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.

But

• the latest HTML spec for <select> element says <select> acts as both combobox and listbox based on multiple & size attributes
• the html-aam for <select> also maps it to both combobox and listbox

I think we should update the combobox spec to not require a textbox always or we need to explicitly mention what is expected when <select> element acts a combobox

[accdc]

A readonly combobox is indeed valid, as can be seen here:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm

[stes-acc]

Absolutely. We have this frequently in our UI's.

[carmacleod]

The read-only combobox discussion starting with this comment in the aria-practices issue tracker may be relevant here.

[mcking65]

We will fix this issue by fixing w3c/html-aam#46. On the ARIA side, that means resolving #721 and #722 and then making a new version of the APG collapsable listbox example. This plan is documented in this comment I made on August 3, 2018 to html-aam issue 46.

The net of what things will look like after this plan is complete is:

1. A combobox will still always has a textbox.
2. A combobox may still contain a read-only textbox.
3. In an ARIA 1.1 combobox, the textbox will remain a child of the combobox element.
4. In an ARIA 1.0 combobox, the textbox will still have the combobox role and own the listbox.
5. An HTML:select@size=1 will be a collapsable listbox.
6. An HTML:select@size=2+ will remain a listbox that is not collapsable, i.e., will not include aria-expanded in the mapping.

After we land #721 and #722, we can make a new version of the APG collapsable listbox example that recasts the button element as the collapsed listbox. That will both resolve several of the issues raised in w3c/aria-practices#557 and serve as an example of a custom ARIA version of HTML:select@size=1.

I should get moving on these issues. They are lingering far too long.

Given that resolving this specific issue does not require changes to the combobox role in ARIA, i think we should close this as overcome by #721 and #722.

[carmacleod]

@mcking65

A combobox will still always have a textbox.
A combobox may still contain a read-only textbox.
In an ARIA 1.0 combobox, the textbox will still have the combobox role and own the listbox.

Please see @accdc's ARIA 1.0 simulated readonly combobox.

This combobox does not have a textbox. It doesn't need one, because it's read-only, so the user does not type the combobox value - they use the list to change the value.

It is implemented using a span (styled to look like a button), and all of the combobox markup, focus and behavior is on that span.

This combobox works well in the screen reader/browser pairings that I tried. So I don't think we should say it has to be a popup list, because it is a working combobox pattern that has existed since 1.0 and has been implemented in AT, and it would be a shame to drop it.

I have a similar use case, which is a read-only combobox that pops up a dialog. The markup is similar, except that it has aria-haspopup="dialog" and it does not use aria-activedescendant. It works best with 1.0 markup, because if I force it to have a fake textbox child, then that child needs a label, and it needs to take focus, and the event handling needs to move to the child, and suddenly all that's left is a textbox that does not work properly with AT because they don't see it as part of a combobox.

So in conclusion, I think we have to allow for read-only combobox to not have a textbox.

We should also describe clearly what a "read-only combobox" is and what it is not, because there seems to be some confusion. It is not disabled. If it was disabled, it would have aria-disabled="true". A combobox has a value, and its owned listbox, tree, grid, or dialog can dynamically pop up to help the user set the value of the combobox (not textbox). If the combobox is not read-only, then it can also have a single line textbox, and the user can type the combobox value into the textbox directly.

[zcorpan]

#1051 is merged.