Eui: [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: https://github.com/elastic/kibana/issues/77828, https://github.com/elastic/kibana/issues/80599

[cchaos]

Yes this was actually added from a specific ask: https://github.com/elastic/eui/issues/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.