The design of the focus outline on buttons/elements could be improved

[michaelarestad]

Currently, the focus styles for buttons and many elements use a gradient box shadow that can be pretty hard to spot in some instances including the primary button styles.

I'd like to propose something more like what we use on WordPress.com:

CC @mor10

[afercia]

I'm all for improvements to the focus style, by the way I'd suggest to consider the focus style in real use scenarios, for example when buttons are close to other form elements, the focus style should be consistent. See what was done on #32915. Screenshot before and after the changes from #32915:

[michaelarestad]

I totally agree. I want to make sure these focus styles are pretty dang consistent across the board. We might even have to work on links as well.

[afercia]

Replying to michaelarestad:

We might even have to work on links as well.

+1 Yep, focus styles should probably be as similar as possible everywhere.

[mor10]

This looks way cleaner to me. When the button is blue, I'm wondering if there is enough contrast between the button itself and the outline. Might want to create a stronger difference, either by making the focus state a dotted/dashed line, or by changing the outline color to be more distinctly different.

I may be overthinking this.

[michaelarestad]

@mor10 Maybe. The size difference in overall appearance works pretty well even though the colors are similar. We'll see what we can do.

[mor10]

Looking at Twitter, I noticed that they have added a 2px space between the button and the outline to clearly separate the focus state indicator from the button itself. This might be a solution here as well: Provide some whitespace to show this is a line drawn around the element to indicate it is currently in focus.

Easiest place to see it is in the "People to follow" area. I'll upload some images later.

[michaelarestad]

@mor10 Good find. Might make sense just for the primary buttons. Twitter mostly only uses it on the blue buttons. Gallery of uses: ​https://cloudup.com/ckMCQgaDLaw

[kellychoffman]

With a white border:

    box-shadow: 0 0 0 .75px #fff, 0 0 0 2.5px #33b3db;

[michaelarestad]

I added an initial quick patch to mess with a non-gradient style. @kellychoffman I tried yours, but it was doing something funky on my external monitor maybe because of the half pixel. Also, we'll need to account for the 3D effect of the bottom (the extra 1px bottom shadow). Will try again in a V2 because I like the idea of the gap for the primary button.

I did maybe get a little overreaching with the focus style on links by adding a border radius. There's another fancy trick I want to try on links, but not quite yet.

Results of the first patch:

[adamsoucie]

It works great except for the primary buttons. The contrast between the primary button background color and the border is really low (1.91). We'll need some kind of alternate color so that it is clear there is a :focus being placed on the primary button. Otherwise, a great step forward!

Contrast score: ​http://snook.ca/technical/colour_contrast/colour.html#fg=008EC0,bg=5EC7E3

[kellychoffman]

@michaelarestad Right, the half pixel isn't necessary. A full pixel gap would probably make more sense anyways.

The contrast between the primary button background color and the border is really low.

This could be improved using the (white) pixel gap.

[michaelarestad]

@kellychoffman I agree. I just took another stab at it. I added the white gap to just the primary button and kept the shadows from the previous patch elsewhere. The box shadow is nasty, but works. The alternative would be to switch to using a border for the shadows and such which is a bit nastier.

It should look like this:

[michaelarestad]

The latest patch, 34904.3.diff​, has a simpler box shadow (never drink while box shadowing) than what I cam up with last time. I did, however bump the size of the shadow on the primary button slightly. It now has a single pixel white border and a 3 pixel blue border for a combined 4 pixels total.

It should look like this:

[afercia]

Related: #34957.

[kellychoffman]

It now has a single pixel white border and a 3 pixel blue border for a combined 4 pixels total.

Do you think 3 pixels is too much? What about only 2?

[paaljoachim]

I just want to say that outlining is an subtile effect meaning having a white border and then the blue creates a double effect white and blue. I think that is too much as it goes from subtile over to its own effect which I believe is too strong and takes too much visual space. Perhaps less pixels will help. I think posting some pixels variations can help as well.

I went looking for the pattern library as I would like to test this out but can not find it online. Where can I get a hold of the pattern library?

[afercia]

Moving to future release as it is something that should be done and there are some initial proposals here. Hoping there will be some more traction in the next releases.

[afercia]

