WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 21 months ago

#21324 closed task (blessed) (fixed)

Visible Focus within Admin Screens could be much clearer.

Reported by: grahamarmfield Owned by: azaozz
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.4.1
Component: Accessibility Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (20)

cc-admin-menu-accessibility.zip (1.7 KB) - added by grahamarmfield 2 years ago.
Plugin to add more overt focus visibility (and Skip to Content link).
21324.patch (1.0 KB) - added by azaozz 2 years ago.
21324-focus-active.diff (2.8 KB) - added by lessbloat 2 years ago.
21324-focus-form-elements.diff (1.2 KB) - added by lessbloat 23 months ago.
Bolder form element :focus styles
21324-focus-form-elements-2.diff (997 bytes) - added by lessbloat 23 months ago.
Updated based on feedback from toscho
21324.no-blur.png (8.2 KB) - added by SergeyBiryukov 23 months ago.
21324.no-blur.2.png (4.4 KB) - added by SergeyBiryukov 23 months ago.
21324.no-blur.3.png (5.0 KB) - added by SergeyBiryukov 23 months ago.
21324.no-blur.4.png (4.4 KB) - added by SergeyBiryukov 23 months ago.
21324.5.diff (4.8 KB) - added by lessbloat 23 months ago.
21324.6.diff (1.8 KB) - added by SergeyBiryukov 22 months ago.
21324.7.diff (2.6 KB) - added by SergeyBiryukov 22 months ago.
21324.8.diff (4.0 KB) - added by SergeyBiryukov 22 months ago.
21324.9.diff (4.4 KB) - added by lessbloat 22 months ago.
21324.10.diff (5.5 KB) - added by lessbloat 21 months ago.
21324.11.diff (5.5 KB) - added by lessbloat 21 months ago.
21324.12.diff (6.3 KB) - added by lessbloat 21 months ago.
21324.12b.diff (6.3 KB) - added by lessbloat 21 months ago.
21324.13.diff (6.9 KB) - added by lessbloat 21 months ago.
21324.14.diff (6.4 KB) - added by lessbloat 21 months ago.

Download all attachments as: .zip

Change History (81)

grahamarmfield2 years ago

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

comment:1 azaozz2 years ago

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

Version 0, edited 2 years ago by azaozz (next)

azaozz2 years ago

comment:2 azaozz2 years ago

  • Milestone changed from Awaiting Review to 3.5

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

Last edited 2 years ago by azaozz (previous) (diff)

comment:3 azaozz2 years ago

In [21510]:

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

comment:4 follow-up: lessbloat2 years ago

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:

http://f.cl.ly/items/2A0k143i3N2W2y0Q2N07/focus-preview.jpg

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

http://f.cl.ly/items/3t1u3M0y321b323K002K/focus-contrast.jpg

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.

comment:5 in reply to: ↑ 4 azaozz2 years ago

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.

comment:6 follow-up: azaozz2 years ago

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

comment:7 lessbloat2 years ago

Semi-related: #21598

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

comment:8 in reply to: ↑ 6 ; follow-up: toscho2 years ago

  • Cc info@… added

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

comment:9 in reply to: ↑ 8 ; follow-up: helenyhou2 years ago

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.

comment:10 azaozz2 years ago

In [21534]:

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

comment:11 in reply to: ↑ 9 azaozz2 years ago

Replying to helenyhou:

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

lessbloat23 months ago

Bolder form element :focus styles

comment:12 follow-up: lessbloat23 months ago

  • Keywords has-patch added

comment:13 in reply to: ↑ 12 ; follow-up: toscho23 months ago

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

Last edited 23 months ago by toscho (previous) (diff)

lessbloat23 months ago

Updated based on feedback from toscho

comment:14 in reply to: ↑ 13 lessbloat23 months ago

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

comment:15 follow-up: helenyhou23 months ago

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

comment:16 azaozz23 months ago

In [21641]:

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

comment:17 in reply to: ↑ 15 azaozz23 months ago

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

comment:18 follow-up: azaozz23 months ago

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

