feat: add keyboard accessibility for timepicker

[asajjad2]

What are the relevant tickets?

#9097

Description (What does it do?)

Time fields in Schedule settings rely on react-datepicker's time-only popover. This PR adds ARIA labels and screenreader hints to improve accessibility for keyboard and screen-reader users.

Note: Keyboard navigation (ArrowUp/ArrowDown and Enter key) for the time picker is now handled upstream in react-datepicker. This PR focuses solely on adding proper ARIA labels and screenreader instructions.

The changes include:

• Adding ariaLabel to the time picker input with instructions about using arrow keys
• Adding ariaDescribedBy to associate the input with screenreader hints
• Adding a screenreader-only hint text that explains the time format and provides an example
• Ensuring help text has proper id attributes for ARIA associations

Screencast (this is now handled in react-datepicker upstream)

Screen.Recording.2025-11-11.at.3.38.55.PM.mov

How can this be tested?

1. On schedule page, open a time field with a screenreader enabled - the aria label and hint should be announced
2. Verify the time picker input has proper aria-label and aria-describedby attributes
3. Verify mouse interactions still work as before

[openedx-webhooks]

Thanks for the pull request, @asajjad2!

This repository is currently maintained by @bradenmacdonald.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[codecov]

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.78%. Comparing base (3089d0b) to head (e29b26b).
⚠️ Report is 1275 commits behind head on master.

Files with missing lines	Patch %	Lines
...c/generic/datepicker-control/DatepickerControl.jsx	93.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2613      +/-   ##
==========================================
+ Coverage   93.02%   94.78%   +1.75%     
==========================================
  Files         756     1235     +479     
  Lines       13708    28033   +14325     
  Branches     2961     6365    +3404     
==========================================
+ Hits        12752    26571   +13819     
- Misses        920     1387     +467     
- Partials       36       75      +39     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bradenmacdonald]

Thanks, this looks nice! Please let me know when it's ready for review.

Also, will this work with v8 ? #2572
Ideally we could add this functionality and do the version bump at the same time.

[bradenmacdonald]

Thanks for this PR! Unfortunately I am seeing a few issues.

Here is a screenshot of Chrome's a11y view showing all the issues:

1. The ariaLabel prop you gave is being ignored. If you put // @ts-check at the top of the file, you'll see that DatePicker doesn't accept an ariaLabel prop, and it also seems to ignore aria-label. You can also see in my screenshot that this element has no accessible name/label other than its placeholder ("HH:MM") which isn't helpful.
   
2. There is a <label> element from the <Form.Group> that is supposed to be providing a label (e.g. "Course start time") for this control, but the id prop is not being set on the <DatePicker>/<input> element, so the Form.Group is broken and the label is invalid - which Chrome's a11y viewer is warning about. We need to either generate a unique ID and pass it to the Form.Group as controlId, or use the form group context to get the auto-generated ID and pass it in to the <DatePicker>/<input>. This is affecting the dates as well as the times.