Visible Focus within Admin Screens could be much clearer.

[grahamarmfield]

Users who prefer to, or need to tab around the admin screens do not always get clear feedback as to the current focus location. If focus gets 'lost' it is very hard for some to orientate themselves within the screens and easily carry out the tasks they want to complete.

Can I suggest that all items that can receive focus - links, form fields etc should overtly indicate that they have focus. This would satisfy WCAG2.0 success criteria 2.4.7

I have created a rough plugin which I have used on a couple of sites to help users see where focus is (attached). Although the effect is perhaps a little crass in my plugin, at least you can very easily see where focus goes. Slightly subtler colours could be used - the WordPress button blue maybe, with a more pastel shade as the background for the form fields.

The plugin also adds a Skip to Content link in the menu - not relevant here but this is the subject of another ticket.

[grahamarmfield]

Plugin to add more overt focus visibility (and Skip to Content link).

[azaozz]

Posted on ​Make/UI regarding styling for :focus and :active states for links and buttons. Text fields and most trextareas have slightly darker border when focused, may need a bit more visible styling.

[azaozz]

21324.patch adds a 'screen-reader-text' link to skip to the main content, fixed in [21305].

[azaozz]

In [21510]:

Stop Chrome from applying outline to DIVs that have tabindex="-1", see #21324

[lessbloat]

In 21324-focus-active.diff I attempted to add a visible :focus and :active state for links. I played around with a bunch of color options, and settled on:

And "outline: thin dotted" for the active state.

The a:focus style works only on focus via tabbing (not when you hover, or click with a mouse). This color combo provides "enhanced" contrast for regular sized text under WCAG 2.0 1.4.6 (Level AAA).

A couple notes:

• The main nav and the toolbar already have :focus styles and are not affected by this change.

• I tested as many areas of the admin as I could think to test. Though, these changes, have the potential of affecting pretty much every page of the admin, so this needs to be reviewed carefully.

• I tried to set this up so that we don't need an "Accessibility" option in settings, though that is still an option.

• I left buttons/form fields alone for now. If we do think they still need to be changed, they should probably be in a separate patch.

Open to any feedback/change requests from those of you who work regularly with accessibility design.

[azaozz]

Replying to lessbloat:

...
I tested as many areas of the admin as I could think to test. Though, these changes, have the potential of affecting pretty much every page of the admin, so this needs to be reviewed carefully.

Looks very good. Thinking it should be committed so it can be tested easier and any conflicts/irregularities caught.

The JS that blurs all links on click might conflict with something, moving that to run at "the bottom" of the DOM to minimize the chance.

I left buttons/form fields alone for now. If we do think they still need to be changed, they should probably be in a separate patch.

Sounds good. The text input fields have darker border (not sure if that's enough) but all other form elements would need some sort of highlighting, especially checkboxes and radio buttons.

[azaozz]

In [21529]:

Add :focus style to all links, use JS to blur() them on click so the style is only visible when tabbing, props lessbloat, see #21324

[lessbloat]

Semi-related: #21598

Thought I'd take a stab at updating the buttons altogether.

[toscho]

Replying to azaozz:

In [21529]:

background-color: transparent url(../images/arrows.png) no-repeat right 4px;

That should be just background, right? An URL is not a color. :)

[helenyhou]

Replying to toscho:

background-color: transparent url(../images/arrows.png) no-repeat right 4px;

That should be just background, right? An URL is not a color. :)

Certainly seems so.

[azaozz]

In [21534]:

Fix typo in [21529], props toscho. Simplify the :focus styles for the Screen Options and Help toggles, see #21324

[azaozz]

Replying to helenyhou:

Yes, definitely a typo. Also the styles there can be simpler, no need for 3 background image references.

[lessbloat]

Bolder form element :focus styles

[toscho]

Replying to lessbloat:

The property without prefix (box-shadow) should always be the last in case the final implementation is different than the earlier versions. See the recent changes to gradients.

