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.

Thanks.