Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
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
Thanks, this is really helpful information! I'll take a look into those resources.
In the meantime, hopefully the autocomplete is at least not disruptive for users of ATs? Assuming you don't accidentally press the up/down/enter keys while the autocomplete is active, it should be fairly non-intrustive.
I considered trying to detect ATs and remove it entirely, but then I read this post by Léonie Watson (another toot.cafe user