accessibility Blog html JavaScript usability UX Web

Maybe You Don’t Need a Date Picker

July 5, 2019; zero Feedback

Calendar controls, date pickers, date widgets, no matter you call them, nevertheless they’re described, they comply with the same primary principle — present the consumer with a calendar to enter a date (and typically a time).

The day, month, and year configuration of a custom date rubber stamp.

Chris Blakeley, CC BY-NC-ND

The native implementations come from browsers when authors use . Often a calendar grid, however typically built to appear to be a broken slot-machine or configurable date rubber stamp that your accountant makes use of.

Frameworks and libraries supply their own tackle date pickers, with many more choices from third-party builders. These attraction to developers who need control over the visual fashion, and typically perform, of the date picker. Notably developers who need to avoid a totally different expertise throughout browsers.

The issue is that almost every implementation of a date picker is a barrier for some set of customers. I can comfortably say each one that I’ve seen is a drawback, though maybe there’s a wonderfully strong one someplace. Even the ARIA Authoring Practices, which is extra snug with imperfect patterns, has not deigned to create a date picker.


I’ve been testing with customers for about 20 years (to date). Something I see time and again is the frustration with date fields which are anything aside from a plain textual content area for well known dates (like birthdays). They will anger customers. Enough that I’ve seen customers give up a check (greater than once).

Customers do not need to should cease their circulate and study this new consumer interface. They don’t need to experiment to see what keys work, or learn a pile of instructions. They need to enter a date and transfer on. This is applicable simply as a lot to native date pickers. They could solely use their telephone or pc to e mail and surf the online, not enter in depth date-specific info on a regular basis.

A developer might use a date picker a few occasions a day. Every jiffy when building a display with a date picker. Heck, perhaps solely a few times a week. However a developer might have used date pickers in a single month much more occasions than a mean consumer in a yr or a lifetime.


I’ve not touched on the accessibility issues with date pickers. The ones that declare to be accessible aren’t. For example, we all know is a drawback for voice customers across browsers. I’m continuously tossed date pickers from libraries and asked to guage them, and they are sometimes an accessibility quagmire. There’s a purpose most accessibility professionals tense up at the mention of date pickers.

Pointless element

