1676068 - Consider making datetime picker popup fully keyboard accessible

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, enhancement, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

See the commit description in bug 1608046 for what this means. Quoting:

Eventually, having a fully accessible popup is preferable, but even
though this doesn't allow you to navigate the popup on its own, it
allows you to see it update as you use the arrows or other keyboard
input to see the date, which I think is valuable.

This bug is for the "preferable" option.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I'm going to call this S3 but if any accessibility folks disagree please do change it :)

FWIW as a sometimes-mostly-keyboard-user, I find our behavior after bug 1608046 pretty much as useful if not more as Chromium's. But of course opinions may vary.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

I'm going to call this S3 but if any accessibility folks disagree please let me know! FWIW as a sometimes-mostly-keyboard-user, I find our behavior after bug 1608046 pretty much as useful if not more as Chromium's.

A bit less fancy, that being said.

Comment 3

[James Teh [:Jamie] (away returning 28 Jan)]

I provided a lot of detail in bug 1608046 comment 8, so including that below (with some minor edits for context and updated situation).

It's true that you can change the date with your keyboard easily when you know the exact date you want, but one advantage of the date picker is that it allows you to easily choose the date in terms of week days, rather than doing the math in your head or using an external calendar. For example, you can pretty easily choose one week from today or next Monday. After the patch for bug 1608046 lands, sighted keyboard users can at least activate the picker to see the week dates and enter them manually. However, that's not particularly elegant and it's also no help for screen reader users.

Beyond keyboard activation, here's what needs to happen:

1. Activating the date picker should focus it.
2. The buttons to change the month need to be actionable from the keyboard. Right now, they only work if you click them.
3. The buttons to change to next/previous month should be labelled.
4. The picker grid needs to be a grid semantically, either using an HTML table or ARIA grid.
5. The grid must be focusable (single tab stop). It should probably get auto-focused when the picker is focused.
6. The active day in the grid should get aria-activedescendant.
7. Left/right arrow should move by day, up/down arrow by week, page up/page down by month.
8. Enter should select the active day and dismiss the picker.
9. When the month selector is activated, it should get focus and needs to be a semantic grid similar to the day grid, with similar keyboard support.

Comment 4

[Chris Mills [:cmills]]

Probably doesn't need much in the way of docs updates, but would be nice to announce it somehow.

Comment 5

[Anna Yeddi [:ayeddi]]

Attachment: WIP: Bug 1676068 - Move keyboard focus to the DateTimePickerParent when Date Picker is opened. r=Jamie

Comment 6

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.1 - Change DateTimePicker markup to HTML Table with ARIA Grid. r?Jamie!,flod!,mconley!,kcochrane!

Comment 7

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.2 - Add ARIA Spinbutton properties and updates CSS for consistency. r?Jamie!,morgan!,mconley!,kcochrane!

Depends on D139980

Comment 8

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.3 - Replace Reset button in the DateTimeBox with Calendar one. r?Jamie!,mconley!,kcochrane!

Depends on D139980 and D139981

Functionality was updated.

ToDo:

1. SVG is expected to be returned from the UI (Sam Foster) after some optimization - will be updated
2. Button's l18n label will be updated
3. Tests to be added/updated

Depends on D139981

Comment 9

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.4 - Update keyboard support for a DateTimePicker. r=Jamie!,mconley!,kcochrane!

ToDo:

1. Follow the ARIA Date picker dialog keyboard navigation pattern
2. Ensure proper styling for Spinbutton while navigating with a keyboard
3. Add/update tests

Depends on D141175

Comment 10

[Eemeli Aro [:eemeli]]

I just noticed that there's some overlap between the patches for this bug and bug 1734221. OTOH, it's good to see that in the overlap they both create the same locales/en-US/toolkit/global/datetimebox.ftl file and apply pretty much the same code changes to toolkit/content/widgets/datetimebox.js. 😀

Comment 12

[Anna Yeddi [:ayeddi]]

Requirements update

