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

> Seems like there shouldn't be a textbox and the widget should
> instead be a listbox with standard listbox type-ahead selection.

There is one use case that needs to be brought up, which is when focus is set to a readonly triggering element A, which activates Listbox B, but focus never moves away from triggering element A. However triggering element A is just a div or span.

This can only be made accessible using role=combobox on triggering element A to allow the correct widget modality for screen reader users, and the use of aria-activedescendant to reference the highlighted Option within the Listbox as the arrow keys are used when the Listbox is open.

This requires aria-autocomplete="list", but I wanted to make the point that a Combobox doesn't actually have to have an edit field to be a Combobox.

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

I think a widget that has a textbox, a list, and acts like a select would be a combobox with autocomplete set to list.

Can you describe a widget that acts like a select, has a textbox, and does not have autocomplete? A select has a list and allows only selection of a value from that list. A combobox has a textbox and a list. If typing in the textbox of such a widget doesn't either complete inline based on values in the list or narrow the list and allow selection from the list, then what is the purpose of the textbox? Seems like there shouldn't be a textbox and the widget should instead be a listbox with standard listbox type-ahead selection.

Matt

From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Tuesday, December 1, 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