Better visual indication of focus on elements in the Admin

[rianrietveld]

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/

[celloexpressions]

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

[celloexpressions]

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

[rianrietveld]

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

[celloexpressions]

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.

[rianrietveld]

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.

[joedolson]

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.

[rianrietveld]

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

[iammattthomas]

Use #666 as the focus border color

[iammattthomas]

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​

[rianrietveld]

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.

[nacin]

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

[nacin]

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.

[rianrietveld]

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.

[GrahamArmfield]

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.

[helen]

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.

[sharonaustin]

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?

[joedolson]

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.

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

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

[melchoyce]

Focus color on default color scheme

[melchoyce]

Focus color on sunrise scheme

[melchoyce]

Focus color on ectoplasm scheme

[melchoyce]

Color contrast test

[iammattthomas]

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.

[joedolson]

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.

[celloexpressions]

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

[celloexpressions]

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.

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

[melchoyce]

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.

[joedolson]

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.

[celloexpressions]

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

[helen]

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.

[sharonaustin]

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]

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

[celloexpressions]

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.

[helen]

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.

[helen]

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.

[paulwilde]

editor.css still retains the old border colour and isn't consistent with these changes.

[helen]

In 27771:

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