Can't tab out of field when calendar is open and breaks accessibility

[jwallet]

Describe the bug 2.9.6 was not crashing using Select Year/Month dropdown 2.15.0 fixed it but it is not possible to tab out of the field and get the value selected when moving to the next field 2.9.6 does work.

To Reproduce Steps to reproduce the behavior:

1. Focus on the field
2. use keyboards arrows to move to a date without selecting it
3. hit tab or shift+tab to move to another field
4. it does not move to the other field, it focus inside the calendar and it also breaks the accessibilty hotkeys

• Firefox
• Chrome

[ajcrews]

Looks related to https://github.com/Hacker0x01/react-datepicker/issues/2140. Even a user that has a mouse can't access the other date field without double-clicking. This is a breaking change and we are locking down the version of this package in our repos until it is fixed.

[akash87]

Any workarounds for this ?

[bgl-tand]

This can solve half of the issue to set the value on tab. Otherwise just use the older version. onKeyDown = (e: any) => { if (e.key == 'Tab') { setTimeout(() => this.ref!.setOpen(false), 100 ) } }

Only work around for moving to the next field i've found so far is to specify where you want to focus next, but quite tedious to have to specify this everywhere.

I ended up going with version 2.9.0. This solves any tabbing issues in my case and requires no workaround code - keeping things simple.

[mtran-method]

Hi, I'm still experiencing this issue when a timepicker is present with version 3.4.1

Unable to tab out and breaking accessbility.

[reinvanimschoot]

I have the same issue, any updates on this?

[Bryn-Heath]

Still got this issue - Win7 + IE 11

[GalGrigoryeva]

Will this issue be fixed?

[jp-albrecht]

I'm experiencing this issue as well. Any update?

[avi-dwave]

This is an issue for me as well

[kiprobinson]

This can solve half of the issue to set the value on tab. Otherwise just use the older version. onKeyDown = (e: any) => { if (e.key == 'Tab') { setTimeout(() => this.ref!.setOpen(false), 100 ) } }

Only work around for moving to the next field i've found so far is to specify where you want to focus next, but quite tedious to have to specify this everywhere.

I ended up going with version 2.9.0. This solves any tabbing issues in my case and requires no workaround code - keeping things simple.

2.10.1 worked for me, and it is definitely broken by 2.16.0. I'm not going to go version by version to try to figure out which one broke it. Still broken in latest (4.1.1 as I write this).

Also if you tab into the field, type in a date manually, then tab out, the tab gets stuck looping through prev month, next month, and date. It won't tab to the next field ever.

[tammypmc]

Hello! I need to know if this issue still present on the current version?

[kiprobinson]

@tammypmc

Hello! I need to know if this issue still present on the current version?

I'm no longer working on any react project. But I can reproduce on the demo page: https://reactdatepicker.com/

1. Click near the input field on the first example (not the one at the top, it does other weird stuff. The first one under "Examples".)
2. Tab => Focus goes into the input field
3. Start hitting tab again => It loops between input field, prev month, next month, selected date. User is unable to get out of the field except by using the mouse, a big accessibility issue.

I'm on Chrome on Windows. I've attached a video - all I'm doing in the video is hitting tab over and over

https://user-images.githubusercontent.com/2453426/135771190-288484e2-ed02-4396-8072-8567545da3d0.mp4

[tperamaki]

Steps to produce: Click tab until you are stuck in a loop Requirements for it to happen: There needs to be the arrows for changing months visible

So if you use includeDates option to limit the dates to only one month, there won't be any arrows visible, and the user can properly tab out of the datepicker (although it's left open).

[tperamaki]

There is a tab loop feature in this library that is by default enabled, which breaks the accessibility and works against the documentation (which states that tab exits). See https://github.com/Hacker0x01/react-datepicker/blob/18302ebb2cb6b98ae9064e195d73bc25e96eb6a9/src/tab_loop.jsx

Thankfully the workaround is rather easy, just add the property enableTabLoop={false} and you can tab out of it again, although it will stay open, but still better.

