Last Updated: 26 Jul 2022 07:41 by ADMIN
Created on: 28 Feb 2022 13:50
Category: DatePicker
Type: Bug Report
NVDA Screen Reader issues with DatePicker Control

When testing your datepicker control in NVDA, there are a number of accessibility issues.

  1. The dateinput portion of the control does not account for users entering full dates into the control, meaning if a person was to try to type 2/23/2022 into the input where they included the slashes, it would throw them into the year section when they thought they were entering the day section.  My suggestion via this forum link (https://www.telerik.com/forums/ignore-forward-slash-allow-various-formats-when-using-date-input) is to alter your date entry logic to allow users to both enter the dates without the slashes (which is what you have now except under a few edge cases where a slash is needed to move to the next section like 2 2/ 2022) as well as include the slashes where if the user is on the first digit of the day section and the / is pressed, do NOT advance them to the year section.  While this can be an annoyance for a sited user because they end up accidentally entering the day in the year section when they try to use the slashes, they can at least see what went wrong, and then go back and fix it. For a screen reader user, they are not notified of the auto advancement, and so they have no idea that they have entered an invalid date until the leave the control and then tab back to it, or if they were to try to submit the form and get an error.
  2. The dropdown portion of the control is not being read properly by NVDA.  When you first drop it down via alt-down arrow, it will actually write all of the table text to the Speech Viewer window, but nothing is read. 
  3. Then, once you try to arrow to a date, nothing is read at all. You can tab to the month and previous/next buttons and they are read.
  4. Opening the Month section of the dropdown doesn't read the month out when arrowing through the months.
  5. Tabbing to the previous or next buttons and then pressing them with enter reads all of the dates in the table.
  6. Arrowing up or down within the days reads all of the dates in the table when it advances to a new month, but reads nothing otherwise.

I am using the latest version of NVDA 2021.3.3 on Chrome Version 98.0.4758.82 (Official Build) (64-bit).  I will note that Jaws and Chrome work properly regarding the dropdown issues, so it may be an NVDA thing, but maybe some research can be done to see if there are some different aria attributes that will work so that if functions properly with both screen readers.  For example this Aria Best Practices Date Combo Box example at least reads where the user is with the arrow keys. https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-datepicker.html It is not perfect, but it is better than not being read at all.

And even outside of the date dropdown stuff, the date input portion (#1) above is an issue across the board. I know that it is a design decision that you guys have made, and that you have provided documentation as to why and how to use it, but most users are going to type in the slashes of a date, and it's not reasonable to write up a half page of documentation within my app to let users know how to use the control.  I can't even put a short label that says enter date without slashes, because under some circumstances a slash is necessary, so it becomes confusing to the user, and screen reader users will get lost if they make a mistake because they are not informed that they have just switched to a different section.


Posted on: 26 Jul 2022 07:41


In 3.4.0 release we release accessibility enhancements for the Picker components in terms of aria support and focus management. The other requests that were opened from the feedback here are in planned stage.

In addition, our wai-aria and keyboard navigation are now available through npm package:



Progress Telerik

The Premier Dev Conference is back! 

Coming to you live from Progress360 in-person or on your own time, DevReach for all. Register Today.

Posted on: 09 May 2022 04:55

Hi Lance,

Once again thank you for the feedback.

I replied in the request for configuration of the auto-tab behavior, and our goal will be to include the configuration sooner in our product.


Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Posted on: 02 May 2022 04:26

I believe the current DateInput "efficient keyboard input" actually has to be regarded as a bug for sighted users too.  If you enter the first field then type the slash the behaviour is that it skips to the second field after you type the first field, which happens faster than users can see anyway as nobody under normal scenarios is ever looking up at the screen then down at the keyboard then typing one letter then back up at the screen, etc.  

So what happens is that when you type the slash, the 'smart' input is then incredibly dumb and thinks that you don't actually want to enter the second field and that the slash should be regarded as a magic key like tab and whisk the user away into the third field - which it is almost certain that nobody will ever want.

The slash key is NOT a tab key, it shouldn't allow you to skip a date field if you haven't typed any of it at all.  Nobody would regard 2//2022 as a valid date.  Having the ability to type in a date as '12/12/2022' instead of 12122022 is not rocket science.

The excuse given that you can't please everybody and that you chose this is a compromise does not stack up, because the control actually accepts the tab key in certain cases, but it gets it completely wrong in others when it doesn't need to.  Its current implementation quite remarkably has a bug in how it handles '/' and it should be regarded as such and fixed.

A slash keypress should never advance into the next field IF you haven't typed in the current field.  That is all that is needed to fix it and make it better for everyone

Posted on: 23 Mar 2022 22:40

Hello Mike,

Thank you for the detailed report.

In order to evaluate the request we initiated several researches on the user experience and the accessibility. So, I will go directly to the action points we created:

1. We are approving the request for customizing the default tabbing behavior in the DateInput. I have logged it in a separate request with a short description of the expected output:


2. We are evaluating the addition of a aria-describedby parameter to our input components. Thus, the format of the dateinput can be stored there and achieve the same experience as in the linked w3 example

3. Our accessibility team started working on an accessibility specification for the datepickers and calendar components. I confirm that we have issues with the calendar that interfere the interaction with the screen reader.

So, in this request we will handle the accessibility of our datepicker components and their inner parts.

Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.