Completed
Last Updated: 24 Jul 2019 15:14 by ADMIN
In much of the work we do, we need the user to pick a date-from and date-to.  Currently, this means making two distinct controls and having to write validation to ensure that date 1 must be before date 2.  Many sites, such as hotel booking sites, have a date-period selector as a single control and it would be great to have this available as part of the ASP.NET AJAX suite.  I believe that a date-period-selector tool is available as part of other Telerik control suites, so I was rather hoping that it could make an appearance for us too.  Thanks!
Completed
Last Updated: 08 Sep 2021 10:58 by ADMIN
Release R3 2021
Created by: Jeff
Comments: 0
Category: DatePicker
Type: Feature Request
1

There are accessibility issues with the calendar portion of the DatePicker which can be seen in the following demo:

https://demos.telerik.com/aspnet-ajax/datepicker/accessibilityandinternationalization/wcag2.0andsection508accessibility/defaultcs.aspx

  • JAWS does not announce the selected date in the Date GridWhile running JAWS, open the calendar and use the arrow keys to move through the date grid. Notice that JAWS does not announce the date numbers, so there's no way to know what date is currently focused. 
  • The TAB does not refocus the DateInput back from the popup While the calendar is open, press the Tab key. Note that focus leaves the calendar. Even if the Tab is not the preferred form of navigation, it should be trapped as long as the calendar widget is open so that it cannot interrupt the user's interaction with the control.
  • Escape does not focus the DateInput/Escape does not work in Firefox - While the calendar is open and focused, press the escape key to close it. Note that focus is not returned to the calendar button. It's set top of the page. The calendar button IS focused when a date is selected from the calendar, so it should be possible to do the same when closing the calendar via any other means.
  • *Moved to separate feedback item* No direct way to select the prev/next month and year buttons - While the calendar is open and focused, note that there is no way to focus and use the month and year changing buttons in the calendar header.

All of the above were tested in both Chrome, IE, and Firefox.

Combined, these issues seem to break accessibility for both low-vision and keyboard-only users. Any improvements you can make in future releases would be greatly appreciated.

Completed
Last Updated: 31 Aug 2021 14:16 by ADMIN
Release R3 2021

Markup to reproduce:

<telerik:RadDatePicker Runat="server" MaxDate="11/10/2020" MinDate="11/10/2020" EnableKeyboardNavigation="true" EnableAriaSupport="false"></telerik:RadDatePicker>

Open the popup calendar and try to navigate with the arrow keys. JavaScript error is thrown

 

Unplanned
Last Updated: 08 Oct 2021 09:06 by ADMIN

Currently, the enter key is not closing the popup when pressed on the already selected date. Can be tested in https://demos.telerik.com/aspnet-ajax/datepicker/accessibilityandinternationalization/wcag2.0andsection508accessibility/defaultcs.aspx

Note: The popup calendar can be closed with Esc key in this case

Unplanned
Last Updated: 15 Apr 2021 14:48 by ADMIN
Created by: Neale Hayes
Comments: 1
Category: DatePicker
Type: Feature Request
1

We are trying to get our site to be WCAG AA compliant however the Telerik DatePicker appears to have inline styling on the second popup for month selection:

Completed
Last Updated: 08 Nov 2021 12:27 by ADMIN
Release R3 2021 SP1

No direct way to select the prev/next month and year buttons - While the calendar is open and focused, note that there is no way to focus and use the month and year changing buttons in the calendar header

Related to https://feedback.telerik.com/aspnet-ajax/1481017-jaws-and-keyboard-support-improvements-in-raddatepicker 

Unplanned
Last Updated: 07 Dec 2023 14:04 by Ray

Steps to replicate the issue:

  • Set the computer's Time Zone to CST (Central Standard Time) which is UTC -6:00.
  • Enable Daylight Saving
  • Open VS and create a new Page with a DatePicker in it (basic settings)
  • Select the date "4/1/2023" and picking the time "2:00 AM" jumps to "3:00 AM"

Important: for the Time Zone changes to have effect, the Visual Studio solution has to be closed/re-opened.

Completed
Last Updated: 01 Jun 2021 13:31 by ADMIN
Release Q2 2015
Unplanned
Last Updated: 29 Mar 2019 12:38 by ADMIN
When the DatePicker is with enabled WAI-ARIA support, Jaws reads "link 11" instead of the selected date "Monday, March 11, 2019".
Unplanned
Last Updated: 08 Apr 2020 15:43 by ADMIN

