A small addition: it could also help to select the correct WAI ARIA roles for the elements, i.e.
<ulrole="listbox"><lirole="option">
...
</ul>
Another minor thing: I prefer to use global event handlers (document.addEventListener(...)) and filter the event target after their attributes in the handler if I deal with plain vanilla JS; this way, you can even asynchronously add more of those elements and don't need to add events every time you add a custom select box. Obviously, using a toolkit or framework like React, Angular, Vue or similar, you get the events basically for free.
I'm a self-taught Front End & JS Dev and professional learner with accessibility expertise. I'm passionate about breaking down concepts into relatable concepts, making it more approachable.
For example, it lists that the ul is the one to receive focus, and that the li items are not tabbable per se, but aria-activedescendant on the ul marks the candidate selection. There different ways to do things, of course, which is why I like documents there. The discussion of those patterns on Github has also taught me much about accessibility :)
Something else that I am reminded of, Scott Jehl from Filament Group had an article a while back about styling the native select element. It has some fun stuff: filamentgroup.com/lab/select-css.html
(There was a comment below that mentioned all this replacement seeming tedious, but I find it fascinating how much gets exposed to assistive tehcnologies out of the box)
One more thing I forgot to mention. You should also ensure that the functionality on different screen sizes works. Imagine a country list with 100+ countries and a web app that cuts of at the bottom of the screen. A maximum height of your options list with overflow: auto; will help, but doesn't solve all edge cases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A small addition: it could also help to select the correct WAI ARIA roles for the elements, i.e.
Another minor thing: I prefer to use global event handlers (
document.addEventListener(...)
) and filter the event target after their attributes in the handler if I deal with plain vanilla JS; this way, you can even asynchronously add more of those elements and don't need to add events every time you add a custom select box. Obviously, using a toolkit or framework like React, Angular, Vue or similar, you get the events basically for free.oh i like the addition of roles here.
As an addition, when recreating some of the native (or more complex) interactive widgets, I find the WAI-ARIA Authoring Practices a great read.
They offer a list of the expected behaviour (for focus, keyboard etc.), as well as the roles and examples of alternative implementations.
iirc,
<select>
in this case falls under a "Listbox" patternFor example, it lists that the
ul
is the one to receive focus, and that theli
items are not tabbable per se, butaria-activedescendant
on theul
marks the candidate selection. There different ways to do things, of course, which is why I like documents there. The discussion of those patterns on Github has also taught me much about accessibility :)Something else that I am reminded of, Scott Jehl from Filament Group had an article a while back about styling the native
select
element. It has some fun stuff:filamentgroup.com/lab/select-css.html
(There was a comment below that mentioned all this replacement seeming tedious, but I find it fascinating how much gets exposed to assistive tehcnologies out of the box)
One more thing I forgot to mention. You should also ensure that the functionality on different screen sizes works. Imagine a country list with 100+ countries and a web app that cuts of at the bottom of the screen. A maximum height of your options list with overflow: auto; will help, but doesn't solve all edge cases.