Noting that Gutenberg just implemented a new focus style for the buttons, which is better for accessibility and design-approved. See ​https://github.com/WordPress/gutenberg/pull/15544

Would be great to use the same style in core as well, for better accessibility and consistency.

[afercia]

Gutenberg primary button focus style

[afercia]

Gutenberg secondary button focus style

[truchot]

As I do in Gutenberg, I try to fix button focusing color contrast.
It seems screen options button focus are altered it's not yet perfect…

[kjellr]

Thanks, @truchot. This is a great start. I added an updated version (34904.5.diff) that adds a couple missing buttons, and also tries this out on form fields for consistency:

I'm not sure if we'd want the state for those to be exactly this, or if we'd want to use the slightly different state from Gutenberg:

(Whatever we choose, I figure we should make the treatments consistent here and in Gutenberg)

[truchot]

Great ! It works well.
Maybe input radio and checkbox don't need 1px spacing like secondary button proposed ​here

[afercia]

Worth noting there are other pending tickets for the various checkboxes, radio buttons, select, and inputs. From the oldest to the latest one:

Color contrast: checkboxes and radio buttons
https://core.trac.wordpress.org/ticket/35596

Color contrast: input fields, textareas, select elements etc.
https://core.trac.wordpress.org/ticket/44606

Redesign input fields, checkboxes and other form components for contrast and consistency
https://core.trac.wordpress.org/ticket/44749

Definitely in favor of improving contrast for the form fields but I'd recommend to keep things separated and dedicate this ticket only to the buttons. Any help to make the above pending tickets move on is greatly welcome :)

[Joen]

mockup

[Joen]

☝️

