Accept more than one container in which to look for tabbable nodes

[ZhihaoJia]

It'd be nice to be able to pass more than one element to tabbable. The current tabbable doesn't allow us to easily find the relative tab orders of elements in multiple containers, if we were to call tabbable on each container.

Would it be reasonable to add this feature to tabbable? Happy to send a pull request if that's okay.

Example:

Suppose the numbers following "el" represent the tab orders of focusable the elements...

container1: el1, el4, el3
container2: el2, el5, el6

Calling tabbable on container1 and container2 would give us...

container1: el1, el3, el4
container2: el2, el5, el6

However, we wouldn't know how to combine the two lists of els, or know that el2 from container2 should be tabbed to before el3 from container1.

Proposal

Allow tabbable to accept multiple elements: tabbable(el1, el2, ...). tabbable returns an array of tabbable nodes in tab order from all of the passed elements/nodes.

Use cases

• Composite modals (ie. modals with multiple "dialogs").
• Non-fullscreen modals/overlays (e.g. overlay does not cover a top nav bar).

[davidtheclark]

@ZhihaoJia Interesting ...

Can this be achieved by looking for tabbable nodes in a container that wraps both container1 and container2?

Those sound like some wacky examples, and the idea of bouncing focus across various modals sounds confusing to me. Maybe I'm not envisioning the right UI.

Keep in mind that tabbable is supposed to list the nodes that you would actually focus as you tab through the container. If you tab through your container and come across a node order different from what tabbable returns, there's a bug. But if you want to use tabbable to get some kind of alternate order, different from what tabbing actually does, that's out of scope. Does this apply to your use-cases?

[ZhihaoJia]

@davidtheclark Yep, it could totally be achieved using the method you mentioned! That is, looking for tabbable nodes in the closest common ancestor (with tabbable) and filter for the ones inside either container1 or container2. This would cover my use cases, which I think would admittedly be pretty niche.

I didn't explain the use cases I was envisioning well though, so let me give that another try. The composite modal case I mentioned doesn't have as much to do with multiple modals as overlaying UI components originating from modals. This is getting into the weeds, but suppose we have a dropdown close to the bottom of a modal. The modal content is scrollable (vs say having a long modal that scrolls with the page). On opening the dropdown menu, suppose we want it to extend below the modal dialog. If the menu were a child of the modal, it might cause the scrollable content to increase (e.g. causes a scrollbar to appear). With overflow: hidden on the modal, we would not see the full menu. With overflow: visible, we wouldn't be able to make the modal contents scrollable. So instead we move the menu outside of the modal in the DOM. However, calling tabbable on the modal would no longer include the tabbable nodes in the menu.

For the second use case, suppose we have a modal, except instead of the standard floating rectangle we have a panel that slides in from the side. Suppose we also have a nav bar along the top of the page and we don't want to cover the nav bar with the panel. In that case, we may want to get the tabbable nodes in both the nav bar and modal panel, while excluding tabbable nodes on the rest of the page.

Anyway, I think tabbable would still work for both cases so it's not a big deal. It's really just for convenience. :)

[davidtheclark]

Thanks for clarifying @ZhihaoJia! Makes sense.