Try a darker selected block outline with animation

[kjellr]

Alternate approach to #12478.

As suggested by @LukePettway + @mapk, this adds a delayed fade animation to block borders. On initial focus, they appear with a 3:1 contrast ratio ($dark-opacity-200), and then fade out to the current, lighter border color ($dark-opacity-light-500) after a short delay. I set the delay to 1 second for now.

^ The fade animation has been slowed down a little here so the GIF's framerate can pick it up

Note: This PR does not currently apply this adjustment to our dark background border variants. If this direction moves forward, that'd need to be added in before merge.

[mapk]

I tested and found a some oddities.

1. The toolbar appeared with a block outline.
2. The blue focus outline wouldn't change to the grey one when selected.

[kjellr]

@mapk

1. The toolbar appeared with a block outline.

Can you elaborate on this? I'm not sure what you mean.

2. The blue focus outline wouldn't change to the grey one when selected.

That's weird! I do see that on the page title: the styles there specify that the blue should appear on hover, even when it's focused. But blocks shouldn't be doing that. 🤔

Here's a quick recording of what I see on my end while hovering + clicking on blocks: https://cloudup.com/cjlPBl1mk5a

[mapk]

1. The toolbar appeared with a block outline.

Can you elaborate on this? I'm not sure what you mean.

Yes, it happens when I stop typing text, and then I move the mouse a bit. It results in this for a brief moment:

As for number 2, I've pulled the latest changes and still see the blue line instead of the black one appearing.

[kjellr]

I was able to reproduce both those things in Firefox, but not in Safari or Chrome. 🤔 Super weird. I'll keep digging.

I'll also note that as I'm clicking through posts with a lot of blocks, I'm finding the repetitive Blue ➡ Dark Gray ➡ Light Gray shift to be a little overbearing. So I'm still not totally sold on this solution.

---

Also, since I'm here, I'd like to toss out a related (but probably not viable) idea to maybe help simplify these colors a bit:

It's always seemed weird to me that our hover state for blocks is actually more prominent than our focused state. I'd expect the border darkness to build up a bit:

1. Show a light border on hover.
2. Darken that border on focus.

To that end, I wonder if it'd make sense to tone the hover state down to the light gray alongside this darker focus border:

While this makes sense from a color progression standpoint, I figure that both our hover and focus styles need colors that pass WCAG, so it's not actually a great solution in practice. Also, it may not solve the problem of these color changes seeming too overbearing.

I'm interested in some discussion around it though.

[kjellr]

It's always seemed weird to me that our hover state for blocks is actually more prominent than our focused state.

Another idea for this would be to keeping the hover state dark blue, but give it a less prominent treatment. For example:

1. Show a blue border on hover, but only on one side of the block.
2. Darken that border on focus, expand it to all sides.

That way, we could keep the prominent, accessible blue color, but just move it around a little. This seems like a bit of a more natural progression to me. In addition, by removing the horizontal lines on hover, we help lighten up the writing experience considerably.

I know showing hover/select with only a left border has been explored in the past, but perhaps not in this specific way?

[mapk]

Another idea for this would be to keeping the hover state dark blue, but give it a less prominent treatment.

I do like this treatment! But I also remember a similar approach being explored and not sure why it wasn't followed through. Are there any a11y issues with this, @LukePettway ?

@kjellr What do you think if the blue hovered border were to be thinned down to match the weight of the focused border?

[Luciaisacomputer]

It's an interesting visual treatment but I can see two downsides with this approach:

1. It makes it harder to tell where the interactive area is around the input
2. On wider screens it might be possible to miss this hover state altogether

[kjellr]

1. It makes it harder to tell where the interactive area is around the input

Can you rephrase this? I think you're referring to the fact that the existing hover state highlights the entire clickable area (effectively telling you "This is what you can click on!"), whereas this approach does not — but just want to make sure I understand.

EDIT: Never mind, I see you mentioned this in slack too. Sounds like I'm understanding that correctly. 👍

2. On wider screens it might be possible to miss this hover state altogether