Added a mockup from a related block editor ticket (​https://github.com/WordPress/gutenberg/issues/15432#issuecomment-489536288), worth throwing into the mix for consideration. The key design constraint that inspired the mockup was a reliance on borders instead of drop shadows, both to create consistency between input styles, dropdown widgets and button styles, but to be able to allow the same high contrast focus style for all of them.

Worth also noting that drop shadows alone are removed in Windows high contrast mode, so a focus style made up of only a drop shadow won't show up there. We can hack around that — show a transparent outline, it will be made opaque in that mode — but it would be nice to simplify things and have the same bordered focus style across modes.

[melchoyce]

#47151 was marked as a duplicate.

[afercia]

Adding the wpcampus-report keyword because #47151 (ticket from the WPCampus report) was closed in favor of this ticket.

[melchoyce]

Let's implement @Joen's mockups for 5.3. We'll need someone to write a patch that covers all buttons in wp-admin.

[melchoyce]

Oops, Trac overlap. Re-adding wpcampus-report.

[kjellr]

I've just added 34904.6.diff​, which includes the buttons from @joen's mockup above. Those were missing active and disabled states, so I've approximated those.

(You can try those live on CodePen: ​https://codepen.io/kjellr/full/bGbrqyq)

Here are some screenshots with those buttons in the UI:

... and here are the focus states:

In general, this seems positive to me. My hesitancy is around the default buttons — having them appear on a white background gives them an "outline-only" sort of appearance if the end up on a white background (like in Gutenberg), and I wonder if we should pull them forward visually a little more than that?

Also noted above, there area some other tickets in the works. We should consider how new treatments here align to the work being done in #47153 for example.

[kjellr]

As noted, this issue is deeply related to a couple other tickets. The design team is discussing these holistically over here:
​https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/

Feel free to weigh in there if anyone else has thoughts. Once we have alignment there, we'll bring any related design changes back into this ticket. 👍

[kjellr]

Just added 34904.7.diff​, which includes the button styles in the followup iteration described here:

​https://make.wordpress.org/design/2019/09/06/discussion-higher-contrast-form-fields-and-buttons/#comment-25971

The colors use:

• #fff text on a #007cba background for the primary buttons (Contrast ratio 4.57:1)
• #555 text on a #f1f1f1 background for the secondary buttons (Contrast ratio 6.6:1)

Screenshots:

[audrasjb]

fix errors on 34904.7.diff: line 258 and caps on hex values

[audrasjb]

Thanks for the refresh @kjellr ❤
In 34904.8.diff I fixed some small errors:

• double semi-colon ;;
• caps on hexadecimal value

Otherwise, all is looking good to me. Thanks again, you rock :)

[audrasjb]

fix errors on 34904.7.diff: line 258 and caps on hex values

[audrasjb]

34904.9.diff is the good patch, sorry I uploaded it twice :s

[karmatosed]

From design perspective looks great to me so adding a +1 for feedback. Thanks for all your work everyone on this. I have tested it so removing testing keyword.

[audrasjb]

Keyboard navigation example - Works fine!

[audrasjb]

Keyboard navigation example - Works fine!

[audrasjb]

Keyboard navigation example - Works fine!

[audrasjb]

34904.9.diff is looking great on my side too (see screenshots).
Maybe there is some room for disabled state color contrast enhancements in a next commit but it's a really great enhancement as it :)

[kjellr]

Great, thanks for testing! We also need to make sure this works alright with alternate color schemes. If nobody else gets there first, I'll take a look later today.

Also, some elements (like standard links) still have the "glow" effect on focus:

This ticket seems broad enough to refresh those too — should we replace those with the solid line used in Gutenberg?:

[karmatosed]

I noted this when testing within Slack, so changing the flow effect seems good to me.

[afercia]

Discussed during today's accessibility bug-scrub. This ticket is related to other tickets marked as "bug" aiming to improve contrast and focus indication. It's best to change it from "enhancement" to "bug" so that all these related tickets can be handled together.

[anevins]

Sorry commented on wrong ticket

[kjellr]

Replying to kjellr:

Also, some elements (like standard links) still have the "glow" effect on focus:

This ticket seems broad enough to refresh those too — should we replace those with the solid line used in Gutenberg?:

I've added 34904.10.diff​, which removes that glow hover state wherever I could find it. After some sleuthing, I actually believe that solid color hover state in Gutenberg actually only applies to buttons, so I'm not even sure it's supposed to be applied to buttons that look like links in the first place.

Instead of adopting that, I've brought in the dotted line border that Gutenberg applies to most other focusable, non-button elements:

Happy to reassess that treatment if we decide, but I think it works pretty well, and helps align with what you'd usually see in Gutenberg.

I'm going to dig into the alternate color scheme buttons next and make sure those work nicely.

[kjellr]

Uploaded a fresh version: 34904.11.diff​

This one makes sure the alternate color schemes follow these new button styles focus borders:

A note about that: Not all of the alternate button styles pass contrast tests. But they didn't before, so I think we're fine? Seems like a separate issue, and one that should be considered separately.

This also fixes an issue where the active toggle button wasn't very noticeable. Should be a bit better now:

This patch is getting pretty large, but I think it covers everything it needs to.

The buttons.css file header suggests to edit editor.css as well. I see that file contains some TinyMCE buttons, but I can't find any of them in use, so I'm hesitant to make any changes. I checked the classic editor and it seems to be fine as is. If anyone knows where those are, and can fix them, that would be excellent. Otherwise, I think this is just ready for some solid, thorough testing.

That's probably my last patch in this thread for the day, so feel free to update and build on the patch if anyone finds bugs! Thanks.

[karmatosed]

@kjellr in testing this it feels as good as I think we can get for beta 1. I would note there needs to be some thorough stress testing of this during beta.

[audrasjb]

I tested 34904.11.diff and the patch is looking fine to me as it.
I'd say go for a +1 to commit it and to iterate during 5.3's beta cycle.

I'm going to write a dev-note about those changes once it get committed.

[kjellr]

Thanks for the reviews, folks! Seems like this is probably ready for wider testing.

[audrasjb]

Ready for commit for 5.3 beta 1.

Worth noting it should be committed alongside #47477 darker alternative patch.

[afercia]

In 46241:

Accessibility: Improve and modernize user interface controls for better contrast. First part: buttons and links.

• Introduces new styles for the buttons, with better contrast for borders and better focus style.
• Introduces a new focus style for links.
• The new styles improve consistency with the ones used in the new Block Editor (Gutenberg).

Props michaelarestad, truchot, mor10, kellychoffman, adamsoucie, paaljoachim, Joen, kjellr, melchoyce, karmatosed, audrasjb, afercia.
Fixes #34904.

[youknowriad]

Hi Friends and thanks for your work here.

I discovered these new designs recently and I have some feedback to share.

• In some screens like the post list, the fact that the default buttons have the same background as the regular screen background make them look like disabled inputs for me, it's very hard to understand that these are in fact buttons.

• In Gutenberg, we didn't try new button designs to stay consistent with Core, so I was really surprised when I saw these buttons commited to Core without trying to bring consistency in Gutenberg. What's the plan for that?

• With the current button size and without any borders or elevation, the primary buttons in the settings screen look very weird to me. They feel a bit "disconnected" from the design of the rest of the page.

[kjellr]

Hey @youknowriad! We definitely appreciate the feedback. 🙂

Regarding the specific button styles in general: We're hoping to keep iterating, so perspective like that is super helpful. The goal is to keep iterating throughout the beta period, but given all the bugs that need to be sorted out in general, I'm not sure whether or not we'll be able to make substantial changes during this period.

Regarding Gutenberg: these updates will need to be ported over there. I see that @mapk and @karmatosed have begun logging some tickets for those:

​https://github.com/WordPress/gutenberg/issues/17585
​https://github.com/WordPress/gutenberg/issues/17592
​https://github.com/WordPress/gutenberg/issues/17593
... etc.

Given the timeline, making these changes there too is admittedly going to be rough, so any help would be appreciated.

[afercia]

Thanks @youknowriad et all for your feedback. As @kjellr mentioned, the primary goal of having these CSS changes in Beta 1 is to make them exposed to a larger community, get feedback, and keep iterating. So any feedback is very welcome.

[drw158]

I haven't been watching this too closely so forgive me if this has been tried before. Maybe this mockup I've been working on can help? I've been experimenting with some ideas to try and bring Gutenberg UI styles to the rest of WP Admin. I think the secondary buttons look less disabled, so perhaps it's worth trying.

[youknowriad]

@drw158 Very nice proposal, I'd love to see a patch for that one to at least test how it feels in several situations/states (focused, disabled...).

[kjellr]

Just added a quick patch in case anyone wants to try that out: 34904--blue-secondary-buttons.diff​. I had to adjust the colors just a little bit to get the hover/focus styles working nicely, but otherwise it's really similar to @drw158's mockup.

Screenshots:

[kjellr]

Also! I noticed @drw158 had the "Add New" button as a primary button. I kind of like that too, but I didn't make that change in the patch. Many of the pages that have those "Add New" buttons have no primary buttons currently.

Current:

Primary Button version:

[melchoyce]

I dig it — it brings some nice contrast back. I think we should consider merging it into trunk and sitting with it for a couple days.

FYI, some conversation around the use of primary/secondary buttons in page headers in #41986.

[kjellr]

Here's a quick codepen in case anyone wants to quickly try out adjustments to the different states:

​https://codepen.io/kjellr/pen/VwZNWjq

Edit: Noticed a small active state color bug in the patch, so re-uploaded. 👍

[youknowriad]

Reopening to consider the last patch.

Btw, it looks great for me. Curious to hear other thoughts.

[desrosj]

Just wanted to attach customizer-buttons.png​. I had seen it mentioned in Slack, but not sure it had been added to a ticket.

The buttons are a different height than the input fields in the Customizer.

[desrosj]

Just found #48131. Disregard the last comment.

I did forget to mention, though, that the gear icon in the publish button is also not vertically centered.

[kjellr]

34904--blue-secondary-buttons.2.diff​ fixes some bugs around the display of icons in buttons.

Before

After

[afercia]

For what is worth, I like the idea of the blue buttons as in WordPress the blue traditionally identifies interactive elements. Thanks @drw158 !

Should we make this ticket a "task" so it can run during Beta and use some iterations? #47153, #47477, #47498, and #48101 are already reopened as tasks.

[talldanwp]

I've added a patch that iterates on @kjellr's from yesterday, applying a few fixes to the Add New button (.page-title-action).

That button previously had only a 2px border radius and was a couple of pixels shorter than other buttons. It should now be the same size (though I don't quite know why I had to use line-height: 26px instead of line-height: 28px. Perhaps because it's a link?)

[youknowriad]

Fixed the vertical centering of the small and large buttons by using the same top and bottom padding.

[audrasjb]

As seen during the accessibility meeting, the best option would be to use @kjellr proposal of solid 2px border.
Colors:

• white border for admin menu items
• blue border everywhere else

See screenshot below:

[audrasjb]

Solid outline

[youknowriad]

I think there's still work to do but what's on the last patch here, is better that what's currently in trunk. I'm addinig the "commit" keyword. Commiting these updates will allow us to get a full picture about how all the fixes (buttons, inputs, dropdowns) fit all together and we can keep iterating on it.

[afercia]

Noting another part of the fixes necessary to get a full picture will happen on #47477. Other fixes also in #47153, #47498, #48131, and if needed on #48101.

[afercia]

Looking at the latest patches, worth noting this ticket is only about colors, contrast, and focus style. Changes to the elements size should be omitted from this ticket and addressed in #47477 where a patch is already in the works.

Thanks for the patches :) but given the large set of CSS changes it's best to keep things well in order, address specific issues on specific tickets, and keep track of all the committed changes in their specific order.

