Buttons: Neutral, hover, active and focus styles

[jasmussen]

Let's discuss and find a consensus on how buttons should look and behave when interacted with by mice and keyboards, and then roll this out to every element used. Much of this work is inspired by #846, #835, as well as a few slack conversations.

Let's start with an updated blueprint:

This shows and labels the elements of the editor. Focusing on buttons (and ignoring those provided by WordPress like Publish), we have these:

1. Action Buttons in the Editor Bar (and other places like Post Settings)
2. Block Control Buttons in the Quick Toolbar
3. Post Settings Toggle Button in the Editor Bar (this is essentially a version of the Action Button)

Mockup:

In the above mockup, the "Tab Focus" shows up when you tab into an item with the keyboard. The "Active + Focus" shows up when you click the item with your mouse, using the approach outlined here. You can try the behavior in this codepen: https://codepen.io/joen/pen/OmqQGR

[jasmussen]

CC: @afercia

[afercia]

For controls (buttons, links, and form elements) in the "frame" around the editor, that is toolbar, sidebar, and "meta boxes" after the editor, I'd personally prefer to see as much integration as possible with the various state styles already used by core. From an accessibility perspective, they're already tested and have a decent accessibility. From an UI/design perspective, I think the WordPress design team should be involved 🙂

For controls within the editor, I'm all for custom styles, if needed. Pairing hover and focus is often a good choice, should be evaluated on a case by case basis though. As far as I know, for now two main styling are used:

• complete inversion of color, with a very dark grey: in my opinion this is OK for accessibility because it also designs a "shape"
• 1px dark border: looks OK for a11y to me

Any feedback from other accessibility people very welcome 🙂

[mrwweb]

These are looking really nice!

One state that should probably be added to the Block Control Buttons is Toggled + :focus. Simply combining the Toggled and Focus style right now won't work. I imagine the same style might be good for Toggled + :hover too.

---

And related to toggling, I'll just throw out this article posted recently on CSS Tricks: "User Facing State". (There are some other good posts with the same recommendation, this is just the recent one I remember.)

When possible, hopefully these buttons can be styled in a way that requires semantic markup! i.e. button[disabled] instead of button.is-disabled or [not sure on browser support for this one] button[aria-pressed="true"] instead of button.is-active.

[jasmussen]

As a small update on this, I realized that the previously linked codepen with the :active:focus trick doesn't truly hide the outline that WordPress provides — it only hides it on mousedown. There's a ghost outline appearing and remaining after you've released the button, which sits there until focus is moved elsewhere.

Thankfully the fix is somewhat easy, and the on-click-outline removal is only for a few specific buttons and styles. The fix is to unstyle the custom WP focus outline that's set using box-shadow, and recreate it using outline.

https://codepen.io/joen/pen/XRLeNd?editors=1100

Edit: looks like it's more complicated than that. The focus rectangle lingers if the element is a button or other form element with a styled background or border. At the time of this writing, the implication is to either accept that the outline lingers even when clicking, or use the a element inside the IconButton component.

[afercia]

Thankfully the fix is somewhat easy

I don't think this is something that needs to be "fixed". As noted also in other issues, visual focus should always be very clear, for all users. It's not something that benefits only keyboard users.
Hiding, by any means, the visual focus would be a specific violation of the related WCAG guideline. I'd recommend everyone to carefully read:

Understanding SC 2.4.7 (Visual Focus)
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

I understand all the "visual" concerns, however WordPress aims to be an usable and accessible application. It doesn't necessarily need to "look pretty". Instead, it needs to be accessible. I'd also remind that any new code in WordPress is required to meet the WCAG guidelines at level AA.

I'd also note that I don't see a good reason to deviate from features that WordPress already implements. WordPress already provides focus styles, and it does that pretty decently. Why Gutenberg should have different rules?

[jasmussen]

To be absolutely clear, focus styles are important. We should have them. I was also perhaps premature suggesting a "fix was easy". In fact I'm still investigating.

Can you take a look at https://codepen.io/joen/pen/gRYazN and see what behavior you are seeing? I'm seeing a different lingering focus (when clicking) only on styled buttons, which very much seems like a browser bug to me. The behavior also varies from browser to browser, so looking at various implementations I'm first trying to detect what's going on.

[afercia]

