RE: Allowed values of aria-autocomplete for the combobox role

Select with @multiple is a listbox. Without is a combobox.
Windows also has comboboxes where you can't type, only select from pre-defined values. (side note, personally, I find "combobox" to be a not-great word for this control, but it's been called that for a long, long time). These don't have autocomplete.

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Tuesday, December 1, 2015 10:46 AM
To: Cynthia Shelly <cyns@microsoft.com>; Matt King <a11ythinker@gmail.com>; 'PF' <public-pfwg@w3.org>
Subject: RE: Allowed values of aria-autocomplete for the combobox role

> What about a combobox that acts like a <select> ? Those don't have autocomplete.

That sounds like a standard role=listbox?

I guess one possible use case for keeping this though is if you have an edit field that might sometimes be enabled for autosuggest and sometimes not. Though the role can't be changed, the value of aria-autocomplete can be to reflect when this is the case.

I don't really understand the difference between inline or both, inline makes sense to me since it would update the value of the field that has focus when pressing Up/Down, but what does both mean?

While I'm on this thread, I didn't see an answer when I asked about this before, so I'll rase this here again.

What do people think about adding aria-valuetext as a supported attribute of role=combobox and mapping this to the Value property in the accessibility tree? Currently only HTML input fields do this automatically, but this is impossible to achieve on simulated elements such as Div or Span elements because there is no way to explicitly set a combobox value.

Also, have we agreed that aria-controls should be used to associate a combobox with the accompanying Listbox and not aria-owns? The use of aria-controls makes more sense, because HTML input fields cannot support children when aria-owns is set, especially if the accessibility tree is adjusted to reflect changes using aria-owns.

From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Tuesday, December 01, 2015 9:48 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'PF' <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Subject: RE: Allowed values of aria-autocomplete for the combobox role

What about a combobox that acts like a <select> ? Those don't have autocomplete.

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Wednesday, November 25, 2015 11:02 PM
To: 'PF' <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Subject: Allowed values of aria-autocomplete for the combobox role

I am working on issue 610, which involves writing a new description for the combobox role -- something I have wanted to improve for a very long time!

There is one part of the current role description that I have never understood. I believe it should be removed, but perhaps, just maybe, there is a rational explaination for it. It is this text:

"If an author sets a combobox's value of aria-autocomplete to 'none' (default), authors must manage and set focus on the associated listbox, so assistive technologies can follow the currently selected value."

The part that does not make sense to me is the notion that a combobox could ever have autocomplete set to none, especially if there are values in an associated list that assistive technologies would need to track. The very definition of autocomplete none is that there are no input completion suggestions provided. Well then, what are the values in the list???

Since, by definition,  a combobox always has an associated list, it seems to me that the allowed values of autocomplete should not include none, even if the list is empty or collapsed.

My burning question is under what circumstances would it be appropriate to set autocomplete to none on a combobox?

So far, the only rationale I have dreamed up is that autocomplete dynamically changes based on whether the list is populated and displayed. But, if it is not populated and not displayed, then there are no options for the AT to track. Further, there would be no point in using aria-expanded if aria-autocomplete is intended to serve this purpose.

A question almost as perplexing is under what conditions would autocomplete inline be used instead of autocomplete both? If the value in the text field is being completed inline from values displayed in a listbox, then autocomplete should be set to both. Again, remember that by definition, a combobox always has a list.

It seems to me that the allowed values for autocomplete on a combobox should include only list and both.

Thanks,
Matt King