Make selected block outline darker (Issue #12254)

[timwright12]

Description

Fixes #12254

How has this been tested?

In browser
Color contrast testing
Local Unit tests
Local e2e tests

Screenshots

Types of changes

Darkened the block focus state to $dark-opacity-200 as mentioned in the issue as well as updating the dark-theme state color to $light-opacity-300. Not knowing what the "dark" theme looks like, I picked $light-opacity-300 because it allows for a passable contrast ratio up to and including a background color of #333333, which starts to get on the lighter-side of what I would consider a "dark" theme

Checklist:

• [ x ] My code is tested.
• [ x ] My code follows the WordPress code style.
• [ x ] My code follows the accessibility standards.
• [ x ] My code has proper inline documentation.

[gziolo]

Code wise looks good, @jasmussen and @kjellr - do you confirm the changes proposed?

[kjellr]

Thanks, @timwright12. This works fine in top toolbar mode, but it causes a mismatched border color elsewhere:

---

Once that's fixed, here's how this change would play out:

Current on the top, updated colors on the bottom

In general, I understand the motivation and guidelines around this change, but the dark border feels a bit distracting to me. It exacerbates the blockiness of the UI and seems heavy handed from an aesthetic standpoint. Since it's such a striking change, I'd love to get some more feedback from others on the design + accessibility teams. If we can better understand the reasoning behind a change like this, perhaps we can land on a different way to solve the problem.

In case it's also helpful to see: I've personally explored darker outlines before, as part of #8836. Here are representations of these outlines using all of our available standard grays:

https://cloudup.com/cfF30uBuuJ3

[mapk]

@LukePettway brought up an interesting solution in the #accessibility channel on slack. I prototyped it out below to give us an idea. Is this what you were thinking @LukePettway? If there remain any a11y concerns with this solution, please share.

Some of the timing is off in this prototype and can be refined, but hopefully it communicates the idea.

[Luciaisacomputer]

@mapk I think this might be a good in between solution that satisfies the accessibility requirements of a 3:1 contrast focus ring, while still providing a less distracting outline for users once they start interacting with the content.

[mapk]

I'd like to get some more feedback on the border fade design before continuing.

@kjellr I know you've spent some time here before... any thoughts?

I'm also introducing something new to this PR, so @timwright12, I'd love to hear your feedback as well.

[kjellr]

I'd like to get some more feedback on the border fade design before continuing.

@kjellr I know you've spent some time here before... any thoughts?

Yep! I just opened #13700 to try this out. If this seems reasonable from an accessibility perspective, I think it's a nice compromise between ensuring that the selection is clear and preserving a light visual weight to the block.

[Luciaisacomputer]

@kjellr One thing I'm thinking about with this is whether it is possible to have the focus fade on interaction vs a delay. My main concern would be for people with slow visual processing or attention disorders that the focus might fade fast enough for them to lose their place. That's obviously an edge case though but still something worth considering. The downside to such an approach is that it would be very specific to the type of functionality a block provides.

This is how the address bar in some browsers works. When you tab or click into it, the input is outlined with the blue focus ring. Once you begin typing the styling changes and displays a dropdown of URLs.

All these considerations aside, I think that this is a step in the right direction for providing a better focus indicator to the users who rely on that, while providing a less distracting editing experience for the users who also need that.

This problem is interesting in that it almost feels like a clash between two different sets of accessibility needs.

[kjellr]

One thing I'm thinking about with this is whether it is possible to have the focus fade on interaction vs a delay.

Yeah, this crossed my mind while I was trying to land on a delay time — the exact amount of seconds I chose seemed a little arbitrary. Tying it to an action would make sense.

I had some trouble figuring out what that action would be though. When you begin typing, the border already disappears, so presumably this would be tied to some other sort of action. Mouse movement could get tricky too, since we wouldn't want to compete with hover states.

This problem is interesting in that it almost feels like a clash between two different sets of accessibility needs.

Yes! That's exactly the feeling I'm getting here. 🙂

[timwright12]

Closed because this was fixed in #14145