Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#27173 closed task (blessed) (fixed)

Better visual indication of focus on elements in the Admin

Reported by: rianrietveld's profile rianrietveld Owned by: helen's profile helen
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.8.1
Component: Administration Keywords: has-patch needs-testing
Focuses: ui, accessibility Cc:

Description

This is a follow-up to #26120.

The border style of for example a checkbox, radio button and an input field is border: 1px solid #bbb;
And with focus the style is

border: 1px solid #999;

To improve the accessibility it would be more clearly if the focus has the style

 border: 1px solid #555;

The styles are defined in:
wp-admin/css/colors.css and wp-admin/css/colors-rtl.css

See also the keyboard testing results of the Make WordPress Accessible group:
http://make.wordpress.org/accessibility/testing/3-8-admin-screens-results/

Attachments (13)

27173.diff (421 bytes) - added by celloexpressions 11 years ago.
Suggested outline color change on focus for all input-type elements.
27173.alt.diff (730 bytes) - added by celloexpressions 11 years ago.
Alternate approach, only changing the focused outline color for checkboxes and radio inputs.
27173.3.diff (428 bytes) - added by iammattthomas 11 years ago.
Use #666 as the focus border color
Screen Shot 2014-03-12 at 4.56.45 PM.png (38.1 KB) - added by melchoyce 11 years ago.
Focus color on default color scheme
Screen Shot 2014-03-12 at 5.09.43 PM.png (46.4 KB) - added by melchoyce 11 years ago.
Focus color on sunrise scheme
Screen Shot 2014-03-12 at 5.10.59 PM.png (46.1 KB) - added by melchoyce 11 years ago.
Focus color on ectoplasm scheme
Screen Shot 2014-03-12 at 5.05.09 PM.png (61.9 KB) - added by melchoyce 11 years ago.
Color contrast test
27173.4.diff (1.9 KB) - added by celloexpressions 11 years ago.
Use colorscheme's checkbox/radio mark color for border and shadow colors on focus, and add a slight animation.
27173.4-default.png (4.2 KB) - added by celloexpressions 11 years ago.
27173.4-midnight.png (4.1 KB) - added by celloexpressions 11 years ago.
27173.5.diff (1.3 KB) - added by celloexpressions 11 years ago.
Bounce the border color on focus (but not un-focus), remove redundant rule.
Screen Shot 2014-03-26 at 11.55.56 AM.png (20.6 KB) - added by helen 11 years ago.
27173.2.diff (797 bytes) - added by paulwilde 11 years ago.

Download all attachments as: .zip

Change History (46)

@celloexpressions
11 years ago

Suggested outline color change on focus for all input-type elements.

@celloexpressions
11 years ago

Alternate approach, only changing the focused outline color for checkboxes and radio inputs.

#1 @rianrietveld
11 years ago

@celloexpressions thanks for adding the patch :-) My preference would be the fist option, change outline color on focus for all input-type elements.

Version 0, edited 11 years ago by rianrietveld (next)

#2 @celloexpressions
11 years ago

Beat me to the comment :)

I agree that the suggested change is needed for checkboxes and radio options, but it seems a little harsh on larger inputs, textareas, and selects, since there's also a shadow change and those are so much larger. Are there any quantitative accessibility guidelines for this - how much contrast/change do we need, or is it subjective (in which case I would default to those of you with more experience here)?

I attached two patches - one for the change as suggested and the other only applying the change to checkbox and radio. I think either should be fine but someone involved in designing the current focus styles should weight in on 27173.diff if we want to go that route.

#3 @celloexpressions
11 years ago

  • Keywords has-patch added

#4 @rianrietveld
11 years ago

I suggested the #555 to meet WCAG 2.0 AAA text-rules as you can experiment with on http://snook.ca/technical/colour_contrast/colour.html

To my knowledge there are no accessibility rules for the contrast of outlines, as there are for text.

So you are right, it's probably subjective in this case. The checkboxes and radio buttons definitely need better focus, for the other inputs: more contrast would be nice for people who have problems with contrast.

#5 @joedolson
11 years ago

The guidelines do refer explicitly to color contrast for text and images of text, so you're correct, there are no guidelines indicating minimum focus contrast for a control outline. I think that there's room for compromise. The information conveyed by a focus outline is essentially simpler than that conveyed by text. Because text is complex, the focus needs to be higher in order to give the user enough visible information to read it; for the form control outline, all that needs to be detected is the presence of a change. Because the information density is much lower, it's probably acceptable to go somewhere in between.

#6 @rianrietveld
11 years ago

  • Keywords needs-testing added

Ok, lets go for 27173.alt.diff then.

#7 @SergeyBiryukov
11 years ago

  • Focuses ui added
  • Milestone changed from Awaiting Review to 3.9

