Reports that the outlines are too distracting

[karmatosed]

An example here:

I assume they are being added for a11y reasons, but I have to admit yes they are strong. Another area you can see this:

How can we iterate here? What room is there to reduce this? @jasmussen and @afercia, interested in your input.

[afercia]

Any alternative focus style that is not based on color alone would be OK for a11y. In other words: it needs a shape (border, outline, underline, or any other distinguishable and meaningful shape).

In the case of the Document / Block tabs, the bottom border could be enough maybe.

Not sure about the panel toggles.

[folletto]

I think we should introduce the accessibleFocus approach from #846 first, then start to tackle this having the additional tool for it, so we have a more granular control on styling.

[jasmussen]

I saw this come in yesterday: https://css-tricks.com/removing-ugly-focus-ring-keeping/

Note that I'm presenting this not as an endorsement, or as anything that I know for sure can work for us or not — simply, something to explore and decide whether it could work for us.

[folletto]

Thanks for sharing it! It's good to have an external view. :)

I checked the source and the demo, and the accessibleFocus() code in that PR is already far more sophisticated than that basic approach:

1. It handles not just tab, but tab, space, and arrows – and it's easy to extend too
2. It handles disabling once activated, not just activating it

Which is why it uses the term accessible focus and not just keyboard tabbing. It's more generic, and interacts with mouse too. :)

I'd also add that it's the same code we use in Calypso: while the platform is not perfect in terms of accessibility and we have lots of work to do, that is an architectural feature that works well to address some problems, and it has been extensively tested by being in production for years.

[afercia]

I think we should introduce the accessibleFocus approach from #846 first

No, please. As I've already tried to explain, that's just based on a wrong assumption. There are a lot of people who use a mouse or other pointing devices and at the same time need a clearly visible focus style.

Worth reminding all browsers have a default focus style and the real origin of this kind of issues is when designers want to reset it with outline: none 🙂
It's a native functionality that should never be removed. If there's really, really, the need to change its style, then it's everyone responsibility to make it work in the exact same way as the native functionality works.

[folletto]

I read the analysis there.
Please split the analysis you're doing between the functionality and how it's used:

1. Functionality: the component in Add accessibleFocus utility. #846 introduces more flexibility for how design can handle focus behaviour. It doesn't negate any native behaviour, it just introduces an additional way to do it.
2. Usage: UI by UI, we then can review which design achieves the best result.

Let's merge that as it provides more options, and then discuss on the designs case by case.

[karmatosed]

@afercia what about those with visual issues that would find the extra clutter distracting. For example neuro-processing complications?

[afercia]

@karmatosed the best option would be: do nothing and remove any outline: none 🙂 Native functionalities are always better also because they work with different settings (for example High Contrast Mode on Windows, or when users set a different base font size, or zoom levels).

We should really try to distinguish how it looks from what it does. Instead of removing it, it'd say the best approach would be make it look better. Form follows function, no? FWIW I'm not the author of the focus style on the panel toggles and I'm not saying I like it 🙂

@folletto

the component in #846 introduces more flexibility

Not exactly. What it does, it's detecting when the following keys are used tab, space, left, up, right, down and only in this case it applies the focus style on some elements (and I suspect more elements in the future). It doesn't seem to me this can be called "flexibility". It's just removing a native functionality.

So I'm strongly opposed to removing the focus style under any circumstances. Making it better is very welcome.

For the one interested, some history here:
The “Eric Meyer Reset”
http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/

On that last point, defining an invisible focus was the biggest blunder of the original reset.

[jasmussen]

Without taking any side of the argument (I can live with the lingering focus outline, even if I don't think it's pretty) — I would like to just note that the native behavior changes as soon as you style an element like the button (and there are further differences between browsers). The details are in https://codepen.io/joen/pen/gRYazN, but it boils down to this:

• An unstyled button receives a focus outline that disappears after you've clicked
• A styled button — even just a bg color change — receives a focus outline that stays and lingers after you've clicked

For me, personally, it's the lingering outline that feels distracting, not the outline itself. If there was an accessible way to get rid of the lingering outline (emulate native behavior), I'd be fine with even a much heavier focus outline than we do now.

[folletto]