(In reply to James Teh [:Jamie] from comment #3)

[...]
Beyond keyboard activation, here's what needs to happen:

[...]
9. When the month selector is activated, it should get focus and needs to be a semantic grid similar to the day grid, with similar keyboard support.

This point was not covered in this bugwork per discussions with Jamie, because the existent behavior is to open a new modal dialog (on top of the datepicker dialog, with the same size and position visually, but as a descendant of the main dialog in the DOM) when a month selection (Month-Year button) is activated and the month selection dialog to include the Month-Year button itself and two spinbuttons - one for a month and one for a year selection.

If we were to create a grid, this would require UI change which would be out of scope of this enhancement. I will log a new ticket to discuss if we want to do it in the future.

Status update:

• Patches are under reviews
• Targeting 109 train
• The QA team is ready to start testing in Nightly when the patches land
• There are a few minor updates that would need to be done as a follow up to this major datepicker a11y update - these will be separate tickets.

Comment 13

[James Teh [:Jamie] (away returning 28 Jan)]

(In reply to Anna Yeddi [:ayeddi] from comment #12)

9. When the month selector is activated, it should get focus and needs to be a semantic grid similar to the day grid, with similar keyboard support.

This point was not covered in this bugwork per discussions with Jamie, because the existent behavior is to open a new modal dialog (on top of the datepicker dialog, with the same size and position visually, but as a descendant of the main dialog in the DOM) when a month selection (Month-Year button) is activated and the month selection dialog to include the Month-Year button itself and two spinbuttons - one for a month and one for a year selection.

If we were to create a grid, this would require UI change which would be out of scope of this enhancement. I will log a new ticket to discuss if we want to do it in the future.

We probably don't need to discuss this further. I think this was due to my misunderstanding of how the UI worked, given that it was previously inaccessible and I didn't have sighted assistance when investigating it. Two spin buttons seems perfectly reasonable to me.

Comment 14

[Anna Yeddi [:ayeddi]]

(In reply to James Teh [:Jamie] from comment #13)

(In reply to Anna Yeddi [:ayeddi] from comment #12)

[...]
If we were to create a grid, this would require UI change which would be out of scope of this enhancement. I will log a new ticket to discuss if we want to do it in the future.

We probably don't need to discuss this further. I think this was due to my misunderstanding of how the UI worked, given that it was previously inaccessible and I didn't have sighted assistance when investigating it. Two spin buttons seems perfectly reasonable to me.

Got it. Thank you, Jamie!

Adding a keyboard nav guide for future references:

Keyboard behavior expected

1. An <input type=date> and <input type=datetime-local>:
   1. Enter/Space on the Calendar button should open a datepicker dialog and move the focus to a date within the calendar grid
   2. Tab from the last editable field (“YYYY” in en_US locale) moves the keyboard focus to the Calendar button
   3. Enter/Space on the Calendar button should open a datepicker dialog and move the focus to a date within the calendar grid
   4. Tab and Shift + Tab moves the focus away from the Calendar button, when it is focused and no datepicker is opened
2. Datepicker dialog:
   1. Tab and Shift + Tab should move the focus between controls of the datepicker (a day in the calendar grid, Previous month button, month-year selection button, Next month button)
   2. Enter/Space on the Previous/Next month button should activate it and update the calendar view and a month-year selection button text
   3. Enter/Space on the month-year selection button should activate it (expand it) and open a month selection modal dialog on top of the datepicker, while focus should stay on the month-year selection button
   4. Escape from any focus position should dismiss the dialog and return focus to the input field
3. Date selection Calendar grid:
   1. Left Arrow/Right Arrow should move the focus by day
   2. Up Arrow/Down Arrow should move the focus by week
   3. Page Up/Page Down changes the view to the previous month and sets focus on the same day. If that day does not exist, then it moves focus to the same day of the same week.
   4. Shift + Page Up and Shift + Page Down changes the view to the previous month and sets focus on the same day. If that day does not exist, then it moves focus to the same day of the same week.
   5. Home/End to select the first day/last of the current week
   6. Ctrl + Home and Ctrl + End to select the first day/last of the current month
   7. Enter/Space should select the active day and dismiss the picker
   8. Tab and Shift + Tab should move the focus from the calendar date to Next/Previous month button and circles between controls of the dialog (focused day on the calendar, Previous button, Month-year selection button, Next month button)
   9. Escape from any focus position to close the datepicker and return focus to the input field (to its control that opened the datepicker previously)
4. Month selection dialog:
   1. Tab and Shift + Tab should move the focus between controls of the month-year selection dialog (month-year selection button, month selection spinbutton, year selection spinbutton)
   2. Enter/Space on the month-year selection button should activate it (collapse it) and close a month selection modal dialog returning to the datepicker dialog, while focus should stay on the month-year selection button
   3. Escape from any focus position should dismiss the dialog and return focus to the input field (to its control that opened the datepicker previously)
5. Month/Year selection Spinbuttons, when a spinbutton is focused:
   1. Up Arrow/Down Arrow should increase/decrease the value by 1 step
   2. Page Up/Page Down should increase/decrease the value by 5 steps
   3. Home/End should select the min/max value
   4. Enter/Space selects the current value of the spinbutton (value that is centered)
6. Month/Year selection Spinbuttons’ Up and Down buttons should not be focusable.

Comment 15

[Sergi Almacellas Abellana]

Hi,

I see this improves the datetime popup for datetime-local widgets.
Does this patch add the time picker so we will be able to pick both date and time widgets?

How can I tests this feature? Is available on firefox nightly or should I build it myself to test it?

TIA.

Comment 16

[Anna Yeddi [:ayeddi]]

(In reply to Sergi Almacellas Abellana from comment #15)

Hi,

I see this improves the datetime popup for datetime-local widgets.
Does this patch add the time picker so we will be able to pick both date and time widgets?

How can I tests this feature? Is available on firefox nightly or should I build it myself to test it?

TIA.

Hi Sergi,

The feature is not yet landed, but you are welcome to pull the attached stack of patches and build it locally to test - I am actively working on finalizing it, so while there may be slight changes in the code down the line, but they should not affect the built functionality (i.e. it could resolve some edge cases or refactor test code). I will post here once all the patches are approved and are landing.

This bugwork does not add time picker panel, but I filed another bug 1802202 to consider flipping the pref dom.forms.datetime.timepicker to true by default - this would show the time picker on time fields within <input type=datetime-local> and <input type=time>. Please feel free to comment a thumbs up in there, if you think that would be good to have ;)

That's being said, the spinner.js work done for this bug would drastically improve the a11y of the time picker panel already.

(Updated to add a phab link)

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ca2fed771557
Datepicker Pt.1 - Change DateTimePicker markup to HTML Table with ARIA Grid. r=Jamie,desktop-theme-reviewers,fluent-reviewers,flod,dao,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/fc1c62ea6542
Datepicker Pt.2 - Add ARIA Spinbutton properties and updates CSS for consistency. r=Jamie,morgan,fluent-reviewers,mconley,kcochrane,flod
https://hg.mozilla.org/integration/autoland/rev/7ba99b58ac35
Datepicker Pt.3 - Replace Reset button in the DateTimeBox with Calendar one. r=Jamie,fluent-reviewers,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/3e8b24890eb2
Datepicker Pt.4 - Update keyboard support for a DateTimePicker. r=Jamie,mconley,kcochrane

Comment 18

[Cristian Tuns]

Backed out for causing mochitest failures

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | toolkit/content/tests/browser/browser_spinner_keynav.js | Uncaught exception in test - Should change to December 2030, instead got December 2020 - timed out after 50 tries.
• Failure Log 2
• Failure line 2: TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_date)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_datetime-local)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_date_required)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_datetime-local_required)