@iammattthomas
11 years ago

Use #666 as the focus border color

#8 @iammattthomas
11 years ago

I think this looks fine, though I recommend going one shade lighter, #666 for the border color. I've used the first patch because I think it makes sense for all of these to match.

27173.3.diff

#9 @rianrietveld
11 years ago

Hi iammattthomas, today we discussed this on the Make WordPress Accessible group and we agree with your solution, #666 for the border color for all elements on focus.

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


11 years ago

#11 follow-up: @nacin
11 years ago

Even #666 is pretty still dark. It seems like #888 is AA. Workable? Just curious.

#12 @nacin
11 years ago

  • Type changed from enhancement to task (blessed)

I think the best (but possibly unrealistic) scenario is to use individual browser focus indicators (like Chrome's blue glow). As weird as it may be, at least it's consistent — and we've tried hard to let browsers do their things in other situations as well.

#13 @rianrietveld
11 years ago

Meet in the middle at 777?

You are right, in a better world all browsers should handle this properly, as Chrome does. But maybe it's quicker and easier to change the CSS here than to convince browsers to add a better visual focus.

#14 in reply to: ↑ 11 @GrahamArmfield
11 years ago

Replying to nacin:

Even #666 is pretty still dark. It seems like #888 is AA. Workable? Just curious.

Recently I visited the Digital Accessibility Centre in South Wales (UK) to get some feedback on WordPress from their disabled and impaired staff.

The issues with visible focus being too subtle in the admin area was brought up by both the motor-impaired person I spoke to, and the person with only poor vision in one eye - and their issue was not just with the checkboxes. So, the more colour contrast we can bring in here the better.

#15 @helen
11 years ago

Are there other options for focus style we can consider? Just darkening the border color isn't a very pretty thing to begin with, and going darker still looks even worse. I don't think we need to sacrifice design for accessibility or the other way around - surely there's a way.

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


11 years ago

#17 @sharonaustin
11 years ago

Helen, how do you feel about something similar to very bright large yellow boxes against a dark background, very bright blue boxes against a light background, (sounds awful, but with the current fashion of "flat" web designs, looks really good in practice) as seen in this example? http://www.deque.com/ Would this "kind" of thing work with the sensibilities you're after?

#18 follow-up: @joedolson
11 years ago

There are other options besides just darkening the outline color. I think that we should darken it, but the importance is degree of change, not just change of outline color. If the shadow highlight could be intensified, or the background color, as well, that would be helpful. Chrome's intense blue glow is a great focus indicator, and if all browsers offered something like that, we could definitely just leave focus to the browser.

Movement can also be very helpful in drawing focus, so adding a transition to the change would also help; if it flashed dark and then faded, for example. The shift can be very helpful in drawing attention.

Why not actually use something more equivalent to Chrome's blue glow, e.g.: http://css-tricks.com/snippets/css/glowing-blue-input-highlights/, perhaps color-shifted to a WP brand color.

#19 follow-up: @melchoyce
11 years ago

What about using #0074A2 , the link color? We could do something like:

border-color: #0074A2;
-webkit-box-shadow: 0 0px 3px rgba(0, 116, 162, 0.75);
box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1);

I'm going to post a couple screenshots following this comment.

@melchoyce
11 years ago

Focus color on default color scheme

@melchoyce
11 years ago

Focus color on sunrise scheme

@melchoyce
11 years ago

Focus color on ectoplasm scheme

@melchoyce
11 years ago

Color contrast test

#20 in reply to: ↑ 19 @iammattthomas
11 years ago

Replying to melchoyce:

What about using #0074A2 , the link color? We could do something like:

border-color: #0074A2;
-webkit-box-shadow: 0 0px 3px rgba(0, 116, 162, 0.75);
box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1);

+1 for this. It's consistent across browsers, uses color to draw more attention than #666, and can be keyed to the color schemes' choice for checkmarks & radio dots.

Last edited 11 years ago by ocean90 (previous) (diff)

#21 @joedolson
11 years ago

Being able to key it to an existing system color is a big plus. I do think that adding the transition would also be beneficial, from an accessibility standpoint, but I would consider #0074a2 a good choice.

+1 from me.

Last edited 11 years ago by ocean90 (previous) (diff)

@celloexpressions
11 years ago

Use colorscheme's checkbox/radio mark color for border and shadow colors on focus, and add a slight animation.

#22 @celloexpressions
11 years ago

27173.4.diff attempts to implement a variety of the recent suggestions here to facilitate discussion:

  • Add a slight animation for the border-color (using the timing and timing functions used by link hover animations). We could go a bit slower (.1s) if this isn't enough.
  • Use the default color for checkbox/radio button marks for the border and box-shadow colors on input focus.
  • Use the colorscheme's color for border and shadow on focus (first time working with SASS, may have messed that up a bit).
  • Shadow is similar to melchoyce's suggestion, but slightly cleaner.