-o-box-shadow and -moz-box-shadow should not be used. Opera supports box-shadow since 2009, Firefox since version 4.0. :)

[lessbloat]

Updated based on feedback from toscho

[lessbloat]

Replying to toscho:

The property without prefix (box-shadow) should always be the last in case the final implementation is different than the earlier versions. See the recent changes to gradients.

-o-box-shadow and -moz-box-shadow should not be used. Opera supports box-shadow since 2009, Firefox since version 4.0. :)

Thanks toscho, updated in 21324-focus-form-elements-2.diff

[helenyhou]

More CSS review: don't need the -ms- prefix for box-shadow :) Really, we only need -webkit-, which is for Mobile Safari before iOS 5 (not sure if/when we'll drop that), and the unprefixed. Also, vendor prefixes with the same values should be padded with spaces after the colon to right align the values: ​http://make.wordpress.org/core/handbook/coding-standards/css/#vendor-prefixes

[azaozz]

In [21641]:

More visible :focus style for form elements, props lessbloat, see #21324

[azaozz]

In some places the new :focus style didn't apply, fixed there too.

Replying to helenyhou:

Right, no need for -ms- as IE10 uses the standard. Not sure if -webkit- is still needed too. Will have to format all box-shadow one of these days :)

[azaozz]

We also need :focus styles for the TinyMCE buttons, currently there is no change.

[lessbloat]

Replying to azaozz:

We also need :focus styles for the TinyMCE buttons, currently there is no change.

Related: #18141

[SergeyBiryukov]

Since [21641], rows on the Posts screen look a bit squished: ​http://cl.ly/image/2h1r1I0w0l20 (on left, trunk; on right, 3.4).

Reported by nacin in the ​UI chat.

Caused by removing the padding for checkbox column:

.widefat tbody th.check-column {
	padding: 9px 0 22px;
}

[azaozz]

Replying to SergeyBiryukov:

Since [21641], rows on the Posts screen look a bit squished...
Caused by removing the padding for checkbox column.

Yeah, noticed that too. The padding for the checkboxes was pushing them down, so they weren't aligned properly (couple of versions ago they were). If we want taller rows in the list tables, better to use min-height, not depend on padding that behaves a bit differently in different browsers.

[azaozz]

Uh, I take that back :)

Setting table cell height behaves even more inconsistently in the different browsers. Back to using padding...

[azaozz]

In [21671]:

Fix min row height in .widefat, see #21324

[SergeyBiryukov]

On Edit Post screen, when clicking the "Preview" button, "All Categories" tab, or "Choose from the most used tags", blue background appears (blur() is not applied): 21324.no-blur.png​.

[SergeyBiryukov]

Same on the Menus screen: 21324.no-blur.2.png​.

[SergeyBiryukov]

Also when clicking the Update button in Quick Edit: 21324.no-blur.3.png​.

[SergeyBiryukov]

On login form: 21324.no-blur.4.png​

[lessbloat]

21324.5.diff attempts to address the issues brought up by @SergeyBiryukov

[SergeyBiryukov]

Button focus styles are already fixed in #21598, so the CSS changes from 21324.5.diff​ are no longer needed.

We don't have jQuery on wp-login.php, so that part doesn't work. We need to come up with a pure JS solution. 21324.6.diff​ is an attempt to do that. Also hides outline on .login h1 a (WP logo).

Found one more bug (not covered in the patch): Visual and Text tabs briefly turn white on click.

[SergeyBiryukov]

Replying to SergeyBiryukov:

Visual and Text tabs briefly turn white on click.

Fixed in 21324.7.diff​.

Another thing to mention is that outline is briefly displayed when clicking most of the links in the admin, including Visual/Text tabs. Is that intentional, or perhaps the JS that hides focus on click should also hide outline?

[SergeyBiryukov]

Perhaps the $('.postbox .inside a') part would make more sense in post.js.