geckoview Failures : https://treeherder.mozilla.org/logviewer?job_id=398364807&repo=autoland

Comment 19

[Anna Yeddi [:ayeddi]]

(In reply to Cristian Tuns from comment #18)

Backed out for causing mochitest failures

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | toolkit/content/tests/browser/browser_spinner_keynav.js | Uncaught exception in test - Should change to December 2030, instead got December 2020 - timed out after 50 tries.
• Failure Log 2
• Failure line 2: TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_date)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_datetime-local)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_date_required)
  TEST-UNEXPECTED-FAIL | dom/html/test/forms/test_input_datetime_calendar_button.html | Calendar button is hidden on mobile/tablet (id_datetime-local_required)

geckoview Failures : https://treeherder.mozilla.org/logviewer?job_id=398364807&repo=autoland

Thank you very much! I addressed these 2 flagged issues (that cause 5 failures above) in the patch:

1. toolkit/content/tests/browser/browser_spinner_keynav.js: As the stack was backed out because of the End test failing which does happen inconsistently and seems to be caused by the event synthesis (see the bug 1803612) rather than the logic introduced by this patch, plus this works in human testing on macOS and Win, I wrapped these 3 checks in the todo and filed bug 1803664 to update it when the event issue is resolved.
2. dom/html/test/forms/test_input_datetime_calendar_button.html: Further investigation with @eeejay showed that this test was never actually true, because the mobile devices do not "hide" the button (then - Reset, now - Calendar), they either show it like Fenix/Android does or replace it with their own date picker altogether as iOS does. This is why I never came across any user agent-dependent logic within the datepicker-related files.
   1. Current behavior:
   2. Stable build on iOS does replace the field with its own date picker (attached to the next comment)
   3. And the Fenix Android does show the Reset button (not hiding it), tapping on the button activates it, tapping anywhere on the field opens the Android's own date picker (attached to the next comment)
   4. Expected behavior related to the button (as discussed with the UX team this past sprint): retain the same logic just replace the icon and its functionality.
   5. The test that I updated to be more precise was faulty to begin with and should not be there. I have corrected this historical mistake in the updated patch by removing the check for the user agent to preserve the existent logic of an in-input control as was approved by the UX team before.
   6. I can file a follow up bug for future investigations if we want to change the existent behavior at some point, but as I mentioned above this would be outside of this ticket's scope.

