Steps to reproduce the issue

Audit finding

The calendar/date-time picker has barriers affecting keyboard operation and screen reader feedback.

The original audit reports these problems

• Keyboard interaction can visibly change the calendar without providing a way to confirm the chosen date or time
• Screen reader users do not receive sufficient information about the date being navigated
• Month and year navigation controls are not keyboard reachable in the audited implementation
• Hour and minute selectors have no accessible names

The issue was subsequently reopened after further testing reported remaining keyboard-navigation problems and incorrect date announcements in NVDA.

These findings should be checked individually in the current build rather than describing the widget as wholly unusable or assuming that an earlier improvement resolved every interaction.

User impact

Keyboard users may be able to open the calendar or move its visual highlight but still be unable to reach the month/year controls or confirm the date they intended to choose.

Screen reader users cannot reliably select a date if the calendar announces “blank” or an unrelated number instead of the date being navigated. Unnamed hour and minute selectors also make it difficult to identify which part of the time is being changed.

For article publishing, these barriers interfere with choosing when publication begins or ends. Users may have to abandon the picker and enter a value manually, if that route is available and its required format is understood.

An inaccurate selection can affect the intended publishing schedule, so users need a reliable way to identify, confirm, and review the resulting date and time.

Remediation plan

Implement a complete, consistent keyboard and screen reader interaction for the shared date-time picker

• Choose and document the component's interaction model before adjusting individual focus handlers
• Make the calendar-opening control keyboard operable and identify the associated date field
• Give the popup or dialog an accessible name and expose its open state through an appropriate relationship with the trigger
• Place focus appropriately when the picker opens
• Provide keyboard-reachable controls for changing the month and year
• Use buttons for month/year actions rather than relying on non-interactive anchor elements
• Give navigation controls descriptive names such as “Next month” and “Previous year”
• Provide a consistent keyboard method for moving between dates and confirming the intended date
• Expose the date associated with the active calendar cell and distinguish focused, selected, current, and unavailable dates where those states apply
• Announce month and year changes so that users retain calendar context
• Give the hour and minute selectors explicit accessible names and expose their current values
• Provide a predictable way to confirm or dismiss the picker and return focus to the associated field or opening control
• If using a modal dialog, contain keyboard focus within it while open
• If using a non-modal popup, provide a logical route out rather than adding a focus trap solely because the calendar is visible
• Preserve manual date entry where supported and associate format instructions and validation messages with the field
• Test the integrated component with keyboard input and supported screen reader/browser combinations
• Use established date-picker patterns as implementation guidance, not as untested production code to copy unchanged

Preconditions

• Use Joomla 6.2
• Use Atum for backend testing and Cassiopeia for frontend testing
• Sign in with an account permitted to edit the test article and its publishing fields
• Use a test article and record its existing date/time values
• Record the exact Joomla build or commit and whether it includes the calendar changes associated with PR #48286
• Record the browser name and version, operating system, and screen reader version
• Record the site's language and time-zone configuration
• Do not save unintended changes to article dates or publishing schedules

Steps to reproduce — backend keyboard operation

1. Open the Joomla administrator interface at the site's base URL followed by /administrator/
2. Open Content → Articles
3. Open the test article for editing
4. Open the Publishing tab
   • Record the tab label if it differs in the tested configuration
5. Locate Start Publishing and its calendar-opening control
6. Record the field's existing value
7. Use Tab or Shift+Tab to reach the calendar-opening control
8. Activate it using the keyboard
9. Record where focus is placed when the calendar appears
   • Distinguish focus remaining in the text field from focus moving into the calendar
10. Check whether instructions identify the available calendar keys
11. Use the supported keyboard interaction to move to another date
    • Where arrow-key navigation is provided, test movement in more than one direction
    • Record whether only the visible highlight changes or whether the active date is also exposed programmatically
12. Attempt to confirm the intended date using the supported keyboard action
13. Record whether the field receives the intended value
14. Reopen the picker and attempt to reach the previous/next month and previous/next year controls
15. Activate the reachable navigation controls and record the result
16. Where time controls are present, attempt to reach and change the hour and minute
17. Check whether the intended date and time can be confirmed without using a pointer
18. Dismiss the picker and record the return-focus location
19. Repeat for End Publishing and Created Date where those fields are available
    • Record differences between fields rather than assuming that all use identical settings