@jasmussen the browsers native behavior greatly differs not only across browsers but also across platforms. I've just re-tested a native button on Windows and it's completely different compared to macOS, not a surprise I guess.

Apart from these academic considerations, the WCAG are really clear about this. Have you read what the WCAG require? Just to understand if we're on the same page.
https://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

[jasmussen]

I have read those documents, but as I'm sure you've noticed I sometimes don't understand all the nuance, which is why I'm grateful that you often help provide direction. I'm working on a PR right now, and I was going to bring this up in #accessibility some time tomorrow, so as to not exhaust you specifically.

My confusion currently stems from the different ways browsers treat this. All of these guidelines refer to keyboard focus, and suggests an outline. Combined with one of your past statements, that it's almost always best to rely on the stock implementation rather than designing your own, I've been looking at how Chrome, Firefox and Safari treat the unstyled button:

This is similar to MacOS. There's a clearly distinct visible outline when the elements receive keyboard focus. And there's a clearly distinct button press style. But there's no visible outline when the mouse clicks on the button (i.e. mouse focus).

Unless, of course you style the button, which is why I'm suggesting it's a bug.

[mrwweb]

This link may be useful but it also suggests that the fix is really convoluted [and maybe not worth pursuring?].

Button Focus Hell by Marcy Sutton

[afercia]

All of these guidelines refer to keyboard focus

This may be one of the reasons for being a bit confused. The guideline is about Visual Focus. Then, it calls it "keyboard focus" introducing some confusion. The second part of "Understanding SC 2.4.7 (Visual Focus)" clarifies that it's not just about keyboard users.

As per the native browsers behavior, in this case is really inconsistent and hard to trace. To my understanding, natively buttons are designed by the platform. Some browsers (i.e. webkit) choose to override this and make their own buttons. This differs based on the platform too. For example, this is Firefox 53 on Windows 10:
https://cloudup.com/cOqhxX9Cyop
As you can see, the focus style "lingers" also on native unstyled buttons. So what's the native behavior to preserve here? 🙂 Actually, there isn't one native behavior, there are many.

Regardless, the Guideline 2.4 and specifically Understanding SC 2.4.7 is very clear in illustrating the intent of the guideline. One of the examples there is about people with attention limitations, etc. who are not supposed to be keyboard users, no? (well they might be, but not necessarily :))

[aduth]

What is the intent of Understanding SC 2.4.7 in mentioning this as an "additional" technique:

Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus

In what way is this considered supplementary to "Sufficient Techniques"?

Maybe I'm misunderstanding the format of the document and what is implied by "Additional".

[afercia]

Button Focus Hell by Marcy Sutton

About that post, I just demonstrated with the screenshots posted on cloudup that it's based on wrong assumptions, for examples when it states:

Firefox actually gets it right for native buttons: clicking sets focus, but not the visible focus style.

that's not true on Windows.

[afercia]

What is the intent of Understanding SC 2.4.7 in mentioning this as an "additional" technique:

@aduth I guess we should ask the people who wrote that 🙂 I don't see a great difference from the "sufficient" techniques above.

[dingo-d]

I started testing gutenberg a bit, and I immediately noticed box shadow around the sidebar toggle buttons. Immediately I was annoyed because I usually don't like focus styles, but from the a11y side they are definitely a must have. But still, to me, the current focus is 'too tight' around it. We should add 2 or 3 pixels of padding around those buttons.

Without padding:

With 3px padding:

I played a bit and added a border instead of box-shadow on the focus, but I don't know if that would be clear enough from a11y standpoint, from visual standpoint I think that it looks prettier :D

These are just quick inspector changes.

[jasmussen]

Nice, I think that bottom border style could be interesting to explore. So thanks for your comment!

A few things to unpack, though:

1. We need very visible focus styles when tabbing, they need to be sufficiently contrasty too.
2. I'm still unsure whether this tab style actually needs to linger on the button when you are clicking. Unstyled buttons do not exhibit this behavior, which leads me to believe it's a bug that we could theoretically address by setting box-shadow: 0; on click, but we'd need to be sure this doesn't mess with accessibility.

The metabox buttons, absolutely agree it's very intrusive there. But we could alleviate a great deal of it by making the button itself fill the whole area of sidebar, so it doesn't appear to be "a button inside a grid", but rather that the grid itself is buttons. I.e. something like this:

[jasmussen]

Closing this in favor of #3039