Will commit last patch from @kjellr.

[afercia]

In 46344:

Accessibility: Improve and modernize user interface controls: Make the secondary buttons border blue.

Props drw158, youknowriad, kjellr, melchoyce, talldanwp, audrasjb.
See #34904.

[talldanwp]

I've made a Gutenberg PR to replicate the button styling—GB17645.

[Joen]

Patch to remove 1px pixel-shift and add a transition to borders to match form fields.

[Joen]

Just attached a patch that does two things:

1. It removes the 1px pixel shift on button :active. Given the flat style of the new buttons, this jog is visually incompatible. Additionally it hasn't even been on the buttons in Gutenberg, so it adds consistency.

2. It adds a 0.1 second transition to the focus outline. This transition is already applied to the form fields, so this is another bit of consistency.

In ​https://cloudup.com/ckHvhDJjyNI there are some before and after GIFs to see the difference.

In terms of consistency and contrast, this trac ticket is a welcome step forward. I hope we can take additional steps in subsequent versions, inspired by this change. Many of these have already been mentioned, so take this as an endorsement for additional enhancements, such as:

• Bigger buttons, consistent paddings that are perhaps harmonized to a standard grid.
• More consistent font size across all buttons, perhaps bump to 14px.
• Perhaps add some vibrancy to the blue color, by pushing it towards the purple side of the spectrun.

