Determine if date picker's calendar grid should act more like a modeless dialog

[asudoh]

In #5445, @dakahn had a comment referring to https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker as a benchmark of our date picker UI.

Some notable things in dequeuniversity.com's behavior are:

1. The calendar icon acts as a trigger button to open the calendar grid, and works as the only means to open the calendar grid
2. The calendar grid has focus-wrap behavior (The focus sequence with tab key and shift-tab key won't go out of the calendar grid, unless calendar grid is closed by different means e.g. hitting ESC key)

Above two makes the dequeuniversity.com's UI acts more like a modeless dialog, though the grid doesn't seem to have such ARIA role.

This issue is to discuss if we should incorporate that behavior in part or a whole. Determining that requires our @carbon-design-system/design's input.

CC @carmacleod @snidersd

[carmacleod]

The Deque example behaves very much like the APG DatePicker Dialog example.

However, they use different markup.

The Deque example uses role="application", which doesn't convey the idea that "you're in a dialog and the tab key is trapped". It also doesn't let screen readers use their reading keys to navigate around the dialog, but maybe that's not necessary, as the tab key and arrow keys work ok.

The APG DatePicker dialog example uses role="dialog" aria-modal="true", which this tells the user that this is a modal dialog and that the tab key will be trapped. It also tells the user that the escape key will close it. It lets users navigate to the buttons using their reading keys, including the 'b' key to "go to next button", and table navigation keys in the grid. (Note that this example may have an issue with aria-selected).

You could consider asking some real users to try both examples to see which one they prefer.

Alternatively, you could consider implementing the datepicker as a combobox. The APG task force is working on an example of a DatePicker combobox. It's not finished yet, but it's getting close.

There are so many date pickers that claim to be accessible that it's hard to know which pattern to follow. :)

[grahamharper]

Here is the DatePicker combobox example: https://w3c.github.io/aria-practices/examples/combobox/combobox-datepicker.html

It's very similar to the Carbon DatePicker but a few notable improvements:

1. The picker doesn't open when the field receives TAB focus, only on click and down-arrow (or alt down-arrow). Opening on focus is a problem with Carbon Date Picker because if it's the first field in a modal, it opens when the modal opens and also if tabbing through a form with date inputs, the picker opening and closing is annoying.
2. The picker dialog is a tab-trap and the month and year buttons are tab-focussable.

[tw15egan]

@grahamharper both of those enhancements make sense to me, wondering if these are some small a11y wins we could add in to improve the Datepicker UX @dakahn?

[dakahn]

Let's do it 👍🏽 I don't see any downsides

[grahamharper]

Seeing as issue was closed, what was the outcome?

[grahamharper]

Any update on plans to implement this or not? Our team is particularly interested in:

1. Don't open the datepicker on focus, instead only open on click or down-arrow
2. The month and year buttons should be keyboard accessible

Our team could possibly offer dev assistance if needed.

[francesco-mariani]

Hi @dakahn,

any information on the outcome of this ticket would be appreciated, as I see it has been closed.

Moreover
#5573 (comment)
From an accessibility point of view, we do not provide screen reader users with information around the popup that appears on focus. I did a quick test on Chrome and with VO.

Thanks in advance