Extending guidance for comboboxes that use searchbox role

[0ddfell0w]

Is there anything worth specifying re:ARIA 1.1 comboboxes that use role=searchbox in the text field?

For example:
What should happen when there are no results? Should there be an item in the tree/grid/dialog that conveys the lack of results?

[patrickhlauke]

my understanding (which may or may not be accurate) was that type="search" inputs are no different from regular text inputs, and may only trigger some kind of default visual presentation in browsers (plus some browsers may offer, as their own built-in autocomplete suggestions, values that have been entered in other search inputs on the same site/on different sites, but that's their own prerogative)

https://www.w3.org/TR/html53/sec-forms.html#text-typetext-state-and-search-state-typesearch

[JAWS-test]

What should happen when there are no results?

I think that with every combobox (regardless of the role of the input field) the absence of results should be noticeable, because the combobox implies that you can navigate to the list entries with arrow keys. If there is no message about the absence, the user thinks that

• the search for entries is still running or
• there is a functional error or
• entries are displayed, but are not perceptible due to incorrect implementation with assistive technology (which happens very often with the screenreader)

I.e. even if the specification does not require this, ARIA practice should recommend to also notify the lack of entries.

[mcking65]

This issue is related to w3c/aria#742.

At TPAC on either Sep 16 or 17, the ARIA WG will discuss a whole host of fundamental combobox issues. I am working on organizing that discussion. You can see the list of issues in this comment I made to ARIA issue 1001.

I led work to improve the description and structure of combobox in ARIA 1.1. It was challenging -- to say the least. The work spanned more than a year. There were a lot of compromises. Unfortunately, while I was initially optomistic about the ARIA 1.1 combobox pattern, it has proven to be a nearly complete flop. While the supporting changes to aria-autocomplete, aria-haspopup, aria-controls, and aria-activedescendant have proven worthwhile, the compromises we made within the combobox description itself are not working. Assistive technologies still have not caught up. Support is pretty much non-existent. And, there are still fundamental questions surrounding what screen reader support ought to be like.

There are several members of ARIA WG that are hoping to make changes in ARIA 1.2 that would claw back most of the confusing changes made to the combobox description in ARIA 1.1. We want one, simpler pattern. We know it already works with most screen readers and most browsers. Essentially, use the ARIA 1.0 pattern except replace aria-owns with aria-controls.

If this happens, the combobox role would always be on the text input. In that case, the searchbox role would never be part of the pattern -- there would not be anywhere to put it.

In practice, if a searchbox acts like a combobox, what should a screen reader call it? Do users who know what comboboxes are always expect a searchbox to act like a combobox? Not all searchbox elements do. If it is announced as a combobox to communicate behavior, then why use the searchbox role? BTW, an HTML search input with a list attribute is an ARIA combobox.

From discussion to-date, the ARIA practices task force does not yet have a sufficiently clear understanding of the intended use of the searchbox role to provide guidance for its use. It could be that you would only use it if you are creating a web view that is intended to exactly mirror a native iOS screen that includes a text input with the search trait. That, however, is just a guess. If anyone has real world examples where they believe use of the searchbox role is valuable, please share them.

My inclination is that the searchbox role does not add any value to a search field that acts like a combobox. This is especially the case if the search field is inside a search region and also has an accessible name that includes the word "search." Of course, one could still use the searchbox role instead of the combobox role on a combobox that is for search. In that case, it would be announced as a searchbox, and perhaps the combination of the aria-autocomplete value and the aria-haspopup value would give screen readers a way to describe the behavior to the user. Personally, I think that is just one more way to confuse users who already have too many different types of control names flung at them by their screen readers. They would then need to learn that some searchboxes are just a simple text box where there are no suggestions available while typing and others supply suggestions or even results that you can scroll through without even going to a search results screen. But all that is my own view; I'm not speaking for the practices task force.

[mcking65]

@JAWS-test commented:

What should happen when there are no results?

I think that with every combobox (regardless of the role of the input field) the absence of results should be noticeable, because the combobox implies that you can navigate to the list entries with arrow keys. If there is no message about the absence, the user thinks that

• the search for entries is still running or
• there is a functional error or
• entries are displayed, but are not perceptible due to incorrect implementation with assistive technology (which happens very often with the screenreader)

I.e. even if the specification does not require this, ARIA practice should recommend to also notify the lack of entries.

The combobox pattern provides all the information needed for a screen reader to not only tell the user when results are available but how many are available. There is a lot of information available that screen readers are simply not using.

As described in the read me first section, In the APG, we are very careful to be describing how ARIA should be used, assuming that it is properly supported by browsers and assistive technologies. APG patterns intentionally do not compensate for browser or screen reader bugs. If they did, they would be useless as reference implementations for improving ARIA support.

When using APG patterns in the real world, it is essential that authors test with targeted technologies to be sure that the experience they are building meets their expectations.

Eventually, I hope in the next year, the w3c/aria-at project will supply information about support levels when using popular screen reader and browser combinations. The hope is that this will not only help authors know which patterns to adjust or avoid but also help assistive technology developers provide higher quality support.

[JAWS-test]

@mcking65
I thought the question of @0ddfell0w was a general question, not related to a specific implementation in ARIA practices. My answer was therefore of a general nature. My first two reasons are not about the assistive technology, but for the good usability for all users. Only the last reason concerns assistive technology.

You wrote about it:

The combobox pattern provides all the information needed for a screen reader to not only tell the user when results are available but how many are available. There is a lot of information available that screen readers are simply not using.

However, I do not see e.g. at https://rawgit.com/w3c/aria-practices/apg-1.2/examples/combobox/aria1.1pattern/listbox-combo.html where this information, which I addressed, is available. I can't find it in the source code (in the form of live regions or other ARIA attributes) or visually. I.e. with the screenreader it is not noticeable whether there are entries, how many there are or whether there are none. In my opinion this is not a mistake of the screenreader, but of the implementation. I also don't think it's necessarily an error, because the combobox role implies that there are or could be list entries. It would only be my recommendation that a message is displayed and output by the screenreader (via live region) when a text input leads to no entries. This is especially important for comboboxes that do not allow free text input. These are often implemented in such a way that the entered value is simply deleted after leaving with Tab, if no value was selected from the list. However, blind users do not even notice the deletion. I.e. a blind user sends the form with the certainty of having filled it out completely, the comboboxes are sent empty. Unfortunately, I encounter such comboboxes implementations very frequently in my accessibility test. It would therefore be good for all users if the absence of list entries were noticeable.

[mcking65]

@JAWS-test, if there are no suggestions, the combobox is collapsed. There are state change events for that. If the combobox is expanded, the screen reader knows that and knows how many suggestions are available.

[mcking65]

With merge of #1250, searchbox is no longer a possible part of the combobox pattern. So, closing this issue.