What is the best way for blind users to fill in a date field? The date field is used for dates within the next 3 months.

  1. Single texfield: A single textfield with a 'date' text-label and with a default value of 'dd-mm-yyyy' (european date format).
  2. Single textfield with calendar: Item one with a link to a calendar behind the textfield
  3. Three dropdowns: Three dropdowns with three labels for day, month and year
  4. Input type=date: Using the new input type date. Is this already implemented for screenreaders?
  5. Something else
  • 1
    I think it is less to do with what you put on the page, but how you put it on the page, have a read here: afb.org/info/accessibility/… they include 10 design tips for blind users. Jul 8, 2014 at 10:01
  • Do you think all technics described here can be made accessible?
    – Pieter H.
    Jul 8, 2014 at 10:06
  • To be honest, you're at the edge of my knowledge when it comes to accessibility. I've always designed for standards with the idea that that would be enough to cater for accessibility, if there's a specialist technique to make your website super accessible for visual impaired users, it's beyond my knowledge sorry. Jul 8, 2014 at 10:13
  • Just a note for input type = date. In Chrome, it will automatically place a datepicker (like JQuery UI datepicker) on the screen when you click on the input box. However, browsers like Firefox (and IE too I believe) don't support this feature. So simply relying on any single one item you have listed might not be enough.
    – Andrew
    Jul 9, 2014 at 12:35

4 Answers 4


Having done some testing with screen readers here's what I've found works best for dates -

A plain text input with placeholder text showing the date format. Not all screen readers will read placeholder text, so in the past I've used something like a floating div for placeholder text for sighted users and ARIA attributes to provide a summary of the date format for blind users. (There are other ways to get this same effect, this is just an example.)

In addition to this, I provide a button with a link to a calendar control next to the field. This is primarily for sighted users who will find navigating through a calendar handy. For power users / blind people, navigating through a calendar will be relatively slow. Your calendar control should obviously still have ARIA attributes and be screen reader/keyboard friendly, but it's not the primary use-case for a person relying on a keyboard and screen reader.

I've found that this combination neatly meets all users' needs - power users, novices, vision impaired, and mobility impaired.

Why don't I use the HTML5 date input type? Because it's terrible. The styling and options vary heavily from browser to browser. JS-based solutions are much more customizable and consistent.


GDS have some nice stuff written up about dates in their design patterns library — and I know that they take accessibility seriously and do testing with folk with different disabilities.



We can include an automated voice to read aloud, the numbers entered in the field will be read while typing each numbers for month/day/year or reading aloud while hovering on the date picker. Blind users are good at motor skills, they may hear and judge while typing or hover. Hope this helps.


In my opinion it's really up to you as there isn't just one correct way. I would suggest one of the following:

  • Using 3 drop-downs won't be the faster input method but it's reliable, understandable and partially validated since you exert control over the list of numbers contained in the menu itself.

  • input type="date" should be fine as it is the standard for dates input in HTML5 and its support will grow exponentially over time. An issue here is that users should insert the dates in the correct form to work (you need to validate it). JS fallbacks can be added to bring support to those platforms that still don't like the new input type. In case the type isn't supported and JS isn't available, it simply falls back to a text field and allows the user to freely write in it.

If you plan to use a JS-driven solution be sure to check that it supports Aria attributes - this will make accessible the date panel.

And remember that JS and server-side checks should always be performed to avoid edge cases like 31th February.

Read more at the following link: http://usability.com.au/2013/04/accessible-forms-1-labels-and-identification/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.