Not suggesting buttons be purple, but one of the curious properties of the purple side of the spectrum (as opposed to the green side, which the WordPress brand color is leaning towards at the moment), is that contrast to white overlay text skyrockets: ​https://cloudup.com/cJXNAsoKWyM

In other words, even very subtle shift towards ultramarine/purple can add a ton of color vibrancy without reducing brightness.

[afercia]

@Joen thanks for the patch!

Removing the active state shift makes totally sense.

Regarding the focus transition, in core things are a bit different. Some elements have a transition, other elements don't. When tabbing through (or clicking on) adjacent elements, seeing the inconsistency produced by the presence or lack of transition is not that great and feels sluggish. See conversation on #47153 starting from https://core.trac.wordpress.org/ticket/47153#comment:50

Also, I'd tend to think that at the very least the transition should obey the prefers-reduced-motion setting.

For these reasons in https://core.trac.wordpress.org/attachment/ticket/47477/47477.7.diff I'm removing the transition entirely for now and I'd suggest to re-evaluate later. If no objections. I'd commit only the removal of the active transition.

Bigger buttons, consistent paddings that are perhaps harmonized to a standard grid.

I'd totally second this. Having now spent some time on the core CSS I refreshed my memory on all the various core inconsistencies :) Setting and harmonizing new default buttons and input field sizes is something that need to happen sooner or later. I'd start by defining simple values for the normal size heights for example 30px on desktop / 40px on mobile and then elaborate a scale for small and large starting from there. #47477 is the ticket related to sizes. However, this would need some iterations and in depth testing, not sure it can be done now.

[Joen]

👍

Worth submitting a Gutenberg PR to make it consistent between the two. I look forward to the day when we can share components and work on individual components ✨

for example 30px on desktop / 40px on

I would recommend a base8 or base12 compatible number, as this will make ongoing grid efforts simpler. Could be 24, 32, 36 and sure, 40.

