Improve the visual design of the tab component

[jameskoster]

The focus ring feels a bit heavy-handed. Is there another way to denote focus, perhaps a thicker accent line, or change of text color?

It may also be nice to animate the accent line as you move between tabs.

[jameskoster]

Here's an option to kick-off discussion:

• When focussed the accent line doubles in height, and the label is blue.
• The accent line animates horizontally as you navigate between tabs.

I'm not sure about the animation effect, there are probably lots of options to explore there.

cc @WordPress/gutenberg-design

[javierarce]

That bouncing effect has too much of a personality for me, so I wouldn't use it unless it were justified by other decisions: for example, if that were the animation style for the rest of the UI or if this was needed to direct the attention to the tab change.

[paaljoachim]

Hey James.

The animation has a kind of bouncy feel to it. (Please no bounce). I will also suggest any visual design change that accessibility also adds feedback. Alex I am thinking you might have some thoughts on this. @alexstine

[alexstine]

@paaljoachim Thanks for the ping. With my lack of vision now, I'll refer to @joedolson for some guidance here. Thanks! 👍

[jameskoster]

Agreed on the bouncing, we should instead copy the same animation effect applied to segmented controls:

Thanks for the accessibility pings. I suspect the new effect may be too subtle. But this was just a starting point from which to refine. If we must persist with the full outline, so be it :)

[joedolson]

Regarding the animation, as long as it respects prefers-reduced-motion flags, I'm not too concerned either way.

For the focus effect, I suggest we follow the guidance in WCAG 2.2. They aren't published yet, and could change, but it does help that they give specific guidance on what degree of visual change will meet legal requirements, and that's a good reference to work with.

The guidance for Focus Appearance (minimum) will accept either a focus indicator with a contrast of at least 3:1 against the unfocused states and is either an outline of the entire perimeter of the object with a minimum thickness of 1px or the area of a 4 CSS pixel thick line along the shortest side of the bounding box.

So a border that has a width of 4px along the long side would meet requirements, but if the active state also has a border, then an active control that receives focus would only have a change equal to the difference between the two borders, and that would need to be taken into consideration.

In the current design, the active state has a four pixel bottom border, then the focus state adds a two pixel border on the other three sides. If the active state retains a four pixel bottom border, then it would need to increase at least by 2px on focus. (2px length of bottom border >= 4px length of side border); but this change would only work as long as controls are at least twice as wide as they are tall.

[jameskoster]

Thanks @joedolson.

So to clarify... if:

• The active state has a 1.5px bottom border which acts as the 'focus indicator', and
• The focus state has no outline

Then the indicator on the focus state should increase from 1.5px to 5.5px. Is that the correct interpretation?

For reference here's how that looks:

[joedolson]

Close. The requirement is based on the area of the surface that's changing to indicate focus. It has to be an area equivalent to 4px width times the length of the shortest bound. Increasing by 4px on the long side will definitely meet that, but it doesn't actually have to be that wide.

However, because those comparisons are relative - and that relationship of width to height may be difficult to control, that significant of an increase might be safe. Using the bottom bound will always work as long as the controls are never narrower than they are tall (which seems most likely to be a safe bet.)

This guideline could change, but it's unlikely to get stricter, I think - the main concern is with covering edge cases where the described concern isn't readily capture.

[jameskoster]

OK, so the shortest bound (height) is 48px, multiplied by 4 = a minimum area of 192px.

The smallest tab I'm aware of is the "Block" tab in the Inspector, which is 65px. I think we could safely set that as a min-width for all tabs to ensure they always pass the minimum requirement.

If we then utilise a height of +3 for the focus indicator, that would result in an area of 3 * 65 = 195.

As pointed out, this has to be additional to the existing 1.5px on the active state. So the end result would be:

• 1.5px border on active
• 4.5px on focus

Here's how that looks:

Other options

If we wanted to reduce the focus border with to 3.5 then we'd need to set a min-width on all tabs of 97.5px.

If we wanted to reduce the focus border with to 4 then we'd need to set a min-width on all tabs of 78px.

[joedolson]

I'm in favor of the thicker line, and not adding additional width to tabs when it's not known to be necessary.