Fewer Tokens, Fewer Wrong Answers

Disabled states tend to grow their own palette: a disabled text grey, a disabled border grey, a disabled background grey. Each looks reasonable on its own. Together they’re a set of decisions people have to remember and a set of chances to pick the wrong one.

I’ve come to judge tokens less by how precise they are and more by how many wrong answers they make possible.

One token instead of a palette

In one library I work on, disabled variants keep their normal colours and bind their opacity to a single token, opacity/disabled, at 50%. There are no disabled colour tokens. A disabled button, badge and toggle all fade the same way, and a new component gets a correct disabled state without anyone designing one.

Where the rule bends

In another library we refined it. Buttons and purely visual elements, like flags and icons, use the opacity token. Form fields and cards switch to dedicated disabled colours, because a half-transparent input on a coloured surface lets the background bleed through and looks broken rather than unavailable.

The part both libraries share is the important one: never both. A colour that’s already muted and then faded becomes nearly invisible.

On contrast

Faded text won’t meet normal contrast ratios, and accessibility guidelines exempt inactive controls. That exemption isn’t the goal, though. The disabled state still has to look clearly different from the enabled one, and the reason something is unavailable should be explained close by.

The broader point

A smaller system isn’t automatically a simpler one. But when two tokens exist to express one idea, sooner or later someone uses the wrong one. Consolidate first, then add exceptions deliberately and write down why.