WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#28267 closed defect (bug) (fixed)

Unify focus styles across the admin

Reported by: helen Owned by: helen
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: ui, administration Cc:

Description

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.

Attachments (10)

28267.patch (534 bytes) - added by zamfeer 4 years ago.
28267.customizer.diff (2.4 KB) - added by celloexpressions 3 years ago.
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.
28267.customizer.png (11.8 KB) - added by celloexpressions 3 years ago.
In the Customizer, accordion section hover and focus styles match open/active-section title styles. We should maintain this patter but introduce more contrast.
FF-link-active-state.png (8.9 KB) - added by afercia 3 years ago.
28267.2.patch (358 bytes) - added by afercia 3 years ago.
28267.3.patch (8.6 KB) - added by iseulde 3 years ago.
28267.4.patch (9.8 KB) - added by iseulde 3 years ago.
28267.5.patch (10.8 KB) - added by iseulde 3 years ago.
28267.6.patch (11.8 KB) - added by iseulde 3 years ago.
28267.primary-button-colorschemes.diff (1.0 KB) - added by celloexpressions 3 years ago.
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.

Download all attachments as: .zip

Change History (48)

#1 @helen
4 years ago

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

@zamfeer
4 years ago

#2 @zamfeer
4 years ago

  • Keywords has-patch added

#3 @zamfeer
4 years ago

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

#4 @iseulde
4 years ago

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

#5 @zamfeer
4 years ago

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.

#6 follow-up: @helen
4 years ago

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):

http://s.hyhs.me/VgZW/image.png

#7 in reply to: ↑ 6 @helen
4 years ago

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.

#8 @helen
4 years ago

In 28608:

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

#9 @helen
4 years ago

In 28616:

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

This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.


4 years ago

This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.


4 years ago

#12 @davidakennedy
4 years ago

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!

This ticket was mentioned in IRC in #wordpress-ui by accessiblejoe. View the logs.


4 years ago

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


3 years ago

@celloexpressions
3 years ago

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
3 years ago

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

This ticket was mentioned in IRC in #wordpress-ui by davidakennedy. View the logs.


3 years ago

#16 @afercia
3 years ago

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.

@afercia
3 years ago

#17 @ocean90
3 years ago

In 29122:

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

fixes #28834.
props nvwd.

#18 follow-up: @davidakennedy
3 years ago

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.

#19 in reply to: ↑ 18 ; follow-up: @afercia
3 years ago

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.

#20 in reply to: ↑ 19 ; follow-up: @davidakennedy
3 years ago

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!

#21 in reply to: ↑ 20 @afercia
3 years ago

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:
http://s.hyhs.me/VgZW/image.png
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.

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


3 years ago

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


3 years ago

#24 @helen
3 years ago

In 29466:

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

#25 @celloexpressions
3 years ago

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.

#26 @johnbillion
3 years ago

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:

https://i.imgur.com/lUWGphe.png

Non-default colour scheme button focus style after:

https://i.imgur.com/0xGjFvH.png

Theme browser focus style:

https://i.imgur.com/hlivhFo.png

Help / Screen Options focus style:

https://i.imgur.com/j6FIE4a.png

#27 @johnbillion
3 years ago

Couple more:

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

https://i.imgur.com/jJpEqZ5.png

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

https://i.imgur.com/znE7P0i.png

#28 @iseulde
3 years ago

[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.)

#29 @helen
3 years ago

  • Owner set to helen
  • Status changed from new to accepted

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


3 years ago

@iseulde
3 years ago

@iseulde
3 years ago

@iseulde
3 years ago

#31 @iseulde
3 years ago

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
3 years ago

#32 @iseulde
3 years ago

Above patch should fix everything but the color schemes.

@celloexpressions
3 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


3 years ago

#34 @helen
3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#35 @helen
3 years ago

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.

#36 @helen
3 years ago

In 29648:

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

see #28267.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


3 years ago

This ticket was mentioned in Slack in #accessibility by florianziegler. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.