Tabs variant behaviour

[gestchild]

Background

We have a Tabs component (#10432) that has 2 variants; 'tab' and 'anchor'. They look identical and share styled components.

The 'tab' variant renders true tabs, i.e. html and javascript that follows the Tabs pattern outlined in the ARIA Authoring Practices Guide (APG)

e.g. the month selector on the What's on page

The 'anchor' variant simply renders links on the page.

e.g. the search selector on the works page

Problem

When using a keyboard to navigate, the interaction required to use the two variants is completely different, which is confusing:

• The 'tab' variant requires the use of arrow keys to move between the tabs.
• The 'tab' variant exposes the relevant content by simply moving to the tab control.
• The 'anchor' variant requires the use of the tab key to move between the tabs.
• The 'anchor' variant requires the user to click the tab in order to get to the content.

N.B. the behaviour of the tabs is also different:

• The 'tab' variant exposes different content on the same page.
• The 'anchor' variant takes users to a new page.

Solution

It was suggested using Tabs with Manual Activation instead of Tabs with Automatic Activation could align the interaction of the two variants.

While this does align part of the interaction, i.e. the need to click the tab to get to the content, the user still needs to use the arrow keys (not the tab key) in order to reach the tabs.

I think the only way to align the interaction completely is to not use the Tabs pattern with tablist and tab roles for the the 'tabs' variant. They'd have to be anchors to in page ids, with the aria-controls attribute. That way they could be reached by tabbing and activated by clicking in the same way as the 'anchor' variant. We'd just override the default behaviour with javascript so they behave like tabs.

It's not ideal, but I think aligning the interaction is probably more important. They would still be discoverable and usable with assistive technology.

Otherwise we'd need to look at changing the 'anchor' variant so it doesn't appear to be the same thing.

Also, does it matter that the behaviour (in page changes versus links to new pages) is different between the two?

Discuss!

[j-jaworski]

Yeah, this sounds right and a very clear explanation. I agree with the solution you have proposed.

From a UX perspective, I don't think it is an issue that the behaviour (in page changes versus links to new pages) is different, users are hopefully unlikely to notice or care that they are on a different page and the slug has changed.

[rcantin-w]

Sounds like there's a decision in place then? The last thing was what was worrying me a bit more. So we're going with removing the tablist/tab roles across and having them all using the Tabs with Manual Activation method. Should it be a list at all?

[gestchild]

Not using the tabs pattern at all. Just having the aria-controls property on the tab links and the relevant id and aria-hidden properties on the tab content.

Without js they behave like normal in page links (as they do currently), with js they prevent the default and toggle the aria-hidden property

[gestchild]

One of the downsides of not following the tab pattern is that a user would have to tab through each tab before getting to the tab content

[rcantin-w]

I just found out about focusgroup (not out yet), which would eventually be useful for this case? Thought I'd share it here even though it looks like nowhere ready to be shipped.