I definitely agree that the UX is worse when it comes to keyboard access in 4.0.0 (with this issue). I also would love to see a fix for this that doesn't restart
the problem cycle we had before and have actually reopened the issue (forgot that I closed it) while we determine the best way to handle the issue.
Select2 is designed to be a replacement for select boxes, so if there is a poor user experience (when compared to standard select boxes) it's something we want to improve. We've addressed one UX issue in this thread so far, are there any others that may have been overlooked that might need to be addressed?
I've
posted the key sequences for native selects as well as Select2 3.5.2 and 4.0.0 for selecting an option, which makes it very clear what the impact of this issue is. Right now this isn't as much of an issue for those using Select2 with a mouse, because clicking on the select will open it and automatically focus the search box. But for keyboard users, the keyboard is not opened until either the enter or space key is pressed. These keys were selected because they are the common keys for opening the dropdown and they did not conflict at all when doing accessibility testing.
And while writing this I thought of a possible partial solution.
What if the dropdown was automatically opened when the select was focused? In order to avoid breaking the standard tab order (as tab currently closes the dropdown), the tab key would also need to be intercepted such that it moves the focus to the next item when the dropdown is already opened.
This still wouldn't fix the UX issue if the dropdown is closed for some reason, but there is another partial solution there: Just opening the dropdown when any letter is pressed and the dropdown is closed. Keep in mind that this is step 1 in the cycle of events that caused this current UX issue.
Does anyone else have a recommendation for how the UX could be improved here?
Kevin Brown