gutenberg icon indicating copy to clipboard operation
gutenberg copied to clipboard

Update secondary button appearance

Open jameskoster opened this issue 1 year ago • 9 comments

This issue came out of the discussion in https://github.com/WordPress/gutenberg/issues/63856.

There are a couple of details about the secondary button appearance it could be good to address.

Lack of clear hover style

Users with low vision might have difficulty distinguishing buttons from static content. A distinct hover style helps these users identify buttons as interactive elements.

Relatedly, a clear hover style will be critical if the button cursor ever changes from pointer to default, as discussed in https://github.com/WordPress/gutenberg/issues/63856. There's an interesting article on this subject here, the upshot being:

  • pointer is for links. Note that default browser styles do not apply it to buttons, radios, inputs, or any other interactive elements.
  • A well designed button (with clear hover state) should not require a cursor change to indicate interactivity.

There are also cursor-less environments to keep in mind like Spatial Computing, or devices that use different cursor sets, e.g. an iPad with Magic Keyboard:

Components  Button - Secondary ⋅ Storybook

Visual overlap with inputs

Text inputs and secondary buttons have a very similar footprint, visual weight, and general style treatment. As an example here's a screenshot from the Block Inspector:

example

If you squint, or find yourself in certain lighting conditions, it's kind of hard to tell the input / button apart. This is even more pronounced for sufferers of monochromatic color blindness (simulator):

mono

Coupled with the lack of clear hover style this makes for a situationally poor UX.

Additional considerations

It's important to acknowledge that any new design should retain the a11y features of the current design. Specifically:

  • Contrast ratio: The button text and any icons should have a contrast ratio of at least 4.5:1 with the button background.
  • Clarity vs Surrounding Content: Whichever detail is used to distinguish the button as an interactive element (e.g background color, border, font-weight, combination thereof) should also meet contrast requirements. For borders and backgrounds that is typically a contrast ratio of at least 3:1 against the surrounding UI. For font weight the text should differ from regular body copy.
  • Shape and Size: The button should have a clearly defined shape and size, making it easily recognizable as a button.

jameskoster avatar Aug 23 '24 12:08 jameskoster

As a starting point for discussion here's a design we might consider:

button
  • Increased font weight distinguishes from surrounding content
  • Lighter but heavier border allows for clearer hover styling
  • Subtle background on resting state helps further distinguish from inputs

Here's how this design would appear in context:

Screenshot 2024-08-23 at 13 57 57

And to users with monochromatic color blindness:

mono

jameskoster avatar Aug 23 '24 13:08 jameskoster

Noting that other style treatments like gradient backgrounds and elevation can greatly improve the distinction between buttons / inputs for users with monochromatic color blindness.

Regular appearance Monochromatic color blindness sim
Screenshot 2024-09-19 at 17 05 05 Screenshot 2024-09-19 at 17 10 46

Compared with trunk it's much clearer at a glance which elements are inputs and which are buttons.

jameskoster avatar Sep 19 '24 16:09 jameskoster

@WordPress/gutenberg-design

jasmussen avatar Sep 23 '24 08:09 jasmussen

The proposed resting state for the button looks like it has a border using #D0D8FA; though I got that from a color picker, and it could be off. However, that yields a contrast of 1.41:1 against a white background, which puts the resting state below contrast requirements under WCAG 1.4.11, which requires a contrast ratio of 3:1 against adjacent colors for user interface components. If we want to make the button easier to visually identify, that visually identifying information needs to meet this criteria.

The existing button meets that, but - as you observe - is difficult to distinguish from input styles. I definitely would like to see the button design be more distinct from input design.

Would it work if it kept the existing border, and only changed the fill?

joedolson avatar Nov 19 '24 15:11 joedolson

Would it work if it kept the existing border, and only changed the fill?

@joedolson Wouldn't the contrast of the background also need to be 3:1 against white to differentiate from inputs? I'm thinking about folks with monochromatic color blindness.

My thinking was that a combination of color, font-weight, fill (gradient), and shadow would cover all bases. See the fourth example in this codepen.

jameskoster avatar Nov 20 '24 12:11 jameskoster

I appreciate the exploration here. That said, I’m not confident in the latest direction. The use of gradients and shadows introduces visual elements that don’t align with other component visuals, and might not directly address the core issues being solved for. I do see potential in the gray fill color and font-weight changes. The text is already centered vs. left aligned, what are some other options? A corner radius change? It could be worth exploring these further in the context of the full interface—toolbar, inspector, and modals—to ensure it balances well across the system.

jasmussen avatar Nov 21 '24 08:11 jasmussen

The gradient/shadow are mainly to further distinguish secondary buttons from inputs for folks with color blindness, as mentioned in https://github.com/WordPress/gutenberg/issues/64744#issuecomment-2361438698.

But perhaps the weight change and central alignment of text is adequate? Simulation:

A subtle background (similar to the hover state for tertiary buttons) applied to the resting state could also help:

It could be worth exploring these further in the context of the full interface—toolbar, inspector, and modals—to ensure it balances well across the system.

Probably easiest to try in a PR at this point. Change considerations:

  • Increase font weight
  • Subtle background on resting state
  • Hover/active styles

Radius is another option, but could have undesirable knock-on effects (block toolbar).

jameskoster avatar Nov 22 '24 16:11 jameskoster

It's not clear to me that the gradient adds very much for people with color blindness, as it's so subtle (nowhere near contrast ratios), compared to the text being centered, which is fairly universal. Same with the background and hover states. Not that it can't work, the flat background does use existing design principles. As it is, though, exploring a font weight change seems the most basic changethat can meaningfully differentiate.

jasmussen avatar Nov 25 '24 08:11 jasmussen

The gradient would be fine for people with color blindness; the contrast ratios are about distinguish between two colors, and have nothing to do with the ability to see colors. Somebody with color blindness would be perfectly able to see that gradient. They are, however, too subtle to be significant for people with reduced contrast vision.

I do think that centered text is a strong indicator of the difference between buttons & inputs; adding a font weight change would be an additional subtle clue to help distinguish.

joedolson avatar Nov 26 '24 17:11 joedolson