1993756 - Refactor datetime-local picker's ARIA role management to avoid direct DOM manipulation by "TimePicker.init()"

Status: NEW

(Core :: Layout: Form Controls, task)

Description

[Anna Yeddi [:ayeddi]]

Current behavior:

When a datetime-local input is displayed, the TimePicker.init() method manually adjusts ARIA roles and attributes for both the date picker and time picker components to avoid having two modal dialogs in one panel (lines 37–55 in toolkit/content/widgets/timepicker.js). By default, each date and time panels has its own role="dialog" aria-modal="true".

This approach works functionally but introduces several issues:

1. The time picker is modifying the date picker’s ARIA attributes, creating unnecessary coupling between the two components
2. The logic currently lives inside TimePicker.init(), which is not the ideal location for managing panel-level structure and semantics
3. It performs DOM manipulation that should ideally be managed by the parent panel or container logic

Current implementation details:

When type="datetime-local":

• TimePicker.init() changes both the time picker and date picker roles from dialog to group
• It removes aria-modal from both picker panel elements
• It sets the parent datetime-picker container to role="dialog" with aria-modal="true"

Desired behavior:

The ARIA role and attribute management should be centralized and handled in a more appropriate location, i.e.:

• In the DateTimePickerPanel.sys.mjs (the panel controller), or
• In the datetimepicker.xhtml initialization code, or
• Through a shared initialization pattern that ensures each picker manages its own semantics without directly modifying another component’s DOM.

Recommendation:

Refactor ARIA role management so that:

1. The TimePicker and DatePicker components remain self-contained and do not modify each other’s attributes.
2. The panel or container code is responsible for assigning the correct ARIA roles (dialog, group) and aria-modal attributes based on context.
3. Future accessibility logic for modal and non-modal picker behavior can be extended cleanly without introducing cross-component dependencies.

Reference:

• Phabricator D167463 review comments