TabBar: dotted border around clicked tab

[martinkrulltott]

Since ui@6.1.7, when clicking a ´Tab´ in a ´TabBar´, a dotted border is shown around the label. As seen in the screenshot and example sandbox below:

https://codesandbox.io/s/ui-tabs-q3nye?file=/src/App.js

[amcgee]

@martinkrulltott this is actually by design - see this issue and this pr, and you can see this in the release notes of the v6.1.7 release

This is an a11y (accessibility) feature of browsers which allows visual feedback when tabbing through focusable components.

[martinkrulltott]

I understand the accessibility part of the feature for tabbing, I just didn't expect it on click, as I haven't seen that feature anywhere else in neither Data Visualizer nor ui. But as this is per design then this question is ✅

[amcgee]

It does seem like there could be a valid reason to unfocus the tab after it has been clicked (since that didn't depend on pre-existing focus). There appears to be some debate about how or if to do this, but blurring on mouseup seems like a nice compromise to me (one of many solutions from StackOverflow)

Here's an example using a hack to add the event to the buttons.

@cooper-joe @mediremi @paschalidi any thoughts on changing this behavior from a UI or accessibility standpoint?

[amcgee]

We could of course also do this on mousedown to avoid the flash of outline... but that might be worse? Using mouseup if you depress your mouse on the button, then move it somewhere else before releasing, the half-clicked button remains focused

[amcgee]

@cooper-joe another thought here - we actually already have a "hover" style for tabs which I think might be appropriate as the "focus" style as well - when you tab through it could behave similarly to when hovering over the tabs. This could allow us to have a "subtle" active+focused style (blue bottom border and gray background color) when you click a tab, allowing us to keep it focused and for the user to continue tabbing from there.

[mediremi]

I like the idea of having a focus style similar to the hover style. We might want to think about disabling transitions for the focus styles though as I find they can make keyboard navigation feel sluggish.

[paschalidi]

Here is what is suggested from an a11y point of view.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tab_Role
Long story short there is some sort of outline when you click the tab. Also optionally you can navigate using the <- and -> arrow to the previous and next tab. They say that ideally when you press tab your focus moves inside the panel of the tab.

---

Another example can be seen in Chakra who they call themselves an "accessible component library"
https://chakra-ui.com/docs/disclosure/tabs#usage

[cooper-joe]

I agree that using a similar style for hover and focus is a useful way of making this seamless. I think this would be a good starting point for the aesthetic part of this discussion.

[amcgee]

If you try interacting with GitHub interface (see the Write and Preview tabs when writing a comment) is pretty enlightening - they don't have separate tabstops for each tab but rather a single one for the tab bar and support arrow keys to navigate between tabs. Also, when you click on one of the tabs it moves focus to whatever the first focusable element is within that tab which I think makes sense.

Navigating through the "tab-like" sidebar options on the lefthand side of the Codesandbox linked above - if you click on one of the tabs, it is selected. The Active and Focused styles are identical, so this is pretty seamless. If you tab after clicking on one of the tab buttons, the focus starts from whichever tab you clicked which I think is quite nice (and is broken by the blur solution mentioned above)

[amcgee]

Notably - neither of these examples reset focus to the top of the page after clicking a tab/button

[cooper-joe]

Reading into this a bit more, I think the tabbing from the active tab in tab list to the tab panel (or, content) is the recommended design pattern. Arrow keys are used to navigate between tabs in the tab list.
I think this would be the interaction pattern to support if we want to change the current behaviour.

[varl]

We need to pull this out into a JIRA issue and link it to an Epic for adding WAI-ARIA to components as we should not do the work in relation to this question as a quick fix.

[varl]

I've created an issue for the TabBar a11y here: https://jira.dhis2.org/browse/LIBS-124

It is part of an Epic that covers accessibility for all existing components. Future components should consider a11y from the start.

[janhenrikoverland]

@cooper-joe @varl @amcgee Does anyone have any experience with e.g. using :focus-visible ? It could make sense to show such focus indicators only for keyboard interaction. That seems to be the intention as well: the W3C proposal mentions that :focus-visible should be preferred over :focus except on elements that expect a keyboard input (e.g. text field, contenteditable).

Btw, at the moment we have four different focus indicators... dotted, blue, green and yellow border.

---

---

---