Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autocompletion dropdown should be accessible #129

Closed
nolanlawson opened this issue Apr 15, 2018 · 3 comments · Fixed by #1183

Comments

@nolanlawson
Copy link
Owner

@nolanlawson nolanlawson commented Apr 15, 2018

Right now the username/emoji autocompletion dropdown is just set to aria-hidden because I wasn't sure how to make it accessible. Probably some guidelines in https://www.w3.org/TR/wai-aria-practices-1.1/ could help here.

@MarcoZehe

This comment has been minimized.

Copy link

@MarcoZehe MarcoZehe commented Apr 17, 2018

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, @nolan@toot.cafe", or whatever you feel appropriate for emojis. One web app that implements it this way is IRCCloud in their CTRL+K quick switcher.

@nolanlawson

This comment has been minimized.

Copy link
Owner Author

@nolanlawson nolanlawson commented Apr 17, 2018

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 😊) and decided against it.

@MarcoZehe

This comment has been minimized.

Copy link

@MarcoZehe MarcoZehe commented Apr 17, 2018

nolanlawson added a commit that referenced this issue May 6, 2019
fixes #129
nolanlawson added a commit that referenced this issue May 6, 2019
* fix: make autosuggestion accessible

fixes #129

* remove tabindexes, fix aria-hidden
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.