User tests: Successful: Unsuccessful:
Pull Request resolves #24019
Also replaces this incomplete PR #47672
The calendar keyboard navigation has been updated to provide consistent keyboard behaviour for both the calendar and its time controls. It has never been accessible for a keyboard user.
It was impossible for a keyboard user to do anything other than change the date.
They could never reach the time fields or the button.
If it was an empty date field then they couldnt use the picker at all as you couldnt select a day with the keyboard and you couldnt reach the buttons with the keyboard
This PR has taken me a while as I have had to learn the js and find a mentor to support me in writing it but the PBF was a good opportunity to complete it but I believe it addresses all keyboard navigation issues with the calendar
This follows accessibility practice of "is it better than yesterday? Not is it perfect"
The changes to test:
<select> controls now handle their arrow keys nativelyPlease test with a calendar field that has a date value already and one that doesnt
eg for a saved article the Start Publishing already has a value and the Finish Publishing is empty
Go to Content/Article/New or Edit / Publishing tab
Use Tab key to move focus to calendar field
Use Tab key to move focus to calendar button
Ue space or enter key to open calendar
Use Left/Right/Down/Up arrows to select date
Use Tab key or Shift + Tab key to move focus to hours/minutes and then Clear/Today/Close buttons
Use Space/Enter key to place selected date into field and close the popup
This is a js change so you will need to either npm run build:js or use a prebuilt package to test
Please select:
Documentation link for guide.joomla.org:
No documentation changes for guide.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
| Category | ⇒ | JavaScript Repository NPM Change |
I have tested this item ✅ successfully on 506ea3f
Tested the PR and everything works like described. I tested inside a publishing tab and with a custom field too.
I have tested this item ✅ successfully on 506ea3f
I have tested this item ✅ successfully on 506ea3f
| Status | Pending | ⇒ | Ready to Commit |
RTC
RTC
I have tested this item ✅ successfully on 506ea3f
I have tested this item ✅ successfully on 506ea3f
@brianteeman Code style looks weird here: https://github.com/joomla/joomla-cms/pull/48286/changes
The reason is that the file uses tabs for indentation, while your changes correctly use spaces.
When checking the changed file via "view file" on GitHub you will not even notice as that seems to use a tab size of 2 chars: https://github.com/brianteeman/joomla-cms/blob/506ea3f64f7c712bc748312831aeb5b2050938f8/build/media_source/system/js/fields/calendar.es5.js
As I don't wand to ask you to fix the code style for the whole file, maybe you could adjust your changes to the file and use tabs?
It would not require new tests after that change.
What is the code style for this type of file? I should style it to follow our specs BUT shouldn't the lint have detected this anyway?
What is the code style for this type of file? I should style it to follow our specs BUT shouldn't the lint have detected this anyway?
@brianteeman I have no idea why the linter doesn't complain in 5.4-dev. Maybe it would in 6.2-dev as there was an update to it. I think our code style for any kind of JS is to use 2 spaces for each level of indentation, but I am not 100% sure right now if that also applies to the es5 files.
Maybe @dgrammatiko has an idea, or @heelc29 ?
@brianteeman As far as I can see, we have 3 other es5 files in the same folder which also use tabs, files color-field-adv-init.es5.js, modal-fields.es5.js and tag.es5.js. All others use spaces as it should be.
I've asked other maintainer for opinions and will come back with a proposal how to proceed, to keep the tabs in that file for now and change it later with a separate PR together with the 3 other files, or to change the complete calendar.es5.js file to spaces here and do only the 3 other files later.
I await your response before making any changes
@brianteeman In 6.2-dev the linter has been fixed: #47962
But .es5.js files are excluded from linting in 6.2-dev: https://github.com/joomla/joomla-cms/blob/6.2-dev/build/eslint.config.mjs#L14-L18
A lot of .es5.js files have been converted into .es6.js in 6.2-dev and those use spaces. A few .es5.js files are remaining which use tabs.
So I would say stick with the tabs in that file, and that's the feedback I also got from other maintainers.
| Labels |
Added:
RTC
NPM Resource Changed
PR-5.4-dev
|
||
Updated indentation to use tabs throughout the file as requested
Updated indentation to use tabs throughout the file as requested
Thanks @brianteeman .
RTC is still valid as the commit after the 3 successful human tests was only code style.
| Labels |
Added:
a11y
bug
|
||
✅ Final test before merge with JBT
pm run build:js
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-08-28 12:59:05 |
| Closed_By | ⇒ | muhme |
Thank you very much @brianteeman for your contribution. Thanks to @krishnagandhicode, @rbuelund and @coolcat-creations for testing.
Thanks
I have tested this item ✅ successfully on 506ea3f
Tested the PR and everything works like described. I tested inside a publishing tab and with a custom field too.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48286.