Autocomplete and accessibility

A Web Developer based in Belgium, specialized in PHP & JS development
Search for a command to run...

A Web Developer based in Belgium, specialized in PHP & JS development
In the meantime, turns out this is well documented :-) not sure documentation works in real life, but the updated library now has everything for accessibility :-)
I recently needed to collect all changes in one file for reporting purposes. Found this article: https://ratfactor.com/cards/git-diff-with-new-files In case you need something similar on Windows, here

Some projects start with a grand plan. Others start because you just need to read a file without thinking too much about it. That was the case for spread-compat. I needed a common interface for CSV, X

With modern css, you can almost get rid of sass. But there is one last pain point : media queries. Not being able to use variables or an easy, common syntax for typical breakpoints is really annoying. That is, until you meet Media Queries Level 5. I’...

This is a quick article to share this demo I just made. https://codepen.io/lekoalabe/pen/JoPNWpX

Modals are typical UI elements for many web apps. There are countless packages dedicated to that specific features, each framework creating its own variation. Popular frameworks like Bootstrap also have custom code to deal with it. But all this feels...

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.
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.
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.
If you are curious, here is a demo of the new library
You can also head to the repo
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