21324.8.diff​ also fixes spaces vs. tabs while we're there.

[SergeyBiryukov]

To summarize, 21324.8.diff​ fixes:

• Blur for meta box tabs and links on Edit Post screen (21324.no-blur.png​)
• Blur for meta box tabs on Menus screen (21324.no-blur.2.png​)
• Blur for links on login form (21324.no-blur.4.png​)
• Outline of WordPress logo on login form (comment:29)
• Background of editor tabs (comment:29)

[lessbloat]

input:focus was just a tad too pronounced (especially the title field on the edit post screen), lightened it up in 21324.9.diff.

[SergeyBiryukov]

Also need blur for "select a file" link in the customizer (when uploading a background image).

[SergeyBiryukov]

Also "Add New" link on Posts and Pages screens.

[lessbloat]

Changes in 21324.10.diff:

• Update of 21324.9.diff
• :focus style for theme screenshots in theme selector
• blur for "select a file" link in the customizer
• fixed "Add New" link on Posts and Pages screens

[lessbloat]

21324.11.diff is an update of 21324.10.diff

[SergeyBiryukov]

Tested 21324.11.diff​, looks good to me.

[grahamarmfield]

Replying to SergeyBiryukov:

Tested 21324.11.diff​, looks good to me.

Yes this is looking much better.

[azaozz]

Still a bit uneasy on blurring all links in the admin on click with JS. This could potentially break some functionality in plugins or external css. And of course this won't work when JS is disabled but not concerned too much about that. Unfortunately the other option (having another body class that turns this highlighting on) won't work as good.

Some more thoughts after testing 21324.11.diff:

• Why do we need a:active {background: none;} and then negate it here and there (the Text editor tab still needs a background when :active)?
• Still missing clearly visible focus for checkboxes and radio buttons. Seems the best option for them would be an outline?
• Maybe we should consider using a body class and making the focus even more prominent, perhaps adding outlines too as "high visibility" mode?

[helenyhou]

Late to the party, but I'd love to know more about why we're doing so much blurring with JS and why it's a good path forward. Something about blurring clicks on almost every link in the admin just to maintain the design in its non-active state doesn't seem right. Also, like azaozz, I am worried about what it could potentially affect that we haven't thought of or encountered yet.

What would issues be with using outline (like the way many browsers do by default) and allowing it to continue showing after clicking instead of blurring it away? There wasn't an outline on focus before, so it really was completely unnoticeable where you were if you tabbed around even a little bit, but I feel like the background color was a little bit of an awkward way to go in core. I also think that there is something to be said for going with browser defaults, as it's what people are accustomed to looking for. I actually don't really notice the blue because I'm expecting an outline instead.

As for the higher visibility part - a background color does indeed seem more visible than an outline, but to be honest, at least in this application, it looks weird and out of place in the design. That we need to hide it via that JS blur speaks to that, I think. Because it's not a browser default way of handling focus styles, it should especially fit with the admin, and I don't think it does. It's also not great for regular text links that don't have padding because it won't extend past the boundaries of the text itself and makes the text rather harder to read because of all the edges at once.

I definitely want to support high visibility/high contrast/enhanced accessibility, but I think implementing something along those lines as the default in core (as opposed to a mode or a plugin) to the detriment of other parts (the overall visual and JS in this case) is not advisable. We can certainly do better than what we had in terms of visible focus, because we kind of had nothing, but I think we've gone past a sane default state into what should probably be in an enhanced accessibility mode instead, and needing a JS workaround to accommodate what should be basic styling is not good.

[grahamarmfield]

Replying to helenyhou:

Late to the party, but I'd love to know more about why we're doing so much blurring with JS and why it's a good path forward. Something about blurring clicks on almost every link in the admin just to maintain the design in its non-active state doesn't seem right. Also, like azaozz, I am worried about what it could potentially affect that we haven't thought of or encountered yet.

