Improve accessibility of the buttons inside the AdminDateWidget dialog using ARIA attributes

[Antoliny]

The shortcuts provided in the current admin page lack sufficient descriptions for screen reader users.

Using the datetime shortcut as an example, when a screen reader accesses each button representing a date, the following description is provided.

The above description feels insufficient. By using attributes like aria-label to clearly indicate the exact year, month, and day of each button, screen reader users will be able to accurately anticipate which DateTime value corresponds to the button they are accessing.

In addition, shortcut buttons like yesterday, tomorrow, and today, as well as the buttons for navigating to the previous and next month, should have detailed date-related descriptions. The close button for the dialog should also clearly convey its exact purpose.

[Sarah Boyce]

I think this ticket is worth keeping to track that the current design has accessibility problems.

I do however think that we might want to deprecate the AdminDateWidget and instead use the HTML5 <input type="date"> (see ​https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date) which has a datepicker native to the browser. I believe this is more accessible than what we have (see also ​https://www.youtube.com/watch?v=f2pkCDcAUwA). It also stops us having something custom we need to maintain and improve the accessibility of.

[Antoliny]

Replying to Sarah Boyce:

I think this ticket is worth keeping to track that the current design has accessibility problems.

I do however think that we might want to deprecate the AdminDateWidget and instead use the HTML5 <input type="date"> (see ​https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date) which has a datepicker native to the browser. I believe this is more accessible than what we have (see also ​https://www.youtube.com/watch?v=f2pkCDcAUwA). It also stops us having something custom we need to maintain and improve the accessibility of.

I agree. It’s good that there is no need to maintain a custom widget or improve its accessibility separately.
Additionally, it is true that the <input type="date"> tag has better accessibility and usability compared to the current AdminDateWidget.
However, I think there are a few issues.
As far as I know, <input type="date"> makes it a bit difficult to freely customize the input format.
I understand that the input format changes according to the browser’s locale, whereas AdminDateWidget offers a bit more flexibility in that regard.

Also, when considering consistency in styling between Date fields and their subordinate Time fields, such as in DateTime inputs, it might feel somewhat awkward.
Of course, this might be adjustable.
In my opinion, improving accessibility while keeping the current widget is also perfectly fine.
What do you think about making it by referring to this ​site?

Not only for accessibility, but it would also be great to add buttons that allow quickly jumping(previous year, next year) year :)