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.
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.
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><telerik:RadDatePicker runat="server"
DatePopupButton-Visible="false"
PopupDirection="BottomLeft"
ShowPopupOnFocus="true"
DateInput-EnabledStyle-HorizontalAlign="Left"
DateInput-EnableSmartParsing="false"
MinDate="0001-01-01">
</telerik:RadDatePicker>
Test Environment:
OS: Windows_11
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.
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.
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
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
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
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
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:
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
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
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);
There are accessibility issues with the calendar portion of the DatePicker which can be seen in the following demo:
- JAWS does not announce the selected date in the Date Grid - While 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.
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
