support automatic selection about combobox-nav HOT 10 CLOSED

I believe this was resolved by #57 (two years later 🐌). If anyone disagrees, please feel free to reopen.

from combobox-nav.

Hey @jscholes– This behavior was added in #22 to address your feedback at #22 (comment), specifically:

With the list expanded and an option focused, attempting to type an addition to the search string seems to do nothing for a screen reader user. The character(s) are reflected in the input's value, but focus doesn't return to it so SR users won't know that this has happened.

I see that the "automatic selection" pattern is no longer present for the ARIA 1.2 Authoring Practices (the link in the original comment was to ARIA 1.1). Given what we already know about problematic nature of 1.1, I want to double check with you– Do you know if this was intentional, and that combobox shouldn't have an automatic selection behavior?

from combobox-nav.

@muan it looks like it is still present in the 1.2 link you posted:

3. List autocomplete with automatic selection: The combobox is editable, and when the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the combobox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the combobox.

from combobox-nav.

@muan When a user is browsing the list items and updates the value of the input (by typing, cut, backspace, etc.), their focus must still be returned to the input field. Otherwise, a screen reader can't perform its cursor/value change tracking appropriately, and users must fight to find their way back to the input because they can't just use Left/Right to moved through what they've typed.

In other words, my comment re: nothing seeming to happen for a screen reader user would still apply.

from combobox-nav.

As an aside, if focus doesn't move back to the input, it risks inconsistencies in the impact of a user's keystrokes. E.g. if I'm focused on an item, and typing a particular letter causes the item to disappear, what should the behaviour be? We could say it should move to the first item, but what if no more items remain? Then it would need to return to the input. Returning to the input every time avoids such confusion, because overall, maintaining a user's position within a changing dataset is quite a challenge.

from combobox-nav.

@katblag ah thanks, I missed as I was looking at the examples here: https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-autocomplete-list.html

However I noticed a distinction– the part you quoted is for list autocomplete with automatic selection, where user value is expected to be replaced by the selection value. But that's not the case for the search results, in the sense that the search results aren't all prefixed by input.value like an autocomplete list would.

@jscholes what do you think about this use case requested then? I believe you might have been talking to this team already (@cpruitt) so might have more context than I do as I haven't been following that thread. My understanding is the search combobox selects to the first item whenever the list updates (input changes).

The issue was prompted by the desire to opt out of combobox-nav's selection clearing (selection is "focus" via activedescendant in this case) on user input, because this causes in a visible flash. The flash is a result of combobox-nav clearing activedescedant and the custom behavior re-selecting on the first item again immediately.

Sounds to me that automatically selecting the first item isn't accessible to begin with?

from combobox-nav.

@muan There's a lot to unpack here. The new global search isn't currently accessible full-stop, because items can't be navigated/selected with the arrow keys. So this accessibility guidance based on it should be read with that in mind.

At a higher level, it's fair to say that combo boxes that "force" the user to stay inside the list box virtually at all times (unless there are absolutely no matches) should be avoided. I use the word "force" because sure, you can get out of it again and back to the input if you know how. But not everybody knows how, and opting to move into the available options should always be a user choice. Autocomplete exists exactly for this reason, so a developer can surface a default completed value and let the user review other ones at their leisure.

In the case of global search, there will always be at least one suggestion. I can paste in the text of a paragraph from a novel and there will always be the option of searching all of GitHub for that text, even if there were no suggestions. I haven't yet decided how that should best be surfaced.

Even though we're still in the testing phase for the search component, I have a strong feeling that auto-selection of the first item (or rather, using the first item to convey what will happen when you press Enter even though it doesn't exactly match the user's text) will be something we flag as needing reconsideration. Not sure if that has any impact on this issue?

from combobox-nav.

CC-ing @sinabahram so he can follow along with this branch of the global search discussion.

from combobox-nav.

I have a strong feeling that auto-selection of the first item ... will be something we flag as needing reconsideration. Not sure if that has any impact on this issue?

If auto-selection is removed then I believe this issue can be closed.

from combobox-nav.

สนับสนุนการเลือกอัตโนมัติ

from combobox-nav.