Colors that change on touch: interaction states

Short answer

A button doesn't live with just one color; it shifts to a different appearance when the cursor hovers over it, when it's pressed, when it takes keyboard focus, and when it can't be used, and each of these appearances tells the user "what's happening right now." A consistent system builds these changes not by picking a separate color for every component, but with a transparent state layer placed on top of the color, with a fixed opacity for this layer for each state. WCAG doesn't set a contrast floor for a disabled button, but that button's existence and purpose should still be readable; the fading should be just enough to say "currently unavailable" without making the button invisible.

Five states

Rest is what the component looks like when nothing is happening to it; it's the button's base color. The other four states are built on top of this base color.

Focus shows a user navigating by keyboard or another assistive tool that the component is selected; disabled, meanwhile, says the component can't currently be used. These two states get their own sections, because both connect directly to accessibility.

The difference between this lesson and the status colors in UX-02 matters. Success and error report the outcome of an operation; the five states here report the component's own current condition. An error button has its own hover, pressed, and focus states too.

State layers

Choosing a separate color for every state of every component quickly becomes unmanageable: ten components, three themes, and five states add up to one hundred and fifty color decisions. Material Design solves this problem with a single idea.

If a blue button's label is white, a low-opacity white layer is placed on the button in the hover state, and the button lightens slightly. The same logic works with a dark layer on a button with dark text on a light surface, and the button darkens slightly. The designer doesn't pick a new color for every button; they only decide once which opacity corresponds to which state. In the token structure from UX-01, this is a small group of tokens made up of a few fixed numbers, shared by every theme and every component.

It's instructive to calculate just how small a change these opacities produce. Material's baseline theme defines its primary color as #6750A4 and writes its label in white. Once an eight percent white layer is placed on this button, the color becomes #735EAB; the contrast ratio between rest and hover is only about 1.2:1. With a twelve percent layer, that ratio rises to 1.3:1. This smallness is deliberate: hover is a confirmation, not a shout. But it has a consequence too: these changes aren't a strong signal on their own, and they're not enough for a focus indicator that relies on color alone.

Keyboard focus must be visible

Someone who doesn't use a mouse — navigating by keyboard, switch access, or voice — can only tell which element on screen is selected from the focus indicator. If the indicator disappears, the user keeps pressing the tab key without knowing where they are.

WCAG sets several layers of rules on this. The AA-level 2.4.7 criterion requires that every keyboard-operable interface have a mode of operation where the focus indicator is visible. The 2.4.11 criterion, added with WCAG 2.2, requires that the component receiving focus not be entirely hidden by other content the page's author has placed. The AAA-level 2.4.13 criterion sets a measure on the indicator itself: the indicator's area must be at least as large as the unfocused component's surrounding area two CSS pixels thick, and the contrast between the focused and unfocused states of those same pixels must not fall below 3:1.

This last criterion shows numerically why the state layer isn't enough: the 1.3:1 difference a twelve percent layer produces is well below the 3:1 threshold. That's why a good focus indicator doesn't just shift the color slightly — it draws a visible ring around the component. The ring is chosen to stand out from the background, not from the component's own color. A dark ring in a light theme, a light ring in a dark theme; or a two-layer ring that works in both themes, light on the inside and dark on the outside. On the web, browsers let you present this indicator with a selector that shows the ring only when navigating by keyboard, :focus-visible, without bothering mouse users with unnecessary rings.

How faint should a disabled button be

The question on the lesson card: how faint should a disabled button be?

WCAG doesn't answer this question with a floor. The 1.4.3 criterion explicitly states that text that's part of an inactive interface component has no contrast requirement; the 1.4.11 criterion likewise exempts inactive components from the component-contrast requirement. So as far as the rule goes, a disabled button can be as faint as you like.

But the rule's silence doesn't mean the question goes away. A disabled button has to say two things: "I'm here" and "I can't be used right now." A button that's too faint can't say the first: after filling out the form, the user looks for where the "Submit" button went, because the button has become almost invisible. A button that isn't faint enough can't say the second: the user clicks it and nothing happens.

Running the numbers with Material's values makes the boundary concrete. On a #FEF7FF surface, a background drawn at twelve percent of the #1D1B20 text color becomes #E3DDE4 and is separated from the surface by only 1.3:1; a label written at thirty-eight percent of the same color becomes #98939A and is separated from its own background by about 2.3:1. The label is readable, but with effort; the button barely separates from the surface at all. If the label's opacity drops to thirty percent, the ratio falls to 1.9:1; if it rises to fifty percent, it climbs to 3.1:1.

