[EuiTabs] Often misused in Kibana as navigation

[myasonik]

EuiTabs is often misused in Kibana in two different but related ways.

Version 1:

<EuiTabs>
  <EuiTab><a>Foo</a></EuiTab>
</EuiTabs>

Version 2:

<EuiTabs>
  <a>Foo</a>
</EuiTabs>

Either way, the problem is that people want routable tabs. The way that people accomplish it differs but either way it causes accessibility issues (the first by having an anchor nested within a button, the second by not having any tabs inside of a tab list).

Does EUI need to provide a routable tabs pattern? (Semantically, this wouldn't even be a tablist but rather just a list of links but would visually look like tabs.)

Related Kibana issues I could find open right now: elastic/kibana#77828, elastic/kibana#80599

[cchaos]

Yes this was actually added from a specific ask: #1844

I think we will need to find a way to allow changing the role of the whole tabs list (try to do it automatically if they're passing the tabs as an object). But I don't think we can just stop supporting the href usage.

[myasonik]

Ah, ok! I didn't even realize than an href could be passed into EuiTab because I have seen folks in Kibana pass in an anchor as a child.

So EUI can fix something internally for when someone passes in an href and we can try to better educate folks in Kibana to use the official href support.

Thoughts on locking tabs down to instead of allowing any children, using a label prop (and some icon props)?

[cchaos]

Moreover I think we should update the component to this specification: https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html

[myasonik]

++

Nothing to really say about it but just noting that this kind of ties in with a couple of issue that have been brought up about relying on tab vs using arrow keys for navigation within a widget.

[cchaos]

What issues specifically?

[myasonik]

That pattern uses arrow keys to navigate between tabs but pressing the TAB key is often the assumed way to navigate between interactive items on the web. By moving this tab pattern to the reference implementation you posted above, we are further moving to using arrow keys for navigating within complex components and away from relying on TAB for everything (which can be confusing to some users) regardless of what is codified in the spec or what is recommended in the WAI-ARIA Authoring Practices.

Because of the nature of our app (namely, that it is so tab stop heavy and that a lot of our users are regular and repeat users) I think implementing these arrow key controlled patterns are generally a big boon to navigation but it's an arguable position.

The recently came up with DataGrid and ContextMenu.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[myasonik]

With EuiPage taking over the common tab rendering for pages, abuse of Tabs should drop.

@cchaos cool with closing this issue?

[cchaos]

I'm not really sure hoe EuiPageTemplate will fix the original issue 😆 , but I'm also ok closing this.

[myasonik]

In what I've seen from Kibana, people abuse Tabs most in the header. If people are using EuiPageTemplate to render their tabs, they should be passing in just a config object, not a bunch of arbitrary children. So I'm hopeful this will help the issue just be less prevalent, not that it actually solves the root cause (but solving the root cause is much harder).