Question: Why is Tab.Panel focusable by keyboard?

[callumlocke]

I noticed the tab content panel itself is given a tabindex, so if you start focused on a tab and press Tab, it initially focuses the entire panel container. You have to press Tab a second time to focus on the first item inside the panel:

Untitled.mov

Why is this? Just curious, as it seems like a pointless interim step, and possibly a confusing one. It's not clear to me what the intention of 'focusing' the panel container would be in the above example, since there is nothing you can 'do' with the panel container, as it's not a link or form control or similar. All you can 'do' is proceed to tab to the first item inside it.

For cases where the tab panel content is just one or more keyboard-navigable children (as is fairly common, as in the example above), would it make more sense to remove the tabindex from the tab panel itself so the user is immediately taken to the first focusable item within the tab panel? Or do accessibility standards require the panel container itself always to be tabbable, and if so why? Or is there just some practical benefit I'm missing?

[adamwathan]

Hey! We did it because as far as I understand it’s a requirement to make tabs accessible to people using assistive technology:

https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

If it’s actually optional though definitely open to making it configurable somehow.

[carlesandres]

@adamwathan according to this sentence in the ARIA guidelines you mention:

It is recommended that all tabpanel elements in a tab set are focusable if there are any panels in the set that contain content where the first element in the panel is not focusable.

it would seem there is room in the spec for making it optional.

The case I am facing (a tab group that contains only lists of focusable elements) is a perfect candidate for that. Ideally, I want the users of my app to focus immediately on the first element in the list and not on the panel.

[mitar]

I was also surprised with this (also because I didn't know that I have to style the outline on a panel to match other outlines in my app). So +1 on making this configurable.

[firxworx]

@adamwathan I was also surprised by this, and the inability to configure so tab panel is not focusable. It agree with others that the spec linked to above to indicates that this capability should be supported.

My use-case is similar to @carlesandres: the tab panel bodies contain focusable elements. Therefore it is most reasonable for the next tab index to be on a focusable element within the open tab panel body vs. the overall tab panel itself.

The w3 example on codepen (linked to above) shows tabs with prose in them only. In that example case, I agree, it makes sense for next tab focus is the tab panel itself.

Noting Behaviour that's Arguably A Bug

I would argue that the current behaviour of Tab.Panel of accepting the tabIndex prop (e.g. when I tried to set tabIndex={-1} attribute) is a bug when using the library in TypeScript. This prop is clearly ignored/overwritten so it should not be allowed.

To me, support for tabIndex seems like a logical and intuitive way to support disabling tab focus on a Tab.Panel itself, especially if the as prop is provided a component where setting the tabIndex would normally work.

I'd be happy to turn this into a bug report if others agree.

(by the way this is related to a dev experience issue with other HeadlessUI components as well where props are accepted but then do not work at all or as expected -- tighter types could help make the library easier to use and require less time in docs + examples).

Real Use-Case / Scenario Example

A user selects a tab that contains a grid of video thumbnails where there's a filter/search and CRUD features. After selecting the video gallery tab, the next most logical places for a "tab" keypress to set focus is the filter/search input box, then to "add" button, and then to the thumbnails themselves.

I think it is potentially confusing to users and not particularly "app like" to have focus go from the tab to the entire Tab.Panel itself and only then to the contents within it.

Incidentally this project is for an extremely physical mobility impaired user where any extra step would be a genuine hassle!! However... the interface I was working on when I encountered this is for caregivers who have more mobility :-). The big picture definitely keeps these sorts of things top-of-mind though!

[mitar]

This prop is clearly ignored/overwritten so it should not be allowed.

To me it works? And it is not overwritten?

[firxworx]

Hi @mitar are you sure we're talking about the same thing?

I saw your comment and have re-confirmed I am running the latest release v1.7.3 and re-confirmed that I can replicate the issue I described.

I have tabIndex={-1} on Tab.Panel in my TSX and in my browser dev tools I can see that it is rendered with tabIndex={0}. It looks to me like it is being overridden by headless.

Replication Steps

Add tabIndex={-1} attribute to your Tab.Panel components.

In browser, set focus on a given Tab component (the children of Tab.List). Navigate with the keyboard (← and → arrow keys) to switch between tabs and appreciate how great this works great thanks to headlessui.

Now hit Tab.

The focus will immediately shift to the Tab.Panel itself despite being set as tabIndex={-1} in the JSX/TSX.

Use devtools "inspect element" feature to confirm that tabIndex={0} in the markup the browser is working. No matter what you set your tabIndex to in your JSX/TSX it will be overridden by headless and be replaced with tabIndex={0}.

The expected result is that the focus should move from the Tab to the first focusable element within the corresponding open Tab.Panel. In my case, it is a text input element.

Issues

• headlessui is blocking behaviour that should be allowed per https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html as noted above

• there is a TypeScript issue with the current version: if the status quo is by design then Tab.Panel should not accept tabIndex as props. This is somewhat tangential to the specific issue above however I thought it is a good general feedback point to note because similar typing issues are common given the implementation and they risk undermining the overall dev experience of an otherwise awesome library :)

[mitar]

Yea, not sure why, but it works for me, see: https://gitlab.com/peerdb/search/-/blob/main/src/views/DocumentGet.vue#L160

You can see it live: https://wikipedia.peerdb.org/d/3kVWF14ywhUVFaCoTzhhFs

[firxworx]

@mitar looks like we found our difference right there: I mention JSX/TSX which is React (@headlessui/react) meanwhile it looks like you're using Vue (@headlessui/vue).

Its a helpful insight that this issue only appears to only affect the React side of things. I can confirm that your example demonstrates the desired behaviour. Thanks for sharing a link to a working example!

[mitar]

Oh, good catch. :-)

Maybe then given that it works in Vue (but it could be documented better) and that types say it accepts tabIndex, maybe this is simply a bug which has to be fixed in React for tabIndex=-1 to work properly (not be overwritten)?

[mitar]

Also in Vue it does not work perfectly to disable tabbing and there is a broken edge case: #2110