I know very little about how the WordPress Admin screens are put together but I am surprised that it's necessary to use javascript to toggle the focus state on and off. Wouldn't using :focus in the CSS do the job as well? But as I say I don't know how the screens are put together.

What would issues be with using outline (like the way many browsers do by default) and allowing it to continue showing after clicking instead of blurring it away? There wasn't an outline on focus before, so it really was completely unnoticeable where you were if you tabbed around even a little bit, but I feel like the background color was a little bit of an awkward way to go in core. I also think that there is something to be said for going with browser defaults, as it's what people are accustomed to looking for. I actually don't really notice the blue because I'm expecting an outline instead.

As for the higher visibility part - a background color does indeed seem more visible than an outline, but to be honest, at least in this application, it looks weird and out of place in the design. That we need to hide it via that JS blur speaks to that, I think. Because it's not a browser default way of handling focus styles, it should especially fit with the admin, and I don't think it does. It's also not great for regular text links that don't have padding because it won't extend past the boundaries of the text itself and makes the text rather harder to read because of all the edges at once.

You say yourself that having a background colour is more visible than an outline - and that's what so good about the background colour option for me. Outlines can be easily overlooked. I'm sure that it feels odd to see a background colour on focus within the admin screens but to me this looks like a very positive development. Those users using a mouse will not see the background colour.

I definitely want to support high visibility/high contrast/enhanced accessibility, but I think implementing something along those lines as the default in core (as opposed to a mode or a plugin) to the detriment of other parts (the overall visual and JS in this case) is not advisable. We can certainly do better than what we had in terms of visible focus, because we kind of had nothing, but I think we've gone past a sane default state into what should probably be in an enhanced accessibility mode instead, and needing a JS workaround to accommodate what should be basic styling is not good.

My view is that improved accessibility should be a default option wherever possible - not subject to a plugin. I don't believe any of the accessibility improvements in 3.5 that I've seen so far compromise the experience for existing users.

[lessbloat]

A couple of thoughts:

• To be honest, I don't mind the background color on :focus as it stands in 21324.11.diff. As @grahamarmfield pointed out, it doesn't compromise the existing experience. Users who don't browse by tabbing, won't even know it's there, so I don't feel like it's "weird or out of place in the design" at all really.
• With that said... The background color can only work if the links blur on click. What happens otherwise in some browsers (FF specifically) when you click a link, for a brief second (before the page redirects), the link is focused, and the background color shows. This is jarring, and regrettably not acceptable in my mind. If we must do away with auto-bluring on click, we've got to get rid of having a background color for links on :focus.
• Personally, I'd prefer that we avoid having to add a "high visibility" setting, if at all possible. The reason I was happy with the solution in 21324.11.diff was because it seemed like a win-win. A happy medium.
• In 21324.12.diff I've moved us to using outlines instead of a background color, and I've removed the auto-blur JS. I'd love to get this reviewed quickly, and get it committed so that those with more accessibility experience can review it without having to apply a patch.
• I also noticed that along the way we've lost almost all :focus styles on the new buttons. I'll address this over on #21598

[lessbloat]

Replying to azaozz:

Why do we need a:active {background: none;} and then negate it here and there (the Text editor tab still needs a background when :active)?

Removed in 21324.12.diff

Still missing clearly visible focus for checkboxes and radio buttons. Seems the best option for them would be an outline?

Added in 21324.12b.diff

[helenyhou]

Replying to grahamarmfield:

I know very little about how the WordPress Admin screens are put together but I am surprised that it's necessary to use javascript to toggle the focus state on and off.

:focus styles appear whenever you've either tabbed to an item or clicked on it (mouse down), and stays after mouse up. :active is the style that appears only on mouse down. There is no real keyboard-only interaction state. My take here is that if the style applied has to be whisked away by JavaScript in order to maintain the visual, then we have gone too far into what I would consider enhanced accessibility as default rather than improved accessibility. I think it's fair to differentiate the two, and feel rather as though I am being taken as saying that we shouldn't improve the accessibility at all here, which is not true.