[afercia]

I would recommend a base8 or base12 compatible number, as this will make ongoing grid efforts simpler. Could be 24, 32, 36 and sure, 40.

Totally in favor of a "grid base". Anything that is not like the core current (bit random) rendered values e.g. 21px, 25px, 29px 😬 would be great.

[Joen]

👍

Small note on the transition thing, it's worth noting that the transition is currently applied _also_ to form fields. So whatever efforts we should do to include the reduce motion preference should apply to form field and button focus styles both.

[afercia]

In 46350:

Accessibility: Improve and modernize user interface controls: Remove the CSS transform 1 pixel shift from the buttons active state.

Props Joen.
See #34904.

[afercia]

In a few places, the new focus style removed the "rounded focus style". This is mainly used on toggle icons and similar controls. Not sure this has been discussed and I'd rather keep the previous style.

See attached screenshot: old style and new dotted line style (less visible).

[afercia]

34904.12.diff​ restores the toggles "rounded focus style" using the new blue style. See for example all the post-boxes and meta-boxes. See the Menus and Widgets accordions (also in the customizer).

I'd appreciate design feedback on this change :)

[kjellr]

Replying to afercia:

34904.12.diff​ restores the toggles "rounded focus style" using the new blue style. See for example all the post-boxes and meta-boxes. See the Menus and Widgets accordions (also in the customizer).

I'd appreciate design feedback on this change :)

Looks good to me. Thanks, @afercia!

[kjellr]

Replying to audrasjb:

As seen during the accessibility meeting, the best option would be to use @kjellr proposal of solid 2px border.
Colors:

• white border for admin menu items
• blue border everywhere else

See screenshot below:

I've added 34904-link-and-adminbar-focus-borders.diff​, which makes this update.

New link focus states:

New admin menu focus states:

---

My main concern on these is that some of these borders look a bit clumsy and oddly shaped in Chrome. Chrome also decides to show these every time you click, so they're pretty obvious there:

[afercia]

Spotted a new thing :) The permalink structure buttons lack their "pressed" state. That was the :active / .active style. I think a "pressed / active" style needs to be restored, doesn't necessarily have to be the previous one.

See attached screenshot: before and after.

[audrasjb]

Fixes oddly shaped focus styles on WP-Admin dashboard (see @kjellr comment #103)

[afercia]

Reminder: for the admin menu there's #28599. Old, long to read, ticket: recommend to directly jump to the latest comments.

On that ticket, a solid outline for the admin menu received a non positive design feedback. At some point the identified solution was a left "border" implemented with box-shadow and currentColor. Worth noting currentColor has the advantage of automatically using the color from the active color scheme. I'd be inclined to not rush changes for the admin menu and consider what the best option is. Not opposed to postpone and work on #28599 during the WP 5.4 cycle.

For normal links: personally, I'd keep using a box-shadow. It is true that 34904.13.diff​ appears to solve the "odd shape" issue but we're not sure it addresses all the occurrences. After all, using outline instead of box-shadow gives us only the advantage of a slight simplification of the CSS. Instead, box-shadow is more reliable as it is used since years: we know it works across all the UI. For Windows High Contrast Mode the additional transparent outline just works.

I'd like to propose to discuss this during ​today's accessibility bug scrub on Slack, everybody's welcome.

[kjellr]

Reminder: for the admin menu there's #28599. Old, long to read, ticket: recommend to directly jump to the latest comments.

On that ticket, a solid outline for the admin menu received a non positive design feedback. At some point the identified solution was a left "border" implemented with box-shadow and currentColor. Worth noting currentColor has the advantage of automatically using the color from the active color scheme. I'd be inclined to not rush changes for the admin menu and consider what the best option is. Not opposed to postpone and work on #28599 during the WP 5.4 cycle.

Thanks for the link — I'd forgotten about that ticket. As long as we have a visible focus state in here in general, I'd be happy to postpone major changes and work on them in the context of that ticket instead.

For normal links: personally, I'd keep using a box-shadow. It is true that 34904.13.diff​ appears to solve the "odd shape" issue but we're not sure it addresses all the occurrences. After all, using outline instead of box-shadow gives us only the advantage of a slight simplification of the CSS. Instead, box-shadow is more reliable as it is used since years: we know it works across all the UI. For Windows High Contrast Mode the additional transparent outline just works.

Using box-shadow (along with the transparent outline fallback for high-contrast mode) sounds fine to me too. I'm not sure I have time to rewrite that patch at the moment, but if someone else is up for taking it on, that would be excellent.

[kjellr]

The permalink structure buttons lack their "pressed" state. That was the :active / .active style. I think a "pressed / active" style needs to be restored, doesn't necessarily have to be the previous one.

I've added 34904-permalink-buttons.diff​, which borrows the button group's active state for those instead of the standard active state:

Before

After

[mapk]

I wanted to note a couple bugs I'm noticing.

1. Border radii are all over the place.

• Input fields have a border-radius of 4px.
• The "Add New" default button has a border-radius of 2px.
• The other default buttons have a border-radius of 3px.

2. The default button height does not match the input field height.

[afercia]

@mapks thanks for your feedback.

Noting that this ticket is about focus style and contrast :) #47477 is the ticket related to sizes. Saying this just to try to keep things in order.