Also attached a couple screenshots.

#23 follow-up: @paulwilde
11 years ago

I feel using the admin colour scheme for the border colour isn't the greatest of ideas.

Looking at the screenshot you've attached, the red outline strikes to me as suggesting to the user that they have an error with their input as this is pretty common with email validation fields and such.

#24 in reply to: ↑ 23 @melchoyce
11 years ago

Replying to paulwilde:

I feel using the admin colour scheme for the border colour isn't the greatest of ideas.

Looking at the screenshot you've attached, the red outline strikes to me as suggesting to the user that they have an error with their input as this is pretty common with email validation fields and such.

I agree. Relying upon each color scheme's highlight color can lead to some serious usability issues. Since we allow people to create custom admin schemes, we have no way of making sure the highlight colors they choose are going to have a high enough color contrast, either.

#25 @joedolson
11 years ago

I think the concept is sound, but agree that this color choice takes us into the "looks like an error" realm. Going to link color would be preferable.

Regarding using admin theme's colors: I don't think we can both protect people against bad choices and provide them with that much control. Having this as a customizable color can also result in improvements in usability. But perhaps connecting it to pre-existing color is problematic.

#26 @celloexpressions
11 years ago

If we go with anything non-grayscale, it should be customizable in color schemes. Link color is, although none of the built-in schemes change it. The other option would be to create a new color variable, selecting the most appropriate default color and allowing it to be easily overwritten, even if none of the core colorschemes change it.

Personally, I like the idea of it getting a splash of color, but I don't see blue working for every colorscheme (though I'm not a fan of the always-blue link color either). In terms of contrast for that color, it is separate from the highlight color (but defaults to highlight) and if there isn't enough contrast for the borders there wouldn't be for checked checkboxes either.

At this point I think either the original suggestion of #555 or something with color that adapts to colorschemes would be the best options. $form-checked is a logical solution, but may require changing that value when it's red (midnight and sunrise).

#27 @helen
11 years ago

I would be a no on making this related to the chosen color scheme. Much prefer consistency. #555 is too dark design-wise, also a no.

#28 @sharonaustin
11 years ago

Although I understand wanting to coordinate with color schemes, I too, would recommend to avoid using the red outline if at all possible. There's just too strong an impression that an error has been made. It would create the consequence of an inconsistent (and therefore confusing) user experience within Wordpress, as far as visual cues are concerned, since in other areas of WordPress red is used as a warning.

What about avoiding color-scheme issues altogether and simply increasing the border-size of focused elements?

@celloexpressions
11 years ago

Bounce the border color on focus (but not un-focus), remove redundant rule.

#29 in reply to: ↑ 18 @celloexpressions
11 years ago

Replying to joedolson:

Movement can also be very helpful in drawing focus, so adding a transition to the change would also help; if it flashed dark and then faded, for example. The shift can be very helpful in drawing attention.

Since introducing color seems to be problematic (I'm sure we can figure it out, but it does complicate things), I've added 27173.5.diff for discussion.

In this patch, I've kept the current colors and shadows for focus styles. The only change is the addition of a "bouncing" animation, via CSS3 transitions with custom timing functions (supported by latest few versions of all major browsers, falls back to non-bouncing animation otherwise). This causes the border color to flash to somewhere around #555 (approximating the math) for a split second before fading back to #999 (the current value). The movement definitely helps draw attention to the focus, although it could be more effective in conjunction with the addition of a colored glow.

We could apply this effect to any focus indicator we end up picking (darkening, colored glow, thicker border, background color, outline, etc.) to achieve greater focus without impacting the design too heavily.

#30 @helen
11 years ago

I think we can go the direction of 27173.4.diff, but without keying to color schemes, and my inclination is to go with the Webkit blue of #5b9dd9 for the border color instead, which is just a bit lighter. See screenshot above. The bouncing was neat, but I think overkill.

#31 @helen
11 years ago

  • Owner set to helen
  • Resolution set to fixed
  • Status changed from new to closed

In 27741:

Better focus styles for form elements in the admin. These are purposefully not keyed to admin color schemes, as different colors could communicate a state like an error as opposed to focus. props celloexpressions. fixes #27173.

#32 @paulwilde
11 years ago

editor.css still retains the old border colour and isn't consistent with these changes. .mce-textbox input fields to be specific.

Last edited 11 years ago by paulwilde (previous) (diff)

@paulwilde
11 years ago

#33 @helen
11 years ago

In 27771:

Match TinyMCE modal form element focus styling to the admin. props paulwilde. see #27173.

Note: See TracTickets for help on using tickets.