Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update secondary button appearance #64744

Open
jameskoster opened this issue Aug 23, 2024 · 9 comments
Open

Update secondary button appearance #64744

jameskoster opened this issue Aug 23, 2024 · 9 comments
Labels
Design System Issues related to the system of combining components according to best practices. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. Needs Design Needs design efforts. [Package] Components /packages/components [Type] Enhancement A suggestion for improvement.

Comments

@jameskoster
Copy link
Contributor

jameskoster commented Aug 23, 2024

This issue came out of the discussion in #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 #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 jameskoster added [Type] Enhancement A suggestion for improvement. Needs Design Needs design efforts. [Package] Components /packages/components labels Aug 23, 2024
@jameskoster
Copy link
Contributor Author

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
Copy link
Contributor Author

jameskoster commented Sep 19, 2024

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.

@jasmussen
Copy link
Contributor

@WordPress/gutenberg-design

@jasmussen jasmussen added the Design System Issues related to the system of combining components according to best practices. label Sep 24, 2024
@auareyou auareyou moved this to Inbox 📥 in Design systems — Backlog Oct 7, 2024
@joedolson
Copy link
Contributor

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?

@jameskoster
Copy link
Contributor Author

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.

@jasmussen
Copy link
Contributor

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.

@jameskoster
Copy link
Contributor Author

The gradient/shadow are mainly to further distinguish secondary buttons from inputs for folks with color blindness, as mentioned in #64744 (comment).

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

@jasmussen
Copy link
Contributor

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.

@joedolson
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design System Issues related to the system of combining components according to best practices. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. Needs Design Needs design efforts. [Package] Components /packages/components [Type] Enhancement A suggestion for improvement.
Projects
Status: No status
Status: 🔦 Needs triage
Development

No branches or pull requests

3 participants