On your points: whether or not all these changes will stay or will be postponed to next releases, here's some notes that can be good for present or future work:

1 Border radii are all over the place.

I noticed that as well, though the "Add New" button is a pre-existing issue and does have a border-radius of 2px on all previous versions against the 3px of the core-ui buttons. I vaguely remember when it was implemented that was a design choice. I may be wrong, would need some software archeology on Trac.

Can certainly be improved but needs a design decision. I'd tend to think deciding if the radius must be 2, 3, or 4 pixels would need just a few minutes.

2 The default button height does not match the input field height.

On 5.2 and all previous versions:

• The default input field height is the one in the settings pages. About 25px on macOS Chrome. Can vary across operating systems and browsers.
• Some admin pages (e.g. the posts page) use a different input/select height to match with buttons so currently there's not a real "standard"
• On 5.2 and previous: normal buttons have a height of 28px plus a bottom box-shadow that makes them look 1 pixel taller so even in this case form controls and buttons aren't visually aligned:

• On 5.2 and previous: on mobile the small, normal, and large button sizes become all 31px (with various exceptions). Form controls change to a wide range of different heights with no apparent sense.

With the new CSS:

• form controls heights are way more standardized and have way less exceptions
• just needs a decision on the default height of all controls: inputs, selects, buttons. To recap, on desktop - normal size:
  • buttons were not changed, they're still 28px
  • the inputs are now 30px
  • the new select is 28px

We could make it all 28px or all 30px. And on mobile all 40px.

However, @Joen made a very good point on establishing a grid base. I'd totally second that and I'd lean towards a base8. Thus, on desktop the normal size would be 32px and on mobile 40px. This needs a design decision.

Given all heights are now much more standardized, these adjustments would be a matter of very few changes in the CSS.

Lastly: I'd like to note this ticket is not about pixel perfection :)

The main goal here is to remove all the fixed heights and allow all the UI controls to scale with zoom text. Otherwise, text within controls is cut off or overflows, making the controls barely usable.

See for example what happens in Firefox with "Zoom Only Text":

[afercia]

Re: color schemes:

A note about that: Not all of the alternate button styles pass contrast tests. But they didn't before, so I think we're fine? Seems like a separate issue, and one that should be considered separately.

Correct; historically, only the default color scheme aims to have a WCAG compliant contrast ratio. All the other color schemes have always been considered options and they don't meet (never met) the contrast requirement.

Re: buttons active state:

I've added 34904-permalink-buttons.diff​, which borrows the button group's active state for those instead of the standard active state:

The current active state is barely noticeable as it changes only the border color. It should be improved and also implemented for all the buttons, not only the permalink structure ones. Trying a patch now.

[afercia]

34904.14.diff​ tries to improve the active state.

More accurately, the :active browsers state and the .active class should now be distinguished:

• the former is unchanged and it's used by browsers while clicking a button
• the latter is a CSS class meant to be used for buttons that need to look "pressed" as, for example, buttons that represent a selected setting

See in the attached screenshots: permalink buttons and alignment buttons in the media modal (button group).

The "pressed" style is basically the same one used in WP 5.2 the only change is the box-shadow changed from gray to blue because the buttons have blue borders and text.

