The ticket you picked aims to improve accessibility for screen readers.

The goals of this PR are as follows.

When a user using a screen reader clicks on the datepicker or timepicker provided by the admin, focus should be immediately set to the dialog that appears.

Where should the focus be set?

In my opinion, since the Date and Time elements represent time, it would be best if the initial focus (the first element accessed) is set to the element that indicates the current time. This is just my personal view, but both W3C and the <input type="date"> element set the focus directly to the element representing the current time when accessed with a screen reader.

• Date

The element to be focused when pressing enter in a screen reader...

• Time

The element to be focused when pressing enter in a screen reader...

The video shows a small lag (which actually is not there when I tested it) when the clock-box is clicked (also at the calendar-box focusing the current date) to focus the Now element.
Now the elements are properly focused.

@XChaitanyaX
As mentioned in a previous comment, this change is part of an accessibility improvement for users who rely on screen readers.

In other words, as it's currently implemented, it's not about enabling navigation to a specific area using the Tab key without a screen reader.
It must be accessible specifically when a screen reader is being used.

When using a screen reader, users can navigate between elements using the Tab key or reader specific navigation commands, even without any special implementation on our side.
(That’s why the tab navigation you’ve implemented is actually already possible with a screen reader, even without additional code.)

The issue we need to address is ensuring that, when using a screen reader, pressing Enter on the date picker or time picker opens the dialog and allows immediate access to specific elements within it (as I pointed out in a previous comment).
Currently, it is only possible to access after navigating through all the elements.

++ If focus is set to a specific element, screen readers can immediately access that element.

• I am using Narrator (a screen reader) in windows
• Is this good or somethings still need change

Changes done

• removed aria attributes.
• removed accessibility via keyboard where arrow keys are used to navigate in both the date and time pickers as this change is irrelevant to this ticket
• Use the selected element class to efficiently find the currently selected date

Static demo site if anyone wants to test this: Change session - static demo

@XChaitanyaX
If you’d like to have your work reviewed(fellow), please remove the "patch needs improvement" and "needs tests" flags from the ticket.
Feel free to mention me, and I’ll be happy to review it again.

++ When the picker is activated by pressing Enter without using a screen reader, the user still has to navigate through all the elements, just like a screen reader user would. However, I believe this improvement will address that issue for both cases.

++ When the picker is activated by pressing Enter without using a screen reader, the user still has to navigate through all the elements, just like a screen reader user would. However, I believe this improvement will address that issue for both cases.

Yes, it will fix for both the cases

• The accessibility can be improved even more if we add arrow keys to navigate elements in the pickers (it would be a great improvement in the date picker).
• if the current date is 1st and the user need to select the last date of the month, pressing the Tab key 30 times is annoying, if we have arrow key navigation in the date picker it would be a lot easier.

Yes, it will fix for both the cases

* The accessibility can be improved even more if we add arrow keys to navigate elements in the pickers (it would be a great improvement in the date picker).

* if the current date is 1st and the user need to select the last date of the month, pressing the Tab key 30 times is annoying, if we have arrow key navigation in the date picker it would be a lot easier.

Yes, I think so too. The W3C example date picker also provides this functionality.
However, this feature is also something that should be addressed in this ticket.

@Antoliny0919
Any idea on how to write tests for the changes??

I wrote something like this and it failed

QUnit.test('calendar focus loop on tab navigation', function(assert) {
    const $ = django.jQuery;
    const dateField = $('<input type="text" class="vDateField" value="2015-03-16">');
    $('#qunit-fixture').append(dateField);

    DateTimeShortcuts.init();
    DateTimeShortcuts.openCalendar(0);

    const calendarDiv = $('#calendarbox0');
    assert.ok(calendarDiv.is(':visible'), 'Calendar is visible');

    const focusable = calendarDiv
        .find('a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])')
        .filter(':visible');
    const firstEl = focusable.first()[0];
    const lastEl = focusable.last()[0];

    // Move focus to the last element
    lastEl.focus();
    assert.strictEqual(
        document.activeElement,
        lastEl,
        'Last element is focused'
    );

    $(lastEl).trigger($.Event('keydown', { which: 9 }));

    assert.strictEqual(
        document.activeElement,
        firstEl,
        'After tabbing from last element focus loops back to first'
    );

    DateTimeShortcuts.dismissCalendar(0);
});

Died on test 1: Cannot read properties of null (reading 'offsetParent')
-> happened when calling DateTimeShortcuts.openCalendar(0);

• when I have tabbed through the options, I should loop within the datepicker. Instead I then tab through the top of the page
• when I hit "esc" I should be focused on the trigger button (and can continue to tab from their) but instead I am at the top of the page

@sarahboyce

• I have made changes and now it should work as you said.
• But I need help with writing tests.

@Antoliny0919 Any idea on how to write tests for the changes??