Comment 20

[Anna Yeddi [:ayeddi]]

Attachment: Android-Fenix-shows-Reset-button.png

Comment 21

[Anna Yeddi [:ayeddi]]

Attachment: iOS-replaces-the-field-with-its-own-picker.png

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/19a0b7a0987c
Datepicker Pt.1 - Change DateTimePicker markup to HTML Table with ARIA Grid. r=Jamie,desktop-theme-reviewers,fluent-reviewers,flod,dao,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/30a8292a37ae
Datepicker Pt.2 - Add ARIA Spinbutton properties and updates CSS for consistency. r=Jamie,morgan,fluent-reviewers,mconley,kcochrane,flod
https://hg.mozilla.org/integration/autoland/rev/0876924c66e8
Datepicker Pt.3 - Replace Reset button in the DateTimeBox with Calendar one. r=Jamie,fluent-reviewers,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/ee747c27b9bc
Datepicker Pt.4 - Update keyboard support for a DateTimePicker. r=Jamie,mconley,kcochrane

Comment 23

[Cristian Tuns]

Backed out for causing multiple failures.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | org.mozilla.geckoview.test.PromptDelegateTest#dateTestParameters | org.mozilla.geckoview.test.util.UiThreadUtils$TimeoutException: Timed out after 30000ms

log 2: https://treeherder.mozilla.org/logviewer?job_id=398395117&repo=autoland

Failure line 2: TEST-UNEXPECTED-FAIL | toolkit/content/tests/browser/browser_spinner_keynav.js | Uncaught exception in test - Should change to December 2030, instead got December 2020 - timed out after 50 tries.

Comment 24

[Cristian Tuns]

And also this: https://treeherder.mozilla.org/logviewer?job_id=398403254&repo=autoland is perma( on both landings)

Comment 25

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.5 - Fix failing CSS transform-input WPT test. r=emilio

The test reported TEST-UNEXPECTED-PASS for /css/css-transforms/transform-input-013.html which used to expect that the css-transform for <input type=datetime-local> would intermittently fail on macOS which does not happen anymore, thus the patch is changing the expectation to always PASS.

Depends on D141175

Depends on D142743

Comment 26

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.6 - Fix failing junit PromptDelegateTest#dateTestParameters. r?Jamie,eeejay,mconley,kcochrane

Depends on D163739

Comment 27

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1676068 - Datepicker Pt.7 - Removing timeouting spinner keyboard navigation tests. r=Jamie

The tests for Page Up, Page Down, Home, End are temporarily removed from the toolkit/content/tests/browser/browser_spinner_keynav.js until the bug 1803612 is resolved as a follow up. Providing these tests are tracked by the bug 1803664.

Depends on D163802