I am trying to stay more aware of accessibility in core and make sure we don't neglect it, even though I am not any sort of expert in or even user of said features beyond preferring to stay on the keyboard, nor a lead or core developer by any means. What I am asking in this situation is why we should feel that JS is an acceptable workaround, and what an alternative no-JS solution might be, be it an outline or something else that somebody comes up with.

You say yourself that having a background colour is more visible than an outline - and that's what so good about the background colour option for me. Outlines can be easily overlooked. I'm sure that it feels odd to see a background colour on focus within the admin screens but to me this looks like a very positive development. Those users using a mouse will not see the background colour.

As above, those using the mouse do see the background color without JavaScript, which I also find jarring and rather not acceptable as the default setting in core. Also, though the background color is more noticeable on its own merits, I do still feel that it makes regular text links rather more difficult to read because generally the background color does not extend past the edges of the text, and when it does, it looks a little bit random, or broken. One of the first things we learn about text on the web is that it's very difficult to read when it has a lack of negative space around it, yet that lack of negative space is exactly what the background color does here. We cannot add padding to it without adversely affecting everything in the admin, so that is unfortunately not an option.

My view is that improved accessibility should be a default option wherever possible - not subject to a plugin. I don't believe any of the accessibility improvements in 3.5 that I've seen so far compromise the experience for existing users.

Improved, yes. Enhanced, not if it affects the experience for all users. I am very happy with everything else we've seen in 3.5 so far, including what's in the works, but this particular case does not seem right to me, and it's mostly because of the JS required. I can live with not personally liking the background color if those who need high visibility find it to be more useful, but requiring a JS workaround as the default in core is not acceptable.

[lessbloat]

Replying to helenyhou:

I can live with not personally liking the background color if those who need high visibility find it to be more useful, but requiring a JS workaround as the default in core is not acceptable.

Is it specifically the fact that using

$('a').click(function () {
    $(this).blur();
});

is a bit too brute force? If so, I agree. The only reason I used it is that I couldn't think of any other solution at the time.

I spent a bit more time thinking about it this morning, and thought I'd offer up another approach. 21324.13.diff still uses JS, but it simply adds and removes a class (.clicked) to links on click, which seems much less intrusive to me than forcing blur().

It works surprisingly well in my tests (on Mac FF, Chrome, Safari & Win IE7, FF, Chrome) Performance wise, I wouldn't think we'd see any issues (even on lower CPU computers). I'd specifically love to hear @azaozz and @helenyhou's thoughts on this approach.

[azaozz]

Replying to lessbloat:

I spent a bit more time thinking about it this morning, and thought I'd offer up another approach. 21324.13.diff still uses JS, but it simply adds and removes a class (.clicked) to links on click, which seems much less intrusive to me than forcing blur().

Ha, was just thinking/trying something similar yesterday night :)

The problem is how to distinguish between "tabbed to" links and "clicked" links so we can highlight them when tabbing but not when clicking. Adding a class on click that negates the "highlighting" styles seems like a good way to do that.

Thinking we don't need to add/remove that class on each link. A simpler solution would be to add/remove it on the body and then have:

<style>
body.tabbing a:focus { ..do highlighting.. }
</style>

<script>
document.body.onclick = function(){ remove 'tabbing' class }
document.body.onkeydown = function(){ if ( tab key ) { add 'tabbing' class } }
</script>

This is still JS driven but is a lot more subtle than blurring each <a> on click. Still want to test/play a bit more with the idea.

[nacin]

The problem is how to distinguish between "tabbed to" links and "clicked" links so we can highlight them when tabbing but not when clicking. Adding a class on click that negates the "highlighting" styles seems like a good way to do that.

I think this is a solution for a problem that doesn't actually exist. Let's just have good :focus and :active styles that make good accessibility sense without making it ugly for other users, and call it a day?

[azaozz]