Steps to reproduce — screen reader date feedback

1. Enable NVDA with an available supported browser and record both versions
   • The reopening comment specifically reports incorrect date announcements in NVDA
2. Return to the test article's Publishing tab
3. Open the Start Publishing calendar using the keyboard
4. Record the popup or dialog name and the initial date information announced
5. Move between dates using the widget's keyboard interaction
6. Compare each announced value with the visually active date
7. Record the exact announcements when moving in both directions
   • Check whether the reported “blank” or “one” announcements recur
   • Do not assume that those exact words occur in every build or browser
8. Change the displayed month or year using available keyboard controls
9. Check whether the new month/year context is announced
10. Navigate to the hour and minute selectors where present
11. Record each selector's accessible name and announced value
12. Confirm a test date/time and review the resulting field value
13. Dismiss or reopen the picker and check whether focus and date context remain understandable
14. Repeat with other supported screen reader/browser combinations where available

Supplementary semantic and focus check

1. Inspect the month/year navigation controls using Developer Tools or the browser's accessibility inspector
2. Record their element types, roles, accessible names, and keyboard reachability
3. If a control is an anchor without an href, check whether any other implementation makes it keyboard operable
   • Do not infer the complete interaction solely from the element name
4. Inspect the calendar's active and selected date states
5. Inspect the hour and minute selectors for accessible names
6. Determine whether the picker is implemented as a modal dialog or a non-modal popup
7. Test Tab, Shift+Tab, and the supported dismissal action against that interaction model
8. Record unexpected focus loss separately from an intentional exit from a non-modal popup

Frontend verification

1. Sign in to the frontend with an account permitted to edit the test article
2. Open the article's frontend editing form
3. Locate an available publishing date field and its picker
   • Record the field and form URL
   • If the required publishing fields are unavailable to the account, record the missing test setup rather than a calendar failure
4. Repeat the keyboard navigation, date confirmation, screen reader feedback, and time-label checks
5. Record any difference from the backend component
6. Close the editing form without saving unintended changes

Version

6.2

Expected result

Users can open the picker, navigate dates and months/years, adjust available time values, confirm a selection, and dismiss the component using the keyboard.

Screen readers identify the date being navigated, relevant calendar states, and the hour and minute controls.

Focus follows the chosen modal or non-modal interaction model and returns to a logical location when the picker closes.

The confirmed field value matches the intended date and time.

Actual result

The original audit reports incomplete keyboard selection and confirmation, missing calendar-date feedback, unreachable month/year controls, and unnamed hour/minute selectors.

Later testing in the issue discussion reports remaining unreachable navigation controls and incorrect NVDA announcements when moving between dates.

The original and later observations need to be verified separately against the Joomla 6.2 build being tested, including any earlier calendar improvements.

What device were you using? (eg, phone, laptop)

Desktop web

What web browser were you using? (eg, Chrome, Safari)

Chrome, Firefox, Edge, Safari

Assistive Technology?

VoiceOver, JAWS, NVDA

Additional Comments

The browser and assistive-technology entries above are carried forward from the original issue and do not represent a new verification of every combination against Joomla 6.2.

The issue was closed after PR #48286 was cited as an improvement, then reopened following further testing reported on 20 October 2026. Record the tested build so that resolved and remaining defects can be distinguished.

The reopening comment reports that focus is not contained within the widget. Whether containment is required depends on whether the implementation is modal; a non-modal popup should not automatically be given a modal focus trap.

The original report identifies both frontend and backend forms, but available fields depend on permissions and form configuration.

The WAI ARIA Authoring Practices Date Picker Dialog Example is an implementation reference, not a requirement to adopt that exact modal design: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/datepicker-dialog/

MS2b is proposed for the shared complex calendar component, with MS3a and MS3b covering its frontend and backend integration. These are scope-based recommendations rather than confirmed project assignments.