Thanks for the PR! Personally, I don't think we should land any breaking changes anymore.

I can only agree on this. I 've cross check the tests, and it is on bootstrap team decision

In any case, it misses test for keyDown event

Just getting around to checking this https://deploy-preview-33079--twbs-bootstrap.netlify.app/docs/5.0/components/navs-tabs/#javascript-behavior

This may need some additional initialisation, as currently the "make only the active tab focusable / allow cursor keys to change between them" only works after the first time a user changes the tabs

heads-up: ideally, not initialising on focus, but on page load itself. that was the part that stumped me (with our current JS approach). either that or we say authors need to explicitly initialise them when they're using them (same as with tooltips)

We have an opened issue for explicit initialization of tooltips/popover. So I 've added an auto-initialization on window load, to experiment with it, and if we proceed, we may discuss it a bit more

going to https://deploy-preview-33079--twbs-bootstrap.netlify.app/docs/5.0/components/navs-tabs/#javascript-behavior still has all tabs by default focusable (if you start off Tab-bing through the page). After initialisation, only the currently active tab should be focusable.

If you set focus to one of the tabs, and then use cursor keys, the other tabs you land on also become non-focusable by default. but the ones you don't get to still can receive focus.

only after you go to a tabbed interface and cursor through all the tabs does it end up behaving as expected (a single tab, the active one, receives focus in the tablist)

So,

• initialize only active tabs on window load
• only active tabs are focus-able
• on keyboard right/left cycle them
• many aria attrs addons (line 225 to 264)

will check in a bit, but yeah basically, this is a good exemplar of how tabs should behave https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

The intialisation now looks good, and I see you've also made the content panels themselves focusable now (which addresses #31345)

Worth checking if it also handles disabled tabs correctly (i.e. if a tab is disabled, it should not be focusable). And thinking how to handle edge cases like a tab panel where no tab is initially visible (which is not really a sensible thing, but the script should be able to handle it somehow, as otherwise there's a risk none of the tabs would then be focusable and the whole thing would become unusable).

The edge case that we have a tab active & disabled, I think is out of our scope.
For now if a tab is invisible, gets the aria attributes, so when it become visible, will have the proper functionality.
The case that may need to be fix is t the keyboard navigation, when we have disabled elements.

I lost sight of this... what's the state of play here @GeoSot ? are there outstanding parts / things that still need to be explored?

@patrickhlauke we are almost on the same spot.

The edge case that we have a tab active & disabled, I think is out of our scope.
For now if a tab is invisible, gets the aria attributes, so when it become visible, will have the proper functionality.
The case that may need to be fix is t the keyboard navigation, when we have disabled elements.

The only difference are some changes after a help session with @alpadev , where I've changed some selectors and the way the component searches for nested selectors, to cover the co-existent dropdown with an inner tab element.

PS: IMO dropdown messes a bit the mark-up,. You can see and example on our tests, where the tab trigger is two levels deeper than the other tab-triggers

PS: IMO dropdown messes a bit the mark-up,. You can see and example on our tests, where the tab trigger is two levels deeper than the other tab-triggers

tabs with dropdowns were always an abomination. we already strongly suggest that authors SHOULD NOT use them and we removed any examples to that effect https://getbootstrap.com/docs/5.0/components/navs-tabs/#javascript-behavior ... i guess it's too late to completely gut out the code that supports them (as that code simply can't be made to work with proper ARIA tab model that we're implementing here) @XhmikosR @mdo

Looks good to me, but would love @patrickhlauke's eyes one more time.

works as it should (mirrors structure/behaviour of https://www.w3.org/TR/wai-aria-practices-1.2/examples/tabs/tabs-1/tabs.html). if @mdo is happy with the (slightly wordy) additions to the documentation I made, this should be good to go.

@mdo your latest change to the docs is confusing. the accessibility information only relates to the javascript behaviour/plugin (when you're actually doing dynamic tabs, not just using the look/feel of tabs for otherwise basic navigation/links that go to different pages). so it should be a subsection of THAT, rather than coming before it

Lovely, thanks @mdo

Thank you too guys ❤️

Closing the loop, I filed some observations back to ARIA Practices w3c/aria-practices#2281