I gathered the next notes after only a jiffy with the ReactJS Datepicker and its accessibility notes. I’m fairly confident more points can be discovered with more time.

  1. The buttons on the prime of the grid to navigate to the previous or subsequent month haven’t any accessible identify. If a display reader consumer provides them focus, they will be announced only as “Button”. That is a WCAG four.1.2 violation.
  2. The arrows in the buttons have inadequate distinction with the background, which means customers in daylight, with poor screens, or with low imaginative and prescient might have hassle seeing them. This is a WCAG 1.4.11 violation.
  3. The menus for the month and yr haven’t any accessible identify (by way of
  4. The location supplies a stack of keyboard shortcuts that the calendar management supports. While supported, nowhere is that help conveyed to customers. Keyboard-only and display reader users are offered no instructions on the best way to use the management, which means they’ll possible arrow their means by way of months and years to seek out their selection. This is a WCAG 3.3.2 violation.
  5. The earlier / subsequent month buttons, the month select and the yr select cannot be accessed by a keyboard-only consumer. Utilizing the arrow keys doesn’t put concentrate on those controls. Utilizing Tab strikes the main target to the subsequent area of the shape. Of the listed supported keyboard shortcuts, even when a keyboard-only consumer knew about them, there isn’t any strategy to get to these seen controls, which means they may probably arrow their approach via months and years to seek out their selection. This is a WCAG 2.1.1 violation.
  6. The dates have an aria-label with them that overrides the seen textual content and adds complexity to the term. Whereas aria-label sometimes won’t work on a
    , the position makes it work. On this case, as an alternative of a display reader consumer listening to “18” they hear “day dash 18”. A greater strategy can be to exclude the aria-label altogether. This is not a technical WCAG violation, but is taken into account a usability concern for display reader users.
  7. The presently chosen date is just not conveyed to display reader customers. It is just conveyed visually. This is a case the place aria-label could also be helpful to convey the state of the calendar date, perhaps as aria-label=”18 selected”. It’s attainable aria-current can work right here. As it’s, this is WCAG 1.four.1 and four.1.2 violation.
  8. The week days usually are not conveyed to display reader customers for individual days. As a result of the calendar does not use a

    parts for every weekday, and since arrowing proper or left moves the consumer whatever the begin or finish of a row, a display reader consumer won’t know if a specific date falls on a Monday, Tuesday, and so forth. It doesn’t assist that is additionally mis-cast with position=”listbox”. That is a WCAG 1.three.1 violation.

    Round-up of WCAG violations in this calendar management as listed above:

    • 1.3.1: Information and Relationships (A)
    • 1.4.1: Use of Shade (A)
    • 1.4.11: Non-text Distinction (AA)
    • 2.1.1: Keyboard (A)
    • three.three.2: Labels or Directions (A)
    • four.1.2: Identify, Position, Value (A)


    Using third-party or native calendar controls could make a developer really feel that the validation is dealt with. Handled by the collective intelligence of everybody who worked on the management.

    But the developer still has to offer validation outdoors of the control. Typically validation is needed to help the fallback state for older browsers. Typically it is there to honor progressive enhancement. But principally there must be server-side validation because we know scripts break and assets don’t load and knowledge might be bypass client-side validation.

    I can’t imagine that builders are going to let user-submitted content instantly into their knowledge buildings with out scrubbing it in some minimal method. And not simply because of the worry of Little Bobby Tables paying their website a go to. As a skilled consumer, I can get around confounding controls by injecting the values I would like using the browser’s dev instruments, and developers sometimes account for knowledge coming by way of outdoors of the rigorously crafted client-side validation.

    The point is, strong websites and purposes already do validation on the info outdoors of that offered by the management.

    An Various to Date Pickers

    Customers usually are not looking for a complicated date picker each time you ask for any date. At the least not users with a keyboard.

    Textual content Subject

    Beforehand I’ve relied on plain textual content inputs as date fields with custom validation for the location, sometimes using the same logic on the shopper and the server. For recognized dates — birthdays, holidays, anniversaries, and so forth — it has tested properly.

    Text Subject with Messaging

    In this prototype I am still using a text input for the first subject, however I additionally use client-side script to convert the info to a human-readable date that I current to the consumer. This manner a consumer can get speedy feedback and worry a bit much less about matching a specific arcane knowledge format the developers want.

    Briefly, I am making an attempt to deliver far much less code (and confusion) to the top consumer whereas accepting a broader range of date formats. I’m letting the robustness principle drive my strategy.


    See the Pen
    XQBgNO by Adrian Roselli (@aardrian)
    on CodePen.

    You will notice that I ask for a U.S. date format. The weirdest one. This may be adjusted, in fact, however I selected it to exhibit how a globally confusing format benefits from fast suggestions.

    The script to convert the date is the minimal quantity of code to show the effect. It isn’t production-ready. It isn’t even good. Attempt it by getting into “7 5 19”. Ideally, the date your script generates is the one you submit with the shape.

    Notice the ARIA attributes, the connections between the fields, and use of to hold the message. These are all there to ensure it is helpful for display reader customers and voice customers.

    Testing Feedback

    Dragon Dictate users are usually annoyed with all calendar controls, together with the native ones we get from sort=”date”. In an off-the-cuff check, this one proved usable.

    Informal checks (anecdata) from other customers confirmed this strategy was no worse than a textual content area and far simpler than a calendar management.

    Places This Will Not Work

    There are plenty of conditions the place a plain text area (with or with out the messaging function I prototyped) won’t work.

    If it’s essential see chosen dates, unavailable dates, weekends, holidays, date spans, date ranges, dates the place counts from begin or finish dates matter, and so on.


    What we know is that native and custom calendar controls are often a drawback for customers and utilized where they don’t seem to be needed. Earlier than dropping the code on a display as a matter of habit, think about if it genuinely helps the consumer or just your workflow.

    I do not suggest a good answer for the slender use case I identified, however I hope it spurs rethinking the informal software of a more complicated sample than is usually warranted.


    accessibility, html, JavaScript, usability, UX

    Different Posts

    Earlier submit: Link + Disclosure Widget Navigation