Depends on D163802

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a06081c85646
Datepicker Pt.1 - Change DateTimePicker markup to HTML Table with ARIA Grid. r=Jamie,desktop-theme-reviewers,fluent-reviewers,flod,dao,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/04050cfd5e3f
Datepicker Pt.2 - Add ARIA Spinbutton properties and updates CSS for consistency. r=Jamie,morgan,fluent-reviewers,mconley,kcochrane,flod
https://hg.mozilla.org/integration/autoland/rev/234acd14548e
Datepicker Pt.3 - Replace Reset button in the DateTimeBox with Calendar one. r=Jamie,fluent-reviewers,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/50bb7e9c6bcf
Datepicker Pt.4 - Update keyboard support for a DateTimePicker. r=Jamie,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/d06b6aa3b9a3
Datepicker Pt.5 - Fix failing CSS transform-input WPT test. r=emilio
https://hg.mozilla.org/integration/autoland/rev/639c9661c850
Datepicker Pt.6 - Fix failing junit PromptDelegateTest#dateTestParameters. r=Jamie,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/d3c9e777a050
Datepicker Pt.7 - Removing timeouting spinner keyboard navigation tests. r=Jamie

Comment 29

[Marian-Vasile Laza]

Backed out 7 changesets (Bug 1676068) for causing geckoview junit failures.
Backout link
Push with failures <--> gv-junit-e10s-single
Failure Log

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c0dae8a2aaf
Datepicker Pt.1 - Change DateTimePicker markup to HTML Table with ARIA Grid. r=Jamie,desktop-theme-reviewers,fluent-reviewers,flod,dao,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/aa0e481c2cb0
Datepicker Pt.2 - Add ARIA Spinbutton properties and updates CSS for consistency. r=Jamie,morgan,fluent-reviewers,mconley,kcochrane,flod
https://hg.mozilla.org/integration/autoland/rev/509e440fb9a8
Datepicker Pt.3 - Replace Reset button in the DateTimeBox with Calendar one. r=Jamie,fluent-reviewers,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/b383bfc67eba
Datepicker Pt.4 - Update keyboard support for a DateTimePicker. r=Jamie,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/b60564678814
Datepicker Pt.5 - Fix failing CSS transform-input WPT test. r=emilio
https://hg.mozilla.org/integration/autoland/rev/8251fc0ce483
Datepicker Pt.6 - Fix failing junit PromptDelegateTest#dateTestParameters. r=Jamie,mconley,kcochrane
https://hg.mozilla.org/integration/autoland/rev/fe7d9416e641
Datepicker Pt.7 - Removing timeouting spinner keyboard navigation tests. r=Jamie

Comment 31

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2c0dae8a2aaf
https://hg.mozilla.org/mozilla-central/rev/aa0e481c2cb0
https://hg.mozilla.org/mozilla-central/rev/509e440fb9a8
https://hg.mozilla.org/mozilla-central/rev/b383bfc67eba
https://hg.mozilla.org/mozilla-central/rev/b60564678814
https://hg.mozilla.org/mozilla-central/rev/8251fc0ce483
https://hg.mozilla.org/mozilla-central/rev/fe7d9416e641

Comment 32

[Anna Yeddi [:ayeddi]]

The QA bug tracking is available at: https://bugzilla.mozilla.org/show_bug.cgi?id=1804459

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9e2df9db3b60
Port bug 1676068 - Change DateTimePicker markup to HTML Table with ARIA Grid. rs=bustage-fix

Comment 34

[Ryan VanderMeulen [:RyanVM]]

Given the number of regressions this caused, I'm wondering if we should backout before 109 goes to Beta on Monday?

Comment 35

[Emilio Cobos Álvarez (:emilio)]

Can we consider backing out directly from beta? Otherwise blame is going to be a mess, and we need to back-out and re-land all the already-landed regression fixes.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

That could be arranged, yeah. It would be helpful if I had a complete list of changesets to backout or (better yet) a landable backout patch, though.

Comment 37

[Emilio Cobos Álvarez (:emilio)]

Attachment: Backout for beta.

If we want to do that here's a patch.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9307804 [details] [diff] [review]
Backout for beta.

Approved for 109.0b1, thanks!

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9307804 [details] [diff] [review]
Backout for beta.

Per Slack discussion, we're going to hold off on this for now so we can get more feedback from the Beta audience. We'll revisit things next week.

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx109 relnotes.