Not exactly. What it does, it's detecting when the following keys are used tab, space, left, up, right, down and only in this case it applies the focus style on some elements (and I suspect more elements in the future). It doesn't seem to me this can be called "flexibility". It's just removing a native functionality.

This is not correct. :)

It doesn't remove anything. It adds a class to the basic level: it's then up to the UI to decide if to use .accessible-focus ui:focus or ui:focus.

That's why I'm referring this to an architecture piece that allows more granularity. Your interpretation as the component "removing the focus style" is not a correct reading — thus there's no reason to be against it.

[afercia]

@folletto 🙂 That's not correct. On #846 what the lines like these ones do in your opinion?

-	&:focus:before {
+	.has-accessible-focus &:focus:before {

They apply the focus style on some elements just when using the keyboard. For example. the block mover buttons (and several other buttons):

.has-accessible-focus .components-icon-button:focus:before {
    content: '';
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    box-shadow: 0 0 0 1px #5b9dd9, 0 0 2px 1px rgba(30,140,190,0.8);
}

[folletto]

When I mentioned "we should take that approach" I meant the approach, not the specific of the design changes — which, as I illustrated above, must be entirely a different consideration. We shouldn't conflate the two.

Yet, now I understand our misunderstanding, so let me clarify that:

• We should merge the accessibleFocus() functionality.
• The CSS changes have to be evaluated independently.

[afercia]

must be entirely a different consideration.

🙂 I don't understand this distinction. What you call "the approach" is meant to be actually used, no? And its intended usage is to remove the focus style. Since I really hope the second thing is not going to happen, I don't see why the functionality should be merged.

[samikeijonen]

I wish this would be solved with CSS but I'm not sure if that's currently possible. :focus-ring spec is coming but it's not there yet.

I'm not sure what accessibleFocus() does but there is also :focus-ring polyfill out there.

If my vote count I'd go without JS and let the button on click have the focus styles. But in the same time make focus styles as good looking as possible.

Here is list of sources:

• Good overview of focus ring by Google Chrome Developer.
• :focus-ring polyfill.
• :focus-ring specs.

[avocadesign]

It's not just the outlines that are distracting - see the attached screenshot (short block of text with a link) and find the actual content under the crazy array of interface elements, editing short blocks of text is a nightmare at the moment.

[afercia]

I think it's more a design problem than the functionality itself. And the design can be improved. The focus style doesn't necessarily need to be a rectangular outline around an element. For the panel toggles for example, there are already some well established patterns in WordPress, see what the Customizer and Press This use:

[jasmussen]

@avocadesign I agree there's a lot going on there, especially with the link dialog. But there are multiple tickets and pull requests in progress to alleviate that, including these:

• Fixed toolbar: Editor: Try a fixed block toolbar #2148
• Combined Quick Toolbar: Polish quick toolbar #2151
• Lightweight block hover design: Try old hover design #2155

Let's keep this ticket focused on the focus outlines.

[samikeijonen]

Absolutely. That's a good example.

…

On Aug 11, 2017 10:12 AM, "Andrea Fercia" ***@***.***> wrote: I think it's more a design problem than the functionality itself. And the design can be improved. The focus style doesn't necessarily need to be a rectangular outline around an element. For the panel toggles for example, there are already some well established patterns in WordPress, see what the Customizer and Press This use: [image: screen shot 2017-08-11 at 08 48 00] <https://user-images.githubusercontent.com/1682452/29204070-157978ee-7e75-11e7-99c1-85a5a664fd7f.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2331 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvG_9Vjr-_tVPct9kgsT5G2ztXRnkf1ks5sW_7cgaJpZM4OzLO_> .

[cedon]

@jasmussen What about unfocused outlines as well? Just to give some kind of an indicator about the space it occupies in the editor.

[jasmussen]

Unfocused outlines could absolutely go hand in hand with a better outline design in general. That could be something to explore.

[joedolson]

Reading through this thread, it seems like a design issue that got derailed a bit into functionality. As far as I can tell, the operation of the :focus states is totally fine, but there are some issues with the design. I agree totally with @afercia that we should make better use of existing patterns elsewhere in WP. That will help with overall design comprehension since there will be better uniformity in behavior throughout the application.

The presence of the focus highlighting is absolutely critical for accessibility. But certainly the design can be improved.