<DatePicker enableTabLoop={false} selected={startDate} onChange={(date) => setStartDate(date)} />

[shanebeehler]

My solution is to disable the calendar opening on focus which will allow tabbing past this input. And then allowing the user to hit Enter key to open the calendar when on the input. From there, the user can select a date via Enter key or close the calendar via Esc key to the tab on.

  const handleOnKeyDown = event => {
    if (datePickerRef?.current && !datePickerRef.current.state.open) {
      if (event?.keyCode === 13 || event?.which === 13) {
        event.preventDefault();
        datePickerRef.current?.setOpen(true);
      }
    }
  };
  
  <ReactDatePicker
    ...
    preventOpenOnFocus={true}
    ref={datePickerRef}
    onKeyDown={handleOnKeyDown}
  />

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ryanmunger]

Anymore information on this one? It would be great to have at least an option to cycle to the next input after the calendar closes. Seeing the issue when a user tabs in, focuses, selects a date. Hitting tab again just selects the same input over and over again.

[ch1qui]

This is not an issue, Check out the modal pattern as explained in this WAI-ARIA article: https://www.w3.org/WAI/ARIA/apg/patterns/dialogmodal/ If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog. Since the tooltip is interactive, having a focus-trap is a good thing, its not breaking accesibility.

[ryanmunger]

@ch1qui this issue happens after you have closed the calendar and selected a date. So the flow goes:

• tab into a field
• Calendar pops
• Choose date
• Calendar closes
• Tab into next field
• Refocuses back on the same field you were just in

where I think it’s broken is the fact that it pops the SAME calendar on the SAME field previously selected when the expectation/normal flow would be to have the next field focused into when tabbing out of the current field. Therefore a keyboard user can never tab to the next field. Hope this makes more sense!

[reinrl]

This is not an issue, Check out the modal pattern as explained in this WAI-ARIA article: https://www.w3.org/WAI/ARIA/apg/patterns/dialogmodal/ If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog. Since the tooltip is interactive, having a focus-trap is a good thing, its not breaking accesibility.

Respectfully @ch1qui, I would strongly disagree - specifically with comparing the date picker calendar view to a modal window:

• Much like the options for a HTML select field, the window is pinned to the field that opened it.
• The date picker calendar view is not layered above the original window (meaning that you are preventing from interacting anywhere else on the page before addressing the open dialog - mouse users can happily click elsewhere - typically visually indicating by a colored layered overlaying the rest of the pane)

I am currently using this project - and getting dinged on an accessibility audit because focus becomes trapped within the calendar view (among other things they noted). From their critique: "The only time it is acceptable—and in fact, necessary—to create a keyboard trap is within a modal window. In this case, a keyboard user's focus should be trapped within the modal until the modal is closed. Modals act as mini-web pages within themselves; users are not supposed to be able to do anything else on the parent page until they have completed the task inside the modal. Modals are the only elements in which keyboard traps are recommended."

Reading above, it would appear that I can use enableTabLoop={false} to not get trapped in the calendar view (and instead, continue on to the next focusable element in my form) - but that still leaves the calendar view displayed when neither it nor the corresponding input field have focus. @martijnrusschen is this another A11Y issue that you would entertain a PR on? Or is further discussion still needed?

[martijnrusschen]

Yes, I agree @reinrl. We shouldn't treat this as a modal but more as a native part of the page you're on. Users should be able to tab out of it like other fields. However, looking at the examples here: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/datepicker-dialog/ it seems the recommended path is to treat a datepicker as a modal. I'm not 100% sure what's best since I'm not an accessibility expert.

[reinrl]

@martijnrusschen Thanks for the quick reply - I stand corrected (sorry @ch1qui - that guidance from the WAI really surprises me, based on what I thought that I knew about other various input elements!). I don't profess to be an A11Y expert either (only having benefited from working with a few different vendors at various jobs), so our next steps are going to be to go back to our current compliance vendor with that link in hand, and see what they have to say about that information versus their own guidance that the calendar view should not trap the user's focus. We usually hear back pretty quickly, so I will circle back here once I hear more.

[martijnrusschen]

Sounds good!