Hi,

For the date picker and it's family of controls (time picker, date time picker), when using bootstrap skin, lightweight rendering and RTL page, the buttons for the picker are displayed on the wrong side of the control (the right side) instead of being displayed on the left side. I know this can be fixed using some CSS but although the html controls are in order (text and then button both in a container with RTL), the button is stuck to the right side somehow

please advise

Unplanned
Last Updated: 16 Sep 2020 11:27 by ADMIN
Created by: Neale Hayes
Comments: 0
Category: DatePicker
Type: Bug Report
0

1) There is no element with the id or name as the value of the aria-controls attribute of the dateinput button with enabled ARIA support. 

2) The aria-valuemin and aria-valuemax attribute are not valid on role=textbox

To fix these, the following workarounds can be used

Option 1: OnClientLoad event of the DateInput element inside the DatePicker

function DatePickerOnClientLoad(sender) { setTimeout(function () { $telerik.$(sender.get_element()).parent().find("[role=button][aria-controls]").removeAttr("aria-controls");
$telerik.$(sender.get_element()).removeAttr("aria-valuemin").removeAttr("aria-valuemax") }) }

 

Option 2: using Sys.Application.Load event

function pageLoadHandler() {
    $telerik.$("[role=button][aria-controls]");
    $telerik.$("[role=textbox]").removeAttr("aria-valuemin").removeAttr("aria-valuemax");
    // Sys.Application.remove_load(pageLoadHandler);  
}
Sys.Application.add_load(pageLoadHandler);

 

 

 

Declined
Last Updated: 10 Jun 2021 11:55 by ADMIN

There is a problem with the rendering of the RadDateInput when RenderMode is set to Lightweight when on the same page we have a RadNumericTextBox with RenderMode != LightWeight

 

This is the issue when RadDateInput RenderMode="Lightweight" and RadNumericTextBox with RenderMode = "Classic"

 

The issue does not appear when all controls are in Lightweight mode

Unplanned
Last Updated: 29 Jul 2021 08:11 by ADMIN
Created by: Greg
Comments: 1
Category: DatePicker
Type: Feature Request
0

I have started using a shared calendar on RadDatePicker.  I also added a JavaScript example found I believe in the Telerik forum to set the min date of one RadDatePicker to the chosen date on the other RadDatePicker for a date range.  This isn't working correctly with a shared calendar because setting the min date on one RadDatePicker sets it on the calendar for both RadDatePickers. My solution was an OnPopupOpening function on the RadDatePicker to reapply the min/max dates to the calendar.  Here is the code:


    function onPopupOpening(sender, args) {
        var box = sender.get_dateInput();
        var cal = sender.get_calendar();
        var min = box.get_minDate();
        var max = box.get_maxDate();
        var mindate = [min.getFullYear(), min.getMonth() + 1, min.getDate()];
        var maxdate = [max.getFullYear(), max.getMonth() + 1, max.getDate()];
        cal.set_rangeMinDate(mindate);
        cal.set_rangeMaxDate(maxdate);
    }

My suggestion is to either have this done automatically by RadDatePicker or include something similar in the documentation for others who may have the same issue.

Regards,

Greg

Declined
Last Updated: 05 Aug 2021 09:40 by ADMIN

I am using a RadDatePicker in my page like this

<html xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
        <title>Test Page</title>
    </head>
    <body>
        <form id="Form1" runat="server">
            <telerik:RadScriptManager runat="server"></telerik:RadScriptManager>
            <telerik:RadDatePicker runat="server" ID="RadDatePicker1" 
                RenderMode="Lightweight" Culture="English (United States)" 
                DateInput-DisplayDateFormat="d" DateInput-DateFormat="yyyyMMdd" >
            </telerik:RadDatePicker>
        </form>
    </body>
</html>

 

If the culture is set to fr-FR, the DateInput box displays the date in dd/MM/yyyy format and when the input box has focus, the date is converted to yyyyMMdd format for entry.  It also allows for other entry formats such as dd/MM/yyyy and the many other formats documented here DateInput - Parsing Dates.  This is much improved over the legacy input we have been using in our application which has required the users to always enter a date as yyyyMMdd as it allows both the established input format as well as their culture specific format.

