Unable to cycle focus using tab/shift+tab inside of AnchoredOverlay

[marywhite]

Describe the bug
When an AnchoredOverlay allows for keyboard navigation using FocusKeys.Tab, focus will remain trapped on the last focusable element when navigating through the overlay using Tab.

This comment in primer/behavior indicates that the focus trap should be responsible for wrapping focus with Tab (rather than specifying focusOutBehavior: 'wrap')

Because the focus trap rewrites the tabindex=-1 on focusable elements, the focus zone is not able to identify the first focusable element inside of the container when it comes time to wrap.

The below example is a bit contrived, but it seems like the focus zone and trap behaviors do not play nicely together when Tab is eligible for binding.

To Reproduce
Go to sandbox https://codesandbox.io/s/optimistic-villani-6exe7?file=/src/App.js
Click to open menu
Use tab to navigate through the overlay, observe that focus is trapped in the last button

Expected behavior
If FocusKeys.Tab is provided as a bindKey for focus zone, and a focus zone is present, I would expect focus to cycle when a user navigates using Tab.

Desktop (please complete the following information):

• OS: iOs
• Browser chrome, safari, firefox

[marywhite]

I should mention that I found for my personal case I can work around this in two ways

1. provide a custom callback to focus zone getNextFocusable
2. disable the focus zone

Disabling the zone seemed like the most logical action, but it did have the adverse effect of preventing focusability of elements in safari with default browser settings, which impacted some integration tests. If this is not a valid use case for focus zone, please let me know!

[marywhite]

Any thoughts on this issue?

[github-actions]

Hi! This issue has been marked as stale because it has been open with no activity for 180 days. You can comment on the issue or remove the stale label to keep it open. If you do nothing, this issue will be closed in 7 days.

[lesliecdubs]

Hi @marywhite, so sorry we didn't get back to you on this! Can you confirm that this is still a challenge and, if so, we'll triage this issue further?

[marywhite]

Thanks for the response @lesliecdubs 💟 ! Giving this another look (now that I'm more versed in some accessibility training 😄 ) I think we should be alright to close this. From what I understand we shouldn't be using both arrow keys and tab to navigate the controls within a composite widget. For this specific use case - and probably most use cases, Tab should be sufficient for navigating the form controls, and arrow keys should be reserved for composite controls.