Material interaction states: layer, focus and touch

A state tells someone what a component is doing at this moment. Material Design defines states as the interaction status of a component or UI element, and it keeps two visual indicators so the signal survives a weak channel. The guide is exact about the overlay and the numbers behind it. It fixes an opacity per state and never names a minimum contrast for that overlay in each color combination. It also defines hover around a cursor and says nothing about a screen with no pointer. Both cases are the product team’s call, not the guide’s.

What a state communicates

A state answers two simple questions: can I use this, and what just happened to it. An enabled component looks ready for input, and a disabled one looks unavailable because it is. NN/g opens its own article on the same ground, noting that subtle visual cues tell people whether a button is clickable, pressed, or hovered. The signal matters more than the decoration. A person who can’t tell a disabled control from an enabled one will click it, wait, and click again. The guide asks for one more thing: apply states consistently across components, so the same visual change means the same thing everywhere.

The six states and where each one appears

The guide names six: enabled, disabled, hover, focused, pressed, and dragged. Each one has a definition tied to an input. Enabled marks a component that is interactive, and disabled marks one that is not. Hover appears when a cursor rests above an element, and focus appears when someone highlights an element with a keyboard or voice. Press marks a tap, and drag marks a press followed by movement. The states can also stack: the guide says they can be combined, such as selection and hover. The reach of each one isn’t uniform. Hover and focus are inherited by action, selection, and input components, which includes buttons, cards, chips, list items, and text fields. Disabled follows those same groups. Dragged stays narrow, reaching only cards, chips, list items, and sliders. Navigation and communication components sit outside most of it, so app bars, dialogs, menus, and tabs don’t inherit hover. The guide also caps the count. There can be only one hover, one focus, and one press on a screen at a time.

The state layer

The state layer is what makes this work. The guide describes a semi-transparent covering on an element that indicates its state, built from opacity rather than a new color. The layer uses the same color as the content it sits on. A text button tints with its label color, and a filled button tints with the color of the text on its container. Each container color has a matching on color for content, and the layer borrows it. Four values cover the states: hover at 8% opacity, focus at 10%, press at 10%, and drag at 16%. Disabled is a separate case at 38%. Two limits matter. Only one layer applies at a time, and the layer is smaller than the area a finger hits: the state layer is 40dp while the interactive target is 48dp. The gap between those two numbers is deliberate. The ink grows when someone interacts, but the target stays large enough to catch a tap that lands a few pixels off.

Why elevation isn’t the general signal for press

On press, many designers reach for elevation, and the guide keeps that tool on a short leash. Pressed states should be high-emphasis and trigger a change in composition, so a ripple or a fill change carries the signal. Elevation is optional and narrow: only some components, such as buttons and cards, can inherit elevation to signify a pressed state. The same restraint shows up on drag, where the guide asks dragged states to keep low emphasis so they do not distract from the task. Lifting every control on press turns a state into an animation. It also competes with the focus ring and with the layer, which already carry the message. NN/g makes the neighboring point from the other side. Changing a button from flat to three-dimensional raised clicks in an early study, which is about clickability, not about press feedback. A press cue that fires on every tap deserves the smaller budget.

Focus and the keyboard

Focus is the state that has to work even in the worst conditions. The guide defines it as the highlight on an element someone reached with a keyboard or voice. It adds a visible ring, the keyboard focus indicator, so a person can see where they are on the page. Order matters as much as visibility. In the guide’s input rules, focus must move in a logical order, left to right and top to bottom on most pages. The Escape key removes focus and clears a selection. NN/g adds the constraint that decides whether the ring works. It recommends a stroke or outline rather than a color change alone, because a color shift may not be perceived by some people with vision impairments. The guide also stops at one focus at a time, and a disabled control cannot be focused, dragged, or pressed at all. A person tabbing past a disabled button gets silence where a reason would help.

Selection and input: choosing an item against typing a value

Selection and input split along a simple line. Selection asks a person to pick from a set the system already knows, and input asks them to supply a value. The guide shows selection through a check mark, a checkbox, a surface color change, or a combination, and it gives navigation surfaces like tabs and a rail an active indicator instead. The split also follows the input device, where a long press or two fingers starts selection on touch and a hover reveals a checkbox on desktop. NN/g’s older rule still sorts the two controls cleanly. Radio buttons fit a list of mutually exclusive options where exactly one choice holds. Checkboxes fit a list where any number can be chosen, including none. The same page gives a reason to prefer visible options to a dropdown, since a radio list has lower cognitive load because all the options stay visible. One more of its rules lands in daily work: a radio list should always ship with a default selection.

What to measure

Three checks catch most of the slips. The touch target comes first, because it has a physical floor, which a design preference doesn’t. The guide names 48dp as the interactive target while the state layer stays at 40dp. NN/g lands on the same scale in centimeters: a target should measure at least 1cm by 1cm for a person to select it quickly and accurately. The same page names the failure mode, where small targets and tight spacing raise the chance of a slip onto the wrong control. Shape carries the second check. NN/g warns against giving a non-clickable item the look of a button, which is the state system working in reverse. The third check is the state contrast itself, and here the guide gives a fixed opacity and nothing more. Test each state on each container color and read the result, because a 10% overlay on a pale surface can vanish in a screenshot.

The pieces here sit next to the post on Material Design, the post on spacing and grid, the post on accessible HTML, and the post on dark mode contrast. A state system earns its keep when the same cue means the same thing on every screen. A person who never touches a pointer should still be able to tell where they are. Name the contrast floor of your own palette instead of trusting the default opacity to hold.