The issue I am having is if the culture is set to en-US as above.  Like in the previous example, dates are formatted in the culture specific format, this time mm/DD/yyyy but can be input as yyyyMMdd.  However, if the date is entered in as a month/day/year triplet in the culture's format of mm/DD/yyyy, it is parsed as if it was entered in the DD/mm/yyyy format without consideration to the culture setting. So entering 7/4/2021 for July 4th 2021 in the en-US culture, the date becomes 4/7/2021 or April 7th 2021.

According to the DateInput Parsing Dates document linked above "a month/day/year triplet: a month can be both a numeric value or a month name. The order of the parts in the triplet is culture specific."  This does not appear to be the case.  It seems that by using the DateInput format, a month/day/year triplet is no longer applying the culture during parsing.

Is this a bug in the date parsing where culture isn't being used for this scenario?  Does the documentation need to be updated to clarify the parsers behavior when DateInput-DateFormat is used?

 

Please advise,

Greg

Completed
Last Updated: 07 Sep 2022 11:37 by ADMIN
Release R3 2022
Created by: Jeff
Comments: 1
Category: DatePicker
Type: Bug Report
0
The document.body gets focused when tabbing from the Popup button to the Calendar view. Keyboard navigation no longer works.
Completed
Last Updated: 05 Sep 2022 09:02 by ADMIN

Test Environment:

OS: Windows_11

Version: 22H2
OS Build: 22598.200
Browser: Version 104.0.1293.70 (Official Build) (64-bit)
URL: https://demos.telerik.com/aspnet-ajax/datepicker/overview/defaultcs.aspx

Tool: Colour Contrast Analyser (Version 3.1.2)                                                                                                                                                                                                                                                                                                                                                                                                                                        Repro Steps:                                                                                                                                                                                                                                                                                                                                                                                                                                                                              1. 1.Open URL: https://demos.telerik.com/aspnet-ajax/datepicker/overview/defaultcs.aspxpage in Edge Browser.

2. Navigate and activate 'Calander' icon where popup opens.
3. Colour Contrast Analyser.
4. Apply foreground & background color check for luminosity contrast ratio of 'Selected date' on 'Calander' popup.
5. Observe an issue that luminosity contrast ratio for 'selected date' on Calander is 3.8:1 which is less than 4.5:1.

Actual Behavior:

Luminosity contrast ratio for 'selected date' on Calander is 1.6:1 which is less than 4.5:1.

Expected Behavior:

Contrast ratio for the text must be greater than or equal to 4.5:1.                                         

 
Unplanned
Last Updated: 09 Mar 2023 09:35 by Sarkis

We are in the process of upgrading our controls to Telerik. We had noticed a behavior that we did not want to happen, this was related to DatePicker control changing the value of the date if incorrect format was entered, we solved this by having EnableSmartParsing to false in our Telerik Theme so that it applies to all DatePicker controls.

Now we have some instances of date controls that are defined with specific DateFormat/DisplayDateFormat like below:

<telerik:RadDatePicker ID="dpId" DateInput-DisplayDateFormat="y" DateInput-DateFormat="y" runat="server"></telerik:RadDatePicker> or 

<telerik:RadDatePicker ID="dpFrom" DateInput-DateFormat="MM/yyyy" DateInput-DisplayDateFormat="MMM, yyyy" runat="server"></telerik:RadDatePicker>
Now since we have the below set in a theme these controls will also pick up the global properties, and it looks like having DateInput-EnableSmartParsing="false" along with any different DateFormat/DisplayDateFormat is always rejecting the value being entered (error is shown as wrong format being entered with exclamation mark). Is this due to limitation of having EnableSmartParsing="false" ? setting this to true resolves the issue for these controls, i just want a confirmation if this is by design and what sort of workarounds there are?
<telerik:RadDatePicker runat="server"
  DatePopupButton-Visible="false" 
  PopupDirection="BottomLeft" 
  ShowPopupOnFocus="true" 
  DateInput-EnabledStyle-HorizontalAlign="Left" 
  DateInput-EnableSmartParsing="false"  
  MinDate="0001-01-01">
</telerik:RadDatePicker>

 

Unplanned
Last Updated: 07 Aug 2024 06:32 by Avishai
Created by: Avishai
Comments: 0
Category: DatePicker
Type: Bug Report
0

Using the set_value() method of the DatePicker's Input, set "2024-05-08" (the date format is dd/MM/yyyy), the month and day are misplaced and the control gets the wrong date of 05/08/2024.

When the day is larger than 12, the correct date is received. For example,  '2024-05-14' will update the control correctly and we see the control with 14/05/2024.