Thoughts
The Dropdown Dilemma: Building accessible digital services
How do you navigate and read a website? Du you use a mouse pointer, keyboard or screen reader? Do you use a smartphone or laptop? In short, there are a lot of ways in which people use digital services. Different individuals might also have different needs and preferences. That's why it's important to build these services with all of this in mind – so that as many people as possible can use these services, no matter their ability or what tools and devices they use.
The WebAim Million
Each year, WebAIM publishes the report "The WebAIM Million" where they perform accessibility audits on 1 million web pages. In the report from 2025 over 50 million unique errors were found – on average 51 errors per web page, https://webaim.org/projects/million/. That's a lot of errors! Note that these audits are only performed using automatic tools – no manual tests.
How can there be so many errors?
Similar to how there are many ways of using digital services, there are at least as many ways of building them. The amount of frameworks, libraries and design systems is vast and the level of abstraction is getting higher and higher. Perhaps that's why some developers overlook that there are standards for how to build accessible solutions, hidden under all those abstraction layers? Or is the issue that accessibility sometimes isn't taken into account when planning new projects? Perhaps a combination of the two?
No matter the reason, the problems exist. Unfortunately we won't solve everything in this article, but to get into the right mindset – let's dive into a small concrete example which illustrates a common technological accessibility problem.
GelaTogether – where ice cream enthusiasts meet
"The user should be able to pick a favourite ice cream." This could be a requirement if we're building a social platform for ice cream enthusiasts, let's call it "GelaTogether". Some might think "Easy peasy! Let's build a Dropdown where the user can make a choice from a list of options."
If only it were that easy. To start with, a "Dropdown" is sometimes called "Menu", "List", "Popup menu" or "Select". How can such a seemingly simple component have so many names? That's not all! It can and should also be implemented in different ways depending on context. Is it to be used in a form, or as an application settings menu? A Dropdown is a good example of a component which is more complex than some believe. Why? Strap in, it's about to get technical!
To illustrate the issues we'll use CodePen, where you can see both the code and an interactive implementation. The following is an example of how a Dropdown can be built:
See the Pen Inaccessible Dropdown Menu by kral (@karlqueckfeldt) on CodePen.
Some might think that this solution works fine. You can click the button, a list opens and you can make a selection. All done using "only" 227 lines of code! Unfortunately, not all users can select their favourite ice cream using this solution. Here are some problems:
- It's not possible to navigate the list of options using the keyboard.
- It's not possible to determine what's selected in the list, neither visually nor programmatically by screen readers.
- It's not possible to close the list using "Escape" or by clicking outside of it.
- The button doesn't programmatically show when the list is opened or closed.
- Focus is not moved to the first option in the list when it opens.
These are some common problems when building Dropdown components. No matter if developers use a component library, vibe coding or build from scratch, it's important to make sure that these things work. And also that the correct type of Dropdown is used in the correct place.
We need more – and proper code!
So how do we solve these problems? Let's look at how we can implement a more accessible Dropdown:
See the Pen Accessible Dropdown Menu by Karl (@karlqueckfeldt) on CodePen.
Visually, this component looks almost the same. This solution has a whopping 458 lines of code though! That's about twice as many as the previous solution. It's evident that it takes a bit more work to build properly accessible components. Let's not go through the code line by line, but please have a look if you're interested. These are the improvements we made:
- It's now possible to navigate the options using the arrow keys on the keyboard.
- The selected ice cream is now clearly visible in the list, both visually and for screen readers.
- The list can now be closed using "Escape" and by clicking outside of it.
- The button now programmatically shows if the list is open or not.
- Focus is moved to the first option, or the currently selected one, in the list when it's opened.
More users can now select their favourite ice cream! Isn't that great? Please do try both solutions with keyboard and screen reader. Also read the code and compare the solutions.
Finally
As mentioned, there are many ways to build digital services, and this example highlights just a few of the technical challenges with a common component. The subject is vast, and there’s a lot to explore. Hopefully, though, this has provided a small glimpse into what it takes to build with accessibility in mind. By doing so, we ensure that as many people as possible can make use of what we create – and that’s important!
Do you have questions or thoughts about building accessible digital services? Don’t hesitate to reach out to us at Esatto – we’re here to help!
