Accessible Date Pickers and Other Common Offenders

If you audit enough websites, you notice that accessibility failures are not evenly distributed. They cluster. The plain parts of a page, the paragraphs, the links, the ordinary forms, are usually fine, because the browser makes them fine by default. The failures concentrate in a small recurring cast of characters: the custom date picker, the fake dropdown, the carousel, the star rating widget, the toggle switch that’s secretly a div. What these have in common is that each one is a native browser control that a designer decided wasn’t pretty enough, rebuilt from scratch, and rebuilt incompletely.

The date picker is the archetype, which is why it’s in the title. A native date input gives you an enormous amount for free. It’s focusable. It works with a keyboard. It announces itself to screen readers as a date field. On phones it summons the operating system’s own date wheel, which every user already knows how to operate. Then a designer looks at it, notices it renders differently in different browsers and can’t be styled to match the brand, and commissions a custom calendar widget. Now someone has to reimplement everything the browser was doing silently: the keyboard navigation between days, the announcement of which month you’re in, the focus management when the popup opens and closes, the way you type a date directly instead of clicking forty times to reach your birth year. Most custom pickers implement the visual grid and stop. The result looks like a calendar and behaves, for anyone not using a mouse, like a wall. A blind user tabs to the field, hears something unhelpful or nothing, and the booking ends there.

The fake dropdown is the same story with a different costume. A native select element is homely but bulletproof: keyboard accessible, screen reader friendly, familiar on every platform. The styled replacement, a div that opens a list of more divs, has to recreate arrow-key navigation, typing a letter to jump to an option, Escape to close, and the semantics that tell assistive technology this is a list of choices and here is the selected one. The recipe for doing this correctly exists; the ARIA Authoring Practices spell out expected keyboard behavior for a combobox in detail. It’s just long, and most implementations stop at the part that demos well.

The carousel offends differently. Its usual sins are motion and time: it advances on its own schedule, which is hostile to anyone who reads slowly, and its previous and next buttons are often icon-only with no accessible name, so a screen reader announces “button, button.” A moving element that can’t be paused fails people with vestibular disorders and attention difficulties, and it fails everyone else a little, which may be why carousels convert so poorly that the main accessibility advice about them is also the main conversion advice: consider not having one.

Then there’s the family of small impostors. The toggle switch that’s a styled div with a click handler, invisible to the Tab key, mute to screen readers, when a checkbox with custom CSS would have done everything. The star rating made of image sprites that no keyboard can operate, when radio buttons would have worked. The infinitely scrolling list that keeps the footer forever out of reach. Each is a native pattern, replaced for aesthetic reasons, at the cost of function that was already paid for.

I want to be fair about why this happens, because it isn’t laziness. The native controls genuinely are hard to style, inconsistently rendered, and sometimes ugly, and browsers took decades to start fixing that. Designers are judged on how interfaces look, engineers on how fast they ship, and the free accessibility of native elements is invisible right up until it’s gone. Nobody removes accessibility on purpose. They remove an element that had it, and don’t put it back.

So here’s the principle I’d offer, and it’s the one I lean on when GazeSite flags these widgets in a scan: the browser’s controls are not a starting point to be replaced but a budget to be spent carefully. Every native element you swap for a custom one is a loan you’re taking out, and the interest is every behavior you now must reimplement by hand: focus, keyboard, semantics, mobile. Sometimes the loan is worth it. A date picker for hotel stays, showing two months and price hints, genuinely does more than a native input, and a team that builds it properly, or adopts a well-tested library and verifies the keyboard path, is making a reasonable trade. But the default answer to “should we rebuild this control” should be no, and the burden of proof should sit with the redesign, not with the plain version.

The test, as always, is cheap. Take your most custom widget, the one the team is proudest of, and operate it with only a keyboard, then with a screen reader if you can bear the learning curve. If you can’t pick next Tuesday without a mouse, neither can your customers. The prettiest calendar on the web is worth nothing to someone it won’t let choose a date.