Is aria-expanded not supported by the searchbox role?

[Anschur]

Hi! I've been working an a search box with a suggestion popup, where I have applied the role="combobox". I recently realized that the role="searchbox" is probably more fitting. But on closer inspection it seems that aria-expanded attribute is not supported for this role. Searchbox is not listed as a role supported by aria-expanded, and aria-expanded is not listed as inherited state and properties of the searchbox role, but it is required for the combobox role. The searchbox role do support aria-controls, aria-haspopup and aria-owns. Should the role then not also support to indicate the the controlled popup is expanded?

If this is not the correct forum for this question, please point me in the right direction.

[JAWS-test]

If your search box behaves like a combobox, it should be marked with role=combobox instead of searchbox.
If your search box only has autocomplete, aria-expanded is not needed.

It may also be possible to modify the ARIA specification to allow a searchbox to act as a combobox. This would need to be discussed at https://github.com/w3c/aria

[JAWS-test]

Related: #681

[Anschur]

Thanks for your reply @JAWS-test .Yes, it behaves as a combobox in that it has a popup with suggestions below the search box as you type (autocomplete="list"). I'm using the keyboard navigation in the combobox pattern using the aria-activedecendant (supported by searchbox). But screen readers will not identify it as a search box, and I'm currently using the aria-label to inform users of that.
I'm not sure what you mean with "...only has autocomplete" - if using inline autocomplete I see no need for aria-expanded, but with autocomplete="list" I think there is a need as the list is only accessible when expanded (and could also be empty). Do you mean there is no need for aria-expanded independent of the type of autocomplete?

[JAWS-test]

In my opinion there is an important difference between combobox and autocomplete, which is unfortunately often not considered, so that there are many implementations on the web that are badly usable with screen readers, see w3c/aria-practices#1134 (comment).

If no list of values can be opened without text input, but only after text input, then it is not a combobox. Unfortunately, there are no attributes that indicate the fade-in of the list for a textbox or searchbox. Therefore, a live region is usually used for this, see: https://jqueryui.com/autocomplete/

[Anschur]

Our search box will usually display suggestions without text input (zero term suggestions), but it depends what suggestions providers are configured and previous actions of the users. But it is not a filtering of a limited number of entries as mentioned in #1134 (comment).
We are relying on aria-live to inform on the number and types of suggestions, but thanks for the tip.
I thought I could apply the role="searchbox" to make it a more specific combobox for search, but that doesn't seem to be the case. I still think it makes sense to follow the combobox pattern for interaction, but I'm not sure what role would be most useful for the end user (or if it would have any significant impact on the experience). And I do find it strange that the searchbox role doesn't support aria-expanded.

[JAWS-test]

This sounds like a edge case: an autocomplete function that displays suggestions without text input. I would advocate not marking it with role=combobox, but as an autocomplete list. If per live region the presence of list entries is output, this should be sufficient.

[Anschur]

Zero term suggestions for search boxes are not uncommon, so it is not an edge case in that sense. When I click in an empty search box on google.com I get suggestions from/related to recent searches. They are using role="combobox" for their search box - but I'm not advocating doing the same just because it is highly used search box.

[jnurthen]

There is certainly a spec issue here:

• aria-autocomplete is supported on combobox, textbox and searchbox
• aria-autocomplete says: "When an element has aria-autocomplete set to list or both, authors SHOULD use the aria-expanded state to communicate whether the element that presents the suggestion collection is displayed."
• aria-expanded is NOT supported on textbox or searchbox

If all of this is correct then the only values which should be allowed for aria-autocomplete on textbox and searchbox are inline or none. If this is correct then we should state this explicitly in the description of aria-autocomplete.

Otherwise aria-expanded should be supported on textbox/searchbox.

[JAWS-test]

If all of this is correct then the only values which should be allowed for aria-autocomplete on textbox and searchbox are inline or none. If this is correct then we should state this explicitly in the description of aria-autocomplete.

textbox and searchbox should not allow only autocomplete=inline/none - otherwise many web pages would be invalid. Most autocompletes use list or both. Thus, the following should be implemented:

aria-expanded should be supported on textbox/searchbox.