Is your custom dropdown costing you customers?

Many product pages use custom dropdowns for sizes, colours and product options. But what happens when these custom dropdowns only work with a mouse? And what does "fixed" look like for every customer?

Accessibility review: custom dropdowns on product pages

Does your custom dropdown work for all of your customers?

If your dev team or agency are building custom User Interface (UI) components for your website, there’s a good chance they’re replacing perfectly functional browser controls with something that looks polished but works for fewer people. And when that happens, the basic path to purchase breaks.

This is one of the most common and expensive failures on product pages.

Custom elements can look great, and can provide a polished user experience when they’re built properly. But how do you make sure these custom elements aren’t costing you sales, and that they work for everyone, not just people using a mouse?

How can you, as a business owner, spot broken custom dropdowns on your product page before they start costing you sales?

The simplest test is to put your mouse away and try to complete a purchase using only your keyboard. Tab through your product page. Can you select every option? Can you add items to your basket?

Custom dropdowns are often one of the first things to break. In my own reviews, I routinely see product pages where the dropdown looks perfect but fails the moment someone presses Space, Enter, or the arrow keys. These failures never appear in analytics, but they do end up with abandoned baskets.

And unless you test with a keyboard, it’s almost impossible to spot. But if someone can’t choose a size or colour, they can’t add the item to their basket. Their journey ends right there.

This happens more often than people realise, and automated tools like Google’s Pagespeed Insights or Lighthouse often won’t pick it up. These automated tools are great for finding many accessibility issues, but they won’t interact with the page the way a real person does.

Why does this matter for you and your business?

Unless you’re intentionally trying to limit who can buy your products, this probably isn’t a pattern you want.

Many people shop without a mouse: customers with long-term access needs, people recovering from injuries, and power users who prefer fast, efficient keyboard navigation. If the only working path requires a mouse, you lose real customers - not because they don’t want the item, but because the control they need doesn’t respond.

If your business sells online, broken elements are not just a quirk, it’s a drastic revenue leak.

How to fix this problem?

No one ever loses sales because they used the native select element.

Native controls are the lowest-risk option: fewer custom states to maintain, fewer edge cases, and fewer failures blocking purchases. Custom components can absolutely work - they just need to meet the same behavioural expectations that the native control provides for free.

The native <select> element just works. Every time. For everyone. It works with keyboards. It works with screen readers. It works if JavaScript loads slowly. It keeps working even when your UI library has a bad day.

Before looking at the technical side, it’s worth understanding why recreating a select element is so difficult to get right.

Why the native <select> is hard to beat

The <select> HTML component is a complex element, which has been tested and refined over decades by browser vendors and assistive technology experts so that it is predictable and has expected behaviour. Recreating this functionality from scratch is a significant engineering challenge.

From a technical standpoint, once you replace the native control, you’re taking responsibility for everything the browser normally guarantees - including WCAG 4.1.2 (Name, Role, Value) and the ARIA Authoring Practices pattern for a combobox or listbox. This isn’t about ticking a compliance box, it’s about ensuring predictable behaviour so people can complete the task they came to do.

If your business does need a custom dropdown - for branding, for a richer interaction, or for variations the native control can’t express - you can still build one. The baseline is simple: your custom component must match the essential interaction model people already rely on when using a standard <select>.

Your custom component must match the essential expected behaviour from the native control (at a minimum):

  • keyboard event handling (Tab, Enter, Space, arrow keys)
  • focus and blur behaviour so people don’t get trapped or lost
  • clear announcements to assistive technologies
  • correct roles, states and values (expanded, collapsed, active descendant, selected/value)
  • consistent behaviour across browsers and devices

Miss any one of these, and someone cannot choose a size.

And that is why most broken dropdowns look fine visually but fail the moment someone doesn’t use a mouse.

So how can you test this yourself?

Try it yourself:

  1. Put your mouse to one side and visit one of your own product pages.
  2. Press Tab until the dropdown receives focus.
  3. Try opening it with Space or the arrow keys.
  4. Move through the options with the arrow keys.
  5. Choose an option with Enter.

If any part of that sequence fails, the component isn’t behaving like the native element people expect - and some customers will simply be unable to buy your product.

When core interactions follow predictable patterns, people using assistive tech, touch, keyboards, or unconventional setups all get the same reliable path to purchase.

Accessibility here isn’t about adding more UI. It’s about making sure the controls your customers rely on always work, no matter how they shop.

Dropdowns, swatches, quantity selectors, and add-to-basket buttons are some of the highest-friction points in the online shopping journey. When any of them fail, the impact is immediate: the customer cannot complete the purchase. These small details have outsized commercial impact.