Unify focus styles across the admin

[helen]

We spent a fair bit of time in 3.9 getting focus styles on inputs feeling both noticeable and beautiful, and we should now bring that to more places in the admin. For instance, the dotted outline around text links now feels clunky in comparison.

[helen]

zamfeer and I are working on this at our company summit.

[zamfeer]

I attached a patch that applies box-shadow styles to a:focus elements similar to input:focus

[iseulde]

Not sure if I like a solid line around a link, it looks weird...

[zamfeer]

It mimics the default user agent style for focussed elements, which I think is the expected behavior for keyboard navigation users. The goal of focus styles is not to be subtle, but to help users see the currently focussed element clearly. In areas like the media modal it can be difficult to follow the tab index around the various sections, so something more visible is needed. Having the focus be hard to see or radically different between elements can make it hard to tell where you are.

[helen]

The active style is wonky-as-in-ugly and we just should just remove that rule, I think, but the focus style is better and is consistent with Webkit's treatment, just as we've done for inputs. I would like to find a way to also add outline: #5b9dd9 solid 1px; if at all possible, as the box-shadow can get cut off and isn't supported in < IE9. Unfortunately, Firefox does this (I know, my preferred browser is letting me down):

[helen]

Replying to helen:

I would like to find a way to also add outline: #5b9dd9 solid 1px; if at all possible

... Duh, self, multiple box-shadows.

[helen]

In 28608:

Better align link element focus with form focus styling, which also improves the visibility. props zamfeer. see #28267.

[helen]

In 28616:

Don't use the box shadow focus styling for the admin menu or toolbar. see #28267.

[davidakennedy]

Helen: I took a look at this over the weekend, following our discussion during the accessibility team meeting. I agree with Joe Dolson:

• It looks good in most places. Some spots could use some styling work as the border gets cut off in spots.
• It doesn't matter which method we use: outline, border, etc. We just need to provide a method that doesn't reply on color alone. I like that you're experimenting here! Focus styles can be beautiful too.
• The main navigation on the left could use help too, as Joe said. It needs an non-color reliant indicator too.

Hope this helps!

[celloexpressions]

Proposed improved focus styling for Customizer sections and panel headings. It's bold, colorful, and similar to things that have been both proposed an in core in the past. Does work reasonably well with color schemes, could be a bit better.

[celloexpressions]

In the Customizer, accordion section hover and focus styles match open/active-section title styles. We should maintain this patter but introduce more contrast.

[afercia]

hi,
Firefox treats links states a bit differently from Webkit and when you click a link, while it's still "clicked", it's "active" and also "focused" so the box-shadow will be displayed on clicks too. See attached screenshot.
You should probably reset box-shadow on "active" state.

[ocean90]

In 29122:

Don't use box shadow focus styling for widget arrows, see #28267.

fixes #28834.
props nvwd.

[davidakennedy]

I did some testing and experimentation this week with the focus styles specifically for the navigation area on the left-hand side. We talked about it a bit in our last accessibility team meeting. What about something like this?

We can use borders (around all four sides) with the colors I have below. And for the "active/current" page, we can use borders around three sides (top, left, bottom), excluding the right where the little arrow is. That way, the border does not conflict with it. Very similar to what was proposed on the accessibility team blog: ​https://make.wordpress.org/accessibility/2014/06/25/visual-focus-indication-in-left-navigation/

Colors:

Default: White (fff) border on items
Light: Black (333) border on items
Blue: Black (333) border on items
Coffeee: White (fff) border on items
Ectoplasm: White (fff) border on items
Midnight: White (fff) border on items
Ocean: Black (150404 - note: fff just misses WCAG 2.0 contrast mark) border on items
Sunrise: White (fff) border on items

We might have to make some padding adjustments because of the spacing the borders add, but it shouldn't be too bad.

[afercia]

Replying to davidakennedy:

We might have to make some padding adjustments because of the spacing the borders add

hi, using multiple box-shadows would not require padding adjustments. Something like this on the current menu item:

box-shadow:
	inset 2px 0 0 0 #fff,
	-2px 0 0 2px #fff;
z-index: 4;

and something similar can be done for submenu items.

[davidakennedy]

Replying to afercia:

Replying to davidakennedy:

We might have to make some padding adjustments because of the spacing the borders add

hi, using multiple box-shadows would not require padding adjustments. Something like this on the current menu item:

box-shadow:
	inset 2px 0 0 0 #fff,
	-2px 0 0 2px #fff;
z-index: 4;

and something similar can be done for submenu items.

That's a great idea! But we're shooting for something different for the Admin menu and Toolbar. That's still the case as far as I know. See: https://core.trac.wordpress.org/ticket/28267?replyto=19#comment:9

Other suggestions are welcome!

[afercia]

Replying to davidakennedy:

That's a great idea! But we're shooting for something different for the Admin menu and Toolbar. That's still the case as far as I know. See: https://core.trac.wordpress.org/ticket/28267?replyto=19#comment:9

Other suggestions are welcome!

I thought Helen was referring to the "Webkit style" box-shadows currently used on generic links:

and that makes sense, but what about using specifically crafted box-shadows for the Admin menu and Toolbar? White solid ones will look as the ones suggested by the accessibility team, unless I'm missing something.

[helen]

In 29466:

Better focus styling for buttons and button groups. props mattheu, avryl, celloexpressions. fixes #27826. see #28267.

[celloexpressions]

Customizer focus styling is being punted to #29158. Admin menu focus styling is happening on #28599.

Not sure if anything else is left here for 4.0.

[johnbillion]

A few focus-related issues that I'm seeing:

• The focus style for themes in the theme browser still uses a dotted outline rather than our nice blue outline.
• The focus style on primary buttons has been lost if you're not using the default colour scheme.
• The focus style on the actual tabs for the Help and Screen Options tabs is still poor. Especially noticeable if you've just used the "Skip to main content" link.

Non-default colour scheme button focus style before:

Non-default colour scheme button focus style after:

Theme browser focus style:

Help / Screen Options focus style:

[johnbillion]

Couple more:

• Focus style for the colour picker doesn't get the blue outline:

• Focus style on menu items on the nav menus screen gets cut off:

[iseulde]

[29466] doesn't update editor.css and jquery-ui-dialog.css, while these files use the same rules. (I added a note on top of the buttons.css file last cycle btw, and this is partly my fault as I submitted an incomplete patch, not following my own advice.)

[iseulde]

For the menu handle, I removed the overflow: hidden... Not sure if that will cause any issues. I also moved te right label a bit to the left, so it doesn't stick to the link, and removed the top: -1px (not sure why?).

[iseulde]

Above patch should fix everything but the color schemes.

[celloexpressions]

Add the non-color-scheme-keyed outer focus box-shadow to the color-scheme-keyed inset box shadow to preserve focus styling for primary buttons.

[helen]

In 29616:

Focus styling: bring the blue glow to more places.

Handles color picker, theme browser, help/screen options, TinyMCE dialog buttons, jQuery UI dialog buttons, and buttons in color schemes.

props avryl, celloexpressions. fixes #28267.

[helen]

There are some things that are less than perfect overall, such as the cut off that happens when a container has overflow hidden. However, I am happy with the progress made in 4.0, and those instances all need to be dealt with individually. Nav menus in particular could use some overall thought and not just messing with the glow.

[helen]

In 29648:

Correct a Sass typo that somehow slipped by in [29616].

see #28267.