0

According to the documentation here, interaction states (hover, focus, pressed etc) are represented by overlaying an additional state layer on top of the container:

The state layer is an overlay with a fixed opacity for each state and uses the same color as the content.

For example, if the enabled style uses secondary container color for the container and on-secondary container for content, the state layer will be an overlay using the on-secondary container color.

In the context of buttons, it is basically mixing the color of button text into the button background. I am wondering what is the rationale of this approach, as I can see two issues with it:

  1. It actually reduces the contrast because mixing the text color into background will make the background color closer to the foreground color (right ?). This is kind of counter-intuitive given the majority of interaction states are to emphasize.
  2. It creates visually inconsistent effects depending on the background color. For example, when your primary container color is dark, the text, on-primary container color, will be white. Hovering such a button will effective be tinting the container color and lighten up the button. But when the primary container color is light, the text will be pretty much black. Hovering will then be adding black to the button background and make it look darker.

Vuetify 3 implements the Material Design system so we can use it as an example. Look at the icon buttons here:

enter image description here

The first button has white foreground, and the second black. So hovering and pressing the first button will light up the button, but same action will dim the second button. Vuetify applies elevation at the same time so the difference is less intrusive. But if it is a toggle button group (see here) you cannot simply lift an individual button up, and the effect is much more confusing: enter image description here

3
  • I would add the concern that simply changing color by ≈10% for hover/focus is invisible to anyone with even minor vision impairment and violates basic accessibility guidelines. WCAG 2.2 section 2.4.11 requires 3:1 contrast so you can actually see what you are about to select. More info on WCAG w3.org/WAI/WCAG22/Understanding/focus-appearance.html The Material Design guidelines are lacking here in this regard. I would combine with WCAG.
    – Sloan
    Jan 31, 2023 at 20:46
  • Agreed - accessibility guidelines trump design guidelines in the vast majority of cases. Jan 31, 2023 at 22:01
  • Just a comment here to ask: when is accessibility not accessibility? I can see your reasoning and am inclined to agree that this is an odd thing to do. But, if the user has already located and moved their mouse to the button, are the accessibility requirements still the same? Do they still need that contrast ratio or is the hover/focus recognition more important at that stage? Mar 3, 2023 at 9:23

2 Answers 2

0

The reduction in contrast you mentioned is somewhat relative as can be seen on the MD3 page: md3

While the (already massive) contrast between text and button background decreases, the contrast between button and page background increases.

Additionally, this design avoids an edge case: If you were consistently going one direction, what do you do at the extremes? If a #000 button would require to become even darker or a #fff even whiter, it wouldn't change at all. In which case there'd be bug reports about the hover state breaking at these extremes.

In practice, this behavior is also less of a problem than it seems like in these kinds of example pages - if you have a group of 8 randomly colored floating action buttons like shown, your site definitely has other usability problems :)

Finally, some more points worth thinking about:

  1. Design guidelines are not law. You are allowed to break them in instances where you think your own implementation is better. Everyone does this, even Google themselves do it from time to time. YouTube for example didn't fully implement the MD search bar for a very long time, simply because the search bar as specified in MD performed strictly worse for them.
  2. Is it really the state color which is important here for the UX? Or is it that the change in state is very obvious when you interact with it?
0

I assume the reasoning here boils down to:

  • Maintaining a consistent color tone (e.g. you wouldn't want a green button to turn more blue on hover, and even a simple lightening/darkening effect has an impact on saturation).
  • Avoiding a situation where there is no effect (a simple lightening/darkening effect doesn't work for completely white or back backgrounds)

I would assume the loss of contrast isn't a big issue for most states, as:

  • the pressed and dragged states already rely on you having read and understood the content of the UI element, so you don't need to be able to re-read that element during these states, but rather just have indication that you're interacting with the element in some way
  • the hover state already has the person obscure the UI element with a mouse cursor, so the best readability comes from moving the cursor out of the element, regardless of its coloration

There is, however, an argument to be made for the "focus" state, where the lack of contrast could be an issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.