I wrote something like this and it failed

QUnit.test('calendar focus loop on tab navigation', function(assert) {
    const $ = django.jQuery;
    const dateField = $('<input type="text" class="vDateField" value="2015-03-16">');
    $('#qunit-fixture').append(dateField);

    DateTimeShortcuts.init();
    DateTimeShortcuts.openCalendar(0);

    const calendarDiv = $('#calendarbox0');
    assert.ok(calendarDiv.is(':visible'), 'Calendar is visible');

    const focusable = calendarDiv
        .find('a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])')
        .filter(':visible');
    const firstEl = focusable.first()[0];
    const lastEl = focusable.last()[0];

    // Move focus to the last element
    lastEl.focus();
    assert.strictEqual(
        document.activeElement,
        lastEl,
        'Last element is focused'
    );

    $(lastEl).trigger($.Event('keydown', { which: 9 }));

    assert.strictEqual(
        document.activeElement,
        firstEl,
        'After tabbing from last element focus loops back to first'
    );

    DateTimeShortcuts.dismissCalendar(0);
});

Died on test 1: Cannot read properties of null (reading 'offsetParent') -> happened when calling DateTimeShortcuts.openCalendar(0);

Test looks good.
However, I personally prefer Selenium tests.
I think they will be easier to maintain in the long run.
I wrote a test that checks which element receives focus when the date picker is triggered with the Enter key.
Other tests could probably be written in a similar format.

index c47e0e3ec1..3a9ac3f9d9 100644
--- a/tests/admin_widgets/tests.py
+++ b/tests/admin_widgets/tests.py
@@ -1176,6 +1176,23 @@ class DateTimePickerSeleniumTests(AdminWidgetSeleniumTestCase):
                     # The right month and year are displayed.
                     self.wait_for_text("#calendarin0 caption", expected_caption)
 
+    def test_calendar_press_enter_focus_element(self):
+        from selenium.webdriver.common.by import By
+        from selenium.webdriver.common.keys import Keys
+
+        self.admin_login(username="super", password="secret", login_url="/")
+        self.selenium.get(
+            self.live_server_url + reverse("admin:admin_widgets_member_add")
+        )
+
+        icon = self.selenium.find_element(By.ID, "calendarlink0")
+        expected_focus_element = self.selenium.find_element(
+            By.CSS_SELECTOR, "div#calendarin0 table td.today a"
+        )
+        icon.send_keys(Keys.ENTER)
+        focused_element = self.selenium.switch_to.active_element
+        self.assertEqual(expected_focus_element, focused_element)
+

Thank you for the PR @XChaitanyaX ⭐

Note that we will need tests for the changes, this could either be a selenium test or a javascript test in js_tests/admin/DateTimeShortcuts.test.js

I have tested and the focus does go in the popup window of the datepicker, however:

* when I have tabbed through the options, I should loop within the datepicker. Instead I then tab through the top of the page

* when I hit "esc" I should be focused on the trigger button (and can continue to tab from their) but instead I am at the top of the page

See: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction

Should the tab navigation within the datepicker also be part of this work?
I thought handling tab navigation inside the dialog should be addressed in the DatePicker accessibility improvement ticket.
But if it is meant to be included here, I’ll make sure to review the focus navigation as well
I’ll follow your opinion 🥰

Should the tab navigation within the datepicker also be part of this work?

The same is true of the clock widget. I think this ticket should ideally be scoped for keyboard navigation of widget popups 👍

So, the goals we should aim to achieve in this PR are as follows:

• Assign focus to the appropriate element when pressing Enter on the DateTime picker icon.
  As mentioned before, for the Date field, if no date is selected, the focus should default to today’s date. If a date is selected, the focus should move to that date.
  For the Time field, focusing on “now” seems to be the most appropriate behavior.

• Enable keyboard navigation within the DateTime dialog.
  Similar to the W3C example for date pickers, users should be able to navigate between day elements using the arrow keys.
  This is important because the focus should not be limited to just date selection, users must also be able to access other interactive elements like "Yesterday," "Tomorrow," "Close," etc.
  Additionally, as Sarah suggested, we need to consider what happens when the user reaches the last focusable element.
  In the W3C example, focus moves to the next or previous month in such cases.

Thinking about it, implementing all of these features would likely require a significant amount of Javascript and test coverage.
As Sarah previously suggested, switching to a native input type="date" element instead of maintaining the current widget could reduce the maintenance burden, and at the same time, naturally improve accessibility.
That makes suggestion feel even more appealing.

I believe we need a clear direction for what we want to achieve in this PR.
In my opinion, we should discuss this further with the accessibility team.

I'm happy for the accessibility team to come up with a plan for the widgets
Currently as I can tab through the options in the widget (rather than arrow through), I'm less concerned about this as a "blocker"