Definitely true. In most cases, the content width is capped at a certain point, but in general, it is less noticeable than the current state.

@kjellr What do you think if the blue hovered border were to be thinned down to match the weight of the focused border?

I did try that originally. It works just fine, but to Luke's second point above, I think having the border be a little thicker helps make it more noticeable.

[kjellr]

Another idea for this would be to keeping the hover state dark blue, but give it a less prominent treatment. For example:

1. Show a blue border on hover, but only on one side of the block.
2. Darken that border on focus, expand it to all sides.

Just noting that I've pulled this idea out into its own issue to consider it in a broader context: #14095

[afercia]

The focus fade effect doesn't solve the original issue as outlined in #12254. Please consider many users have vision impairment of simply have something called "ageing" 🙂

For these users, a clear indication of focus is essential to understand what the active UI element is.

Would be great to find a good balance. Color contrast is a simple requirement. Non-text contrast needs to be 3:1. At this point of the project, after two years of development, there shouldn't be any contrast issue in the interface. May I suggest to try to invert the borders: personally I wouldn't have objections to use the lighter gray border for hover.

Instead, focus could use the blue (matching the core pattern for focused interactive element). More importantly, focus needs to always be 3:1.

As noted in other comments in other issues/PRs, if users prefer a lighter UI there's "Spotlight Mode" explicitly designed for that. Instead, the default should offer a sufficient contrast.

[Luciaisacomputer]

@afercia From what I understand, the thing that is preventing a border from being applied that satisfies the color contrast requirements is that in doing so it causes other accessibility issues because for some people it can be distracting and make it hard for them to focus because it breaks the flow of content.

In a situation where there could be two competing sets of needs which one wins? Is the visual accessibility requirement greater in terms of need and therefore the right way to go about solving this?

If spotlight mode solves this for the users who do find it distracting then that sounds like we don't need to keep going down this rabbit hole.

[talldan]

Hey. I gave this a test and noticed a couple of things:

1. The dark outline happens both on initial selection and also after moving the mouse once I'd finished typing. The animation after finishing typing feels unnecessary, but I understand it might be hard to solve that:
   

2. Blocks receive a lot of treatement on hover/selection, but the default appender doesn't. As a user it feels like its synonymous with a block, so it seems inconsistent that there's no outline on hover or selection animation:
   

[afercia]

@LukePettway thanks, that's a good point to clarify. Focus indication is a native browsers feature. It exists for a reason. It applies also to custom interactive user interface component. It's an universal requirement that benefits all users. WCAG are pretty clear in this regards and there are no exceptions:

Success Criterion 2.4.7 Focus Visible
https://www.w3.org/TR/WCAG21/#focus-visible

Each block is comparable to a (rich) textarea: when operating in a native textarea, the textarea has focus indication. In the same way, each block needs focus indication.

We've gone through this conversation about focus indication since the very first days of this project, two years ago. Still, I see design feedback aiming to lighten or remove focus indication. So we're starting from scratch the same conversation again and again 🙂 As you said, it would be more productive to not go down this rabbit role every time some new design idea comes up.

We should probably also clarify what "design" means in the WordPress context. WordPress aims to be accessible. In a project that aims to be accessible, inclusive design needs to solve problems for all users and make the interface usable by everyone first 🙂 Instead, lightening up or removing focus indication goes in the opposite direction. It actually excludes users by making the interface harder to use.

I wouldn't put the issue in terms of which competing need "wins". However, focus indication prevails. Users who prefer a lighter interface can switch to Spotlight Mode. The default needs to be usable by everyone.

other accessibility issues because for some people it can be distracting

I think that's more related to the hover effect, so we're probably mixing two different things. Moving the mouse hover multiple blocks makes the hover border appear and disappear multiple times... yes that could be a bit distracting but it doesn't prevent users from using the interface. Instead, I don't see how selecting a block and having the focus border appear can be distracting.

Also, I'd suggest to test with some real content and not with a one-line paragraph 🙂With real content, the need to have some hover effect is more evident: sometimes it's hard to understand where to click to select a piece of content.

[kjellr]

Closing in favor of #14145