Custom selects are one of the more contraversial components in accessibility. In this presentation, I will go over the reasons why it may not be avoidable and show you how to build one won’t get you in trouble.
Just like carousels and parallax scrolling, creating a custom select widget is one of a few cardinal sins in accessibility. The general guidance is, “DON’T DO IT! Just use a native select, since accessibility is already built in.” This is mostly good advice, if all you need is to provide an exclusive selection out of a list of options in a compact way, native select is definitely the way to go. But what if that is not enough? In this presentation, I will lead you down my path of engineering a custom select and discuss the reasons it was necessary.
I will start with the valid reasons as to why custom select widgets are so infamous. In most cases, they just do not include all the features that would be expected with a native, browser-supplied select. Providing the proper keyboard navigation is usually the first thing that is missing, as users are unable to use arrow keys to navigate options or use the space key to make a selection. Another important aspect that is often missing is proper semantics and state management. Rarely will a custom select widget provide the proper semantics to let a user know what kind of widget is being operated and which option is selected.
Despite all the reasons to avoid building a custom select, there are still very valid reasons that someone would need to. First of all, the user interface on mobile platforms is lacking, with list items usually needing to be truncated. If multiple selections are desired, native selects again do not provide the best experience. In multiple selection mode, keyboard interaction is difficult and does not even announce as being in multiple select mode. Additionally, a common complaint is that selects in multiple select mode take up too much space. Lastly, having better grouping options is really important.
Next, I discuss the problems with the official ARIA Authoring Practices example for collapsible dropdowns. The ARIA Authoring Practices documentation is pretty clear that they are not supported everywhere. They are also not recognized as a form element, nor do they provide grouping options.
Before diving into the custom select, I will make one last effort to dissuade attendees from using a custom select if they do not need to. If the only reason for a custom select is to be able to have custom styles, then I will provide some good examples of how to do so.
Finally, after talking about the pros and cons for a custom select, I will discuss the inspiration for my custom select, starting with the official ARIA pattern, as well as native select components on various platforms. I will also demonstrate the practical reasons for deviation, the pitfalls I ran into, and ultimately a working demo of an accessible and usable custom select widget that works on desktop and mobile. Not only will practical HTML and ARIA guidance be provided, I will also discuss some additional improvements to the overall user experience
The ultimate goal of this presentation is to breakdown the myths of custom selects, provide some tips from my experience, and hopefully create, or inspire, a reusable solution that everyone can use.
- Reasons to create/ use a custom select
- Ways to avoid creating/ using a custom select
- Practical implementation of a custom select