Agreed, that would be best. The default in IE and FF is 1px dashed outline. It can be a bit hard to see in some places but subtle enough not to interfere with any visual elements.

[lessbloat]

Replying to nacin:

Let's just have good :focus and :active styles that make good accessibility sense without making it ugly for other users, and call it a day?

As far as I can tell, both have good :focus and :active styles without making it ugly for other users.

21324.12b.diff

• uses outlines on focus
• doesn't require any JS
• is a tad harder to see on the screen
• leaves a dotted outline around the link on click in FF (while waiting for the page to refresh)

21324.13.diff

• uses background color on focus
• requires some JS to do it right
• but is much easier to see
• leaves no outline on click

Neither approach should negatively affect users who aren't browsing by tabbing. In my mind, it's just a matter of which option will serve users best.

[helenyhou]

I would consider a JS solution to not be serving users best :) Much prefer 21324.12b.diff​, although I'm not sure radio/checkboxes need them - thought browsers already had their own special focus styling there, but perhaps there is one that I'm not thinking of. I think the one place we have to worry about not having the outline after click is tabs, since you don't leave the screen. Since those are JS powered already, can deal with that in the JS that switches the tabs.

[lessbloat]

Replying to helenyhou:

thought browsers already had their own special focus styling there

Not chrome unfortunately.

[lessbloat]

Replying to lessbloat:

Not chrome unfortunately.

I realized that sounded weird, so I went to investigate. Turns out line 311 in wp-admin.css is what's preventing the default :focus outline behavior in the admin:

a, input, select, textarea, div {
outline: 0;
}

We could be more specific there (excluding radios and checkboxes), and let the default browser style shine. :-)

[rianrietveld]

Very late to the party, but here's my 2 cents: I agree with helenyhou, nacin and lessbloat. Better solve the problem without JS and in a way most browsers handle the focus styling, with an outline.
I love the way Safari solved this: with a nice blue outline for items in focus.
Keyboard users are used to that and then there's no need to burden the code with extra JS.

But I have some questions using the keyboard:
Using the keyboard I noticed with post.php, there is no focus on change permalinks, view post, beta media and upload/insert. Or was there an outline missing, couldn't see.
The span with the permalink has a tabindex="-1". Why? <span id="sample-permalink" tabindex="-1">.../?page_id=2</span>

Further: with a overlay screen like "Choose a Featured Image", the focus stays in the page it self and doesn't move to the overlay.
I found an article about that with a solution: ​http://webstandardssherpa.com/reviews/overlays-and-lightboxes-keys-to-success/
I'm not sure if this can be used in our case, but it's an issue worth looking into.

[helenyhou]

Replying to lessbloat:

Turns out line 311 in wp-admin.css is what's preventing the default :focus outline behavior in the admin:

a, input, select, textarea, div {
outline: 0;
}

Seems to me we shouldn't be doing that at the global level at all and just setting it to none in more specific cases we don't want the outline. div:focus probably doesn't need it, for instance, if it even gets it in the first place. Then the browser does its thing for everything else.

Replying to rianrietveld:

The span with the permalink has a tabindex="-1". Why? <span id="sample-permalink" tabindex="-1">.../?page_id=2</span>

#21340 - perhaps we should reopen with a comment about that?

Further: with a overlay screen like "Choose a Featured Image", the focus stays in the page it self and doesn't move to the overlay.

Not sure we have a ticket specifically about this - I couldn't find one. May be worth opening one, although do no note that the media overlays are completely new in 3.5, and we do have some specific work being done for this cycle on #21283 for the customizer.

[nacin]

Generally speaking, turning off outlines for everything but :focus is a good balance between accessibility and appearance.

[lessbloat]

21324.14.diff uses 21324.12b.diff (focus with outlines), and corrects CSS to show default browser focus for radios and checkboxes in all browsers.

[azaozz]

In [22268]:

Improve visible focus in the admin, props lessbloat, fixes #21324