These numbers don't yield a single correct opacity, but they do yield a working range: the disabled label should be clearly fainter than the active label, but the user should still be able to read it and understand what the button does. The same button in its active state gives about 6.4:1 with its white label on the primary background; the disabled state being noticeably lower than this value is what carries the "unavailable" message.

Faintness alone isn't enough. Telling the user why the button is disabled often does more work than color: a nearby sentence like "Accept the terms to submit" shows the user what they've left out. Some teams never disable the button at all; instead, when the user submits an incomplete form, they show the missing fields. Both approaches have their advocates; the measurable part is whether the chosen approach shows the user what's missing.

Example — photo selection screen

A family album app lets users select multiple photos and share them. In the first version, a selected photo is shown by placing a twelve percent black state layer over it; no checkmark or frame is used.

The math shows whose photo this marker disappears on. The twelve percent black layer creates about a 1.3:1 difference between the selected and unselected state on a light portrait's #F1C7A9-toned cheek; on a dark portrait's #4A2C1D-toned cheek, that difference drops to 1.09:1. Both are well below 3:1, but when a dark-skinned relative's portrait is selected, the change is nearly invisible. The user can't count which photos they've selected, and some photos silently drop out of the share.

The team rebuilds selection with markers that don't depend on the photo's content. A checkmark is added to the corner of the selected photo, and a two-layer frame — light on the inside, dark on the outside — is added around it; the state layer stays as only a supporting cue. For a user navigating by keyboard, the focus ring is drawn separately from the selection frame, so "in focus" and "selected" don't get confused with each other. The result is tested on an album of portraits whose skin tones, backgrounds, and lighting are clearly distinct from one another.

Common misconception

Summary

1. Rest, hover, pressed, focus, and disabled states are built consistently with fixed-opacity state layers, not by picking a separate color for every component.
2. The change a state layer produces is small and isn't enough for focus; the focus indicator must be a visible ring that stands out from the background, and WCAG 2.2 sets requirements for its visibility, non-obscurement, and, at the AAA level, its size and 3:1 contrast.
3. WCAG sets no contrast floor for a disabled button, but the button must stay visible and readable, supported by text that explains why; selection over variable content like photos is likewise shown with markers that don't depend on skin tone.

Test yourself

1. (Easy) What are the five most common interaction states?
2. (Easy) In Material Web, what is the opacity of the hover state layer?
3. (Medium) How faint should a disabled button be?
4. (Medium) Why isn't a state layer by itself a good focus indicator?
5. (Hard) If WCAG sets no contrast requirement for inactive components, how should a designer decide on a disabled button's faintness?
6. (Hard) Why does selection shown with a twelve percent black layer fail on dark-skinned portraits in the photo selection screen, and how is it fixed?

Answers

1. Rest, hover, pressed, focus, and disabled ("Five states").
2. 0.08 ("State layers").
3. WCAG sets no floor; the button must both stay visible and make clear that it can't be used. With Material's values, the disabled label separates from its own background by about 2.3:1, while the active label gives about 6.4:1. The label should be clearly fainter but readable, and supported by text that explains why the button can't be used ("How faint should a disabled button be").
4. The change it produces is too small: a twelve percent layer on #6750A4 gives only about a 1.3:1 difference, well below the 3:1 that WCAG 2.4.13 requires between the focused and unfocused states ("Keyboard focus must be visible").
5. Instead of the rule, they look at the user's two needs: being able to find the button and being able to tell it can't be used. A range is chosen where the label stays readable but is noticeably fainter than the active state, and the button is supported with text that explains why, or the missing fields are shown without ever disabling the button at all ("How faint should a disabled button be").
6. The layer creates about a 1.3:1 difference on the #F1C7A9 tone but only 1.09:1 on the #4A2C1D tone; the selection becomes invisible. A checkmark is added in the corner along with a two-layer frame, the focus ring is drawn separately from the selection, and the result is tested with portraits of different skin tones ("Example — photo selection screen").

Sources

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," success criteria 1.4.3, 1.4.11, 2.4.7, 2.4.11, and 2.4.13.
• Material Web, "md-sys-state" token file.
• Material Web, "md-comp-filled-button" and "md-ref-palette" token files.

Next step

UX-05 looks at systems that leave where colors come from up to the user: it discusses how an entire family of tones is derived from a single source color in a perceptual space, and how much this flexibility reduces the brand's control over its own colors. UX-07, in turn, turns this lesson's checkmarks and rings into a principle: from faulty form fields to chart legends to underlined links, it covers how information is carried by shape, icon, text, or pattern even when color isn't visible.