comment:19 in reply to: ↑ 18 lessbloat23 months ago

Replying to azaozz:

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

Related: #18141

comment:20 follow-up: SergeyBiryukov23 months ago

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;
}

comment:21 in reply to: ↑ 20 azaozz23 months ago

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.

comment:22 azaozz23 months ago

Uh, I take that back :)

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

comment:23 azaozz23 months ago

In [21671]:

Fix min row height in .widefat, see #21324

comment:24 SergeyBiryukov23 months ago

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.

comment:25 SergeyBiryukov23 months ago

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

comment:26 SergeyBiryukov23 months ago

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

lessbloat23 months ago

comment:28 lessbloat23 months ago

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

comment:29 follow-up: SergeyBiryukov22 months ago

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.

Last edited 22 months ago by SergeyBiryukov (previous) (diff)

SergeyBiryukov22 months ago

comment:30 in reply to: ↑ 29 SergeyBiryukov22 months ago

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?

SergeyBiryukov22 months ago

SergeyBiryukov22 months ago

comment:31 SergeyBiryukov22 months ago

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.

Last edited 22 months ago by SergeyBiryukov (previous) (diff)

comment:32 SergeyBiryukov22 months ago

To summarize, 21324.8.diff fixes:

lessbloat22 months ago

comment:33 lessbloat22 months ago

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

comment:34 nacin22 months ago

  • Type changed from enhancement to task (blessed)

comment:35 SergeyBiryukov21 months ago

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

comment:36 SergeyBiryukov21 months ago

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

lessbloat21 months ago

comment:37 lessbloat21 months ago

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

comment:38 helenyhou21 months ago

  • Keywords needs-refresh added

comment:39 lessbloat21 months ago

21324.11.diff is an update of 21324.10.diff

lessbloat21 months ago

comment:40 helenyhou21 months ago

  • Keywords needs-refresh removed

comment:41 follow-up: SergeyBiryukov21 months ago

Tested 21324.11.diff, looks good to me.

comment:42 in reply to: ↑ 41 grahamarmfield21 months ago

Replying to SergeyBiryukov:

Tested 21324.11.diff, looks good to me.

Yes this is looking much better.

comment:43 follow-up: azaozz21 months ago

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?

comment:44 follow-up: helenyhou21 months ago

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.

comment:45 in reply to: ↑ 44 ; follow-up: grahamarmfield21 months ago

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.

lessbloat21 months ago

comment:46 lessbloat21 months ago

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
Last edited 21 months ago by lessbloat (previous) (diff)

lessbloat21 months ago

comment:47 in reply to: ↑ 43 lessbloat21 months ago

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

Last edited 21 months ago by lessbloat (previous) (diff)

comment:48 in reply to: ↑ 45 helenyhou21 months ago

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.

lessbloat21 months ago

comment:49 follow-up: lessbloat21 months ago

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.

Last edited 21 months ago by lessbloat (previous) (diff)

comment:50 in reply to: ↑ 49 azaozz21 months ago

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.

Last edited 21 months ago by azaozz (previous) (diff)

comment:51 nacin21 months ago

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?

comment:52 azaozz21 months ago

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.

comment:53 lessbloat21 months ago

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.

Last edited 21 months ago by lessbloat (previous) (diff)

comment:54 follow-ups: helenyhou21 months ago

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.

comment:55 in reply to: ↑ 54 ; follow-up: lessbloat21 months ago

Replying to helenyhou:

thought browsers already had their own special focus styling there

Not chrome unfortunately.

comment:56 in reply to: ↑ 55 ; follow-up: lessbloat21 months ago

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

comment:57 in reply to: ↑ 54 rianrietveld21 months ago

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.

comment:58 in reply to: ↑ 56 helenyhou21 months ago

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.

comment:59 nacin21 months ago

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

lessbloat21 months ago

comment:60 lessbloat21 months ago

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.

comment:61 azaozz21 months ago

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

In [22268]:

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

Note: See TracTickets for help on using tickets.