[afercia]

34904.15.diff​ improves 34904.14.diff​ to address the .active class for the color schemes.

[afercia]

In 46423:

Accessibility: Improve and modernize user interface controls: Improve the buttons active CSS class.

• improves the buttons .active CSS class for buttons that need to be styled as "pressed"
• update the alternate color schemes .active CSS class accordingly
• improves a few icons colors in the alternate color schemes

See #34904.

[afercia]

Re: links focus style:

Thanks for the link — I'd forgotten about that ticket. As long as we have a visible focus state in here in general, I'd be happy to postpone major changes and work on them in the context of that ticket instead.
Using box-shadow (along with the transparent outline fallback for high-contrast mode) sounds fine to me too. I'm not sure I have time to rewrite that patch at the moment, but if someone else is up for taking it on, that would be excellent.

34904.16.diff​ restores the previous focus style for links, based on box-shadow and removes the new outline: 1px dotted #555d66;. A new focus style for links needs more exploration as the new dotted outline is noticeably lighter than the previous style thus not quite ready to guarantee a good indication of focus.

Partially reverts [46241] and [46293] (see #47153).

[afercia]

In 46425:

Accessibility: Improve and modernize user interface controls: Revert the new links focus style.

Thew new dotted outline for the links focus style introduced in [46241] doesn't appear to be ready to guarantee a good indication of focus.
It was agreed to restore the previous links focus style and postpone exploration for a new style to the next release cycle.
Partially reverts [46241] and [46293].

See #34904, #47153.

[azaozz]

Re: process, this is a low-priority enhancement that shouldn't have been committed during or right before beta.

Changes to the buttons styling affect a lot of other (old) CSS, potentially breaking many many plugins. This type of low-priority tweaks should happen well before beta so they can be tested and refined in time.

[afercia]

Re: process, this is a low-priority enhancement that shouldn't have been committed during or right before beta.

I'm sorry but insufficient contrast and poor focus indication are a serious accessibility bug. Worth also noting #47151 was closed in favor of this ticket. #47151 comes from the WPCampus accessibility report on Gutenberg and outlined the contrast issue on buttons.

Being a bug, it can be committed at any time during Beta period.

Changes to the buttons styling affect a lot of other (old) CSS, potentially breaking many many plugins.

I'd appreciate concrete examples of breakages regarding the buttons styling. I haven't seen any so far. Also, plugins shouldn't alter the default styling buttons and if they do, they're just "doing it wrong".

Worth also noting that the changes to the focus style improve accessibility and also bring in consistency with the styles used in Gutenberg. Previously, there were two complete different patterns in WordPress: the Gutenberg one and the legacy admin one. I'm not sure that can be considered a good UI. Harmonization of the styles in the admin needs to happen anyways sooner or later.

Considering this is an accessibility bug, I'd like to change the ticket to "bug" (#47151 was marked as bug). Worth also noting this ticket was changed to "blessed task" by the Editor Tech focus lead for this release cycle @youknowriad and I couldn't agree more :)

[afercia]

Discussed during today's accessibility bug-scrub on Slack and agreed to change this ticket back to "task (blessed)" as it was publicly discussed in the Dev Chat last week, and an agreement was reached. With the blessing of @davidb as Triage PM for this release cycle.

[azaozz]

Replying to afercia:

There is no point in changing the type of this ticket. The fact is that it started as a low-priority bug fix but later the scope was changed and it became an enhancement.

Also, there is no such thing as "blessing" a ticket by "anybody". The type of "Task (blessed)" is an override meant for larger new features (which are always "enhancements" by their nature) where the team working on them couldn't meet the deadlines and complete them before beta. It generally means that the code committed before beta is buggy and needs additional testing and fixes. This is not the case here.

I'm thinking we should remove this type or at least the "blessed" part as it is being misunderstood and misused in all kinds of cases.

[audrasjb]

RC1 is approaching. Closing this ticket as fixed for milestone 5.3.

[desrosj]

Dev note: ​https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

[afercia]

In 46575:

Accessibility: Restore the primary buttons original background color for alternate color schemes after [46241].

Props david.binda, audrasjb, azaozz.
See #34904.
Fixes #48396.