In a design system's functional palette, how should hover, pressed, focus and disabled colors be derived, and why is focus treated differently from hover?

## States are part of the functional palette A control is never just one color. It has a resting state and several **interaction states**: **hover** (a pointer is over it), **pressed** (it is being activated), **focus** (it will receive keyboard or remote input), **selected** (it is the current choice) and **disabled** (it exists but cannot be used). A functional palette defines the colors for these states as roles, so every button, tile and row in the product changes in the same way. For a video-streaming service that ships on TV and web, this matters twice over. On the web, a mouse user sees hover, a keyboard user sees focus and a touch user sees pressed. On a TV, the user usually moves a highlight with a remote's directional pad: there is no pointer, so there is nothing to hover, and **focus is the state that tells the user where they are**. ## Two ways to derive state colors | Approach | How it works | Strength | Weakness | |---|---|---|---| | **Discrete steps** | Each state picks a neighbouring step on the role's tonal ramp, for example one step darker for hover and two for pressed | Precise and easy to reason about for one role | Needs a value per role, per state, per surface; combined states multiply the table | | **State layer** | A translucent layer of the control's content color is drawn over the base at a fixed strength per state, lighter for hover and stronger for pressed | One rule works on every role and surface, and combined states simply stack | Results depend on the base color, so each resulting pair still has to be checked | Many systems mix the two: a state layer for hover and pressed, and a dedicated role for focus and for disabled, because those two carry obligations the others do not. ## Why focus gets its own role Hover is a courtesy. The pointer's position already tells a mouse user what they are over, and WCAG's guidance on Success Criterion 1.4.11 Non-text Contrast treats author-supplied hover effects as supplemental: they do not themselves need 3:1 contrast, provided they do not make the control or its other state indicators lose contrast against adjacent colors. Focus is different: - **It is required.** WCAG 2.2 Success Criterion **2.4.7 Focus Visible** (Level AA) requires that keyboard-operable interfaces have a mode in which the focus indicator is visible. - **It must be seen against adjacent colors.** Under 1.4.11 (Level AA), visual information needed to identify a component's state, focus included, needs at least 3:1 contrast against adjacent colors. - **A hue swap alone is weak.** The Understanding document for 1.4.11 notes that a focus state that only changes a button's background color is outside that criterion's scope, but would not pass 1.4.1 Use of Color. A ring, a thicker border or a change in size gives focus a cue that is not hue. - **On TV it is the whole navigation model.** A viewer across the room must find the focused tile instantly, so a strong ring plus a scale or lift change is common practice. Because focus must show on every surface - a light page, a dark player, a colorful poster - systems often define a **two-tone focus ring**, an inner and an outer band of contrasting colors. WCAG's guidance lists a two-color focus indicator as a technique for staying visible against any adjacent color. ## Disabled: exempt, but still designed WCAG exempts inactive components from the contrast criteria: under 1.4.3, text in an inactive user interface component has no contrast requirement, and 1.4.11 excludes inactive components. That is not a licence to make them invisible. The functional palette usually defines a single **disabled role** - a low-contrast neutral applied regardless of the control's role - so disabled looks the same everywhere and never borrows a status hue. Whether a control should be disabled at all is a component decision, not a palette one. ## Combined states States overlap: a tile can be focused and selected, a row can be hovered and pressed. The palette should state the order in which they combine, for example: 1. Apply the base role color. 2. Apply the selected treatment if the item is the current choice. 3. Apply the hover or pressed layer. 4. Draw the focus ring on top, never replacing the others. Writing this down once prevents every team from inventing its own precedence. The TV app and the web app then differ only in which states occur, not in what a given state looks like.