FormBuilderDate[Time|Range]Picker: Web/Accessibility: Comply with WCAG 2.1 A-level criterion "On Focus"

[beExcellentToEachOther]

Is there an existing issue for this?

• I have searched the existing issues

Package/Plugin version

9.1.1

What you'd like to happen

Date pickers should not open automatically when the field receives tab focus. On Web, the current behavior (opens automatically when field receives tab focus) presents a couple of accessibility/usability issues (see Additional Information).

Instead, the user should be able to focus the field and separately trigger the prompt by interacting with it (say, by pressing space or enter?).

It is quite possible that this is happening with other FormBuilder widgets too, but I am unable to test them myself at this time.

Additional information

When tabbing through the fields of the Flutter web app I am testing, the FormBuilderDateTimePicker and FormBuilderDateRangePicker widgets initiate a change of context when they receives focus (the picker dialog constitutes a change of context).

This fails WCAG success criterion 3.2.1 stating that "any component [which may also be called a 'user interface element'] that is able to trigger an event when it receives focus must not change the context."

The following is given as an example of failing this criterion:

When a field receives focus, a help dialog window describing the field and providing options opens. As a keyboard user tabs through the Web page, the dialog opens, moving the keyboard focus away from the control every time the user attempts to tab past the field.

I believe that this is analogous to the datetime/daterange picker's behavior, as you cannot tab past the field without triggering the popup. Compounding this problem is the fact that regardless of whether one selects a datetime/range and hits OK or cancels the dialog using the cancel button/Escape key, the focus is set back to the first element on the page--so you can't tab past it at all. It's a wall that prevents keyboard-only users from accessing all of the fields on the form.

This is an "A"-level success criterion of the WCAG 2.0/2.1 accessibility standard, meaning it's one of the most critical aspects of accessible web content.

Documentation error?

The documentation says that the FormBuilderDateTimePicker class has a "format" property, but its description seems to be related to a property, "editable", that no longer exists (or never existed and was copied/pasted from other documentation). Coincidentally, the description implies an ability to NOT open the picker automatically when the field is focused, which I believe should be implemented!

[grundid]

Please join our discussion about keyboard navigation in forms at #1297
Have a look at our demo app linked in the discussion. It showcases exactly your desired behavior.

[Adam-Langley]

+1 - we must use a fork of this widget until this issue has been fixed as it's a significant usability issue for our users.

[torbenkeller]

@Adam-Langley I recently reworked the date_field package here which adresses proper keyboard navigation now. Maybe you can get inspired by the implementation

[deandreamatias]

@beExcellentToEachOther please take a look if the prerelease version 10.0.0-dev.1 solve this
Thanks