Autocomplete and accessibility

Since I created my Bootstrap Tags library, I realized that it also contained most of what was needed to create an Autocomplete library. I gave it a try with some much-needed code refactoring and while creating the library, I stumbled upon an interesting issue.

To tab or not to tab

The issue is the following: while you type, you show suggestions. The focus is still in the input field, and yet, you should somehow show to the user what is the currently matched suggestion (I'm using bg-primary to show this). I cannot use hover styles, because you can hover a proposal, and yet, change suggestions with the arrow key. I cannot use the focus styles, because they don't exist as a pseudo class (and I really want to avoid any extra css for my library). Also, focus styles are ugly :-)

But the, I realized that when pressing tab, I was moving the focus to the suggestions. At first, it seemed like a great idea: this way, users can tab through proposals. And at the same time, it also seems like a really bad idea: because users need to tab through all proposals to move to the next input field.

Tab vs arrow keys

I wondered: how does behave a native datalist ? Turns out: you need to use arrow keys to move through proposals, and tab move you to the next element. So I decided to do just that: I added a tabindex=-1 and it works fine. You can still use arrow keys as before to move through suggestions.

But is it accessible? How would the user know which proposal is selected if he is blind? I guess I can use Live Regions but I'm not sure how well that is supported (sometimes, the specs are wonderful, but real life isn't).

At least, with tabs, you know for sure that when focusing an element, it will get announced. I'm still on the fence regarding this, but I will definitely investigate and make sure it's working as intended for version 1.1.

Full demo

If you are curious, here is a demo of the new library

You can also head to the repo

Extra tip: using regions

Since I didn't want to split my library into multiple files, but still keep it manageable, I discovered the region/endregion syntax in vs code that allows to collapse/expand whole section of code. It also helps to keep your code structured and grouped in a meaningful way.

// #region REGION_NAME_HERE

... some code

// #endregion