Autocompletion dropdown should be accessible · Issue #129 · nolanlawson/pinafore

Comments

Oh yes, the lovely autocompletes. I was about to file an issue for it when I saw that you had beat me to it.

Unfortunately, the spec you link to is working technically, but from a usability standpoint difficult. Keyboard interaction, and more so, screen readers and accessibility APIs don't have a concept of multiple focus points at the same time. But conceptually, this is exactly what an autocomplete is: You have the cursor in the input, and the selected/highlighted autocomplete item at the same time. The only implementation that @jcsteh and I know is the Windows 10 (Fall Creators Update) start menu autocomplete. The cursor stays in the search field, and through announcements, the screen reader speaks the currently highlighted item. You can cursor up and down, Enter selects the item you want.

The examples given in the spec and in many other places use aria-activedescendant, taking the keyboard focus away from the input field, and you have to then deal with the focus shifting back and forth between the entry and list items.

The one I like most so far is this. It was mentioned in a nice presentation last year.

For stuff to feel like Windows 10, the approach would be different. You'd visually keep track of the focused item, implement all the keyboard interaction, but not do the ARIA dance with aria-activedescendant and all that, but keep the focus in the input all the time, and just shove the text into an offscreen div with aria-live="polite". You'd make up the text, for your examples, like "Nolan, @[email protected]", or whatever you feel appropriate for emojis. One web app that implements it this way is IRCCloud in their CTRL+K quick switcher.