How can I make keyboard focus visible on controls with different backgrounds?

Treat it as a component-by-component review, rather than checking one button on one page and assuming the same treatment works everywhere. First list the controls people can reach with a keyboard—for example, buttons, links, fields, tabs, and menu items. Then identify the backgrounds and visual states each control can appear on.

For each combination, compare the control without focus to the same control with focus. Check normal, hover, selected, and unselected appearances where they apply. Include different surrounding backgrounds, such as a light panel, a dark panel, or an image-backed area. Note whether the focus indicator is easy to notice and whether it blends into either the control or what surrounds it.

WCAG 2.2’s Focus Appearance criterion addresses indicator size and the contrast change between focused and unfocused states; it is a Level AAA criterion, not the AA minimum. Its guidance also says to review components in selected and unselected states. [S1]

Give each row one component, one state, and one background context. Record the indicator style being reviewed, then note what you can actually see: for instance, whether its outline is clear around the whole control or disappears along one edge. Use a separate row for a different selected state or background rather than combining several conditions into a vague note.

A useful result is specific and actionable: “Tab, selected, dark sidebar: indicator’s dark segment blends into the sidebar.” That points to the difficult boundary without claiming that the whole design has passed or failed a formal conformance assessment. If one color disappears against some backgrounds, flag those combinations for design review; don’t let a good result on a light background stand in for the rest.

Possibly, but check the implemented indicator against every relevant component and surrounding color. A two-color indicator is one approach described in W3C Technique C40: contrasting portions can help retain visibility where one portion blends into a background. It can help reveal why a single-color treatment is hard to see across varied backgrounds or component states. [S2]

That technique is informative guidance, not the only design option or a guarantee of conformance. WCAG’s focus guidance distinguishes the change between focused and unfocused appearances from contrast against adjacent colors, which is addressed separately by Non-text Contrast. [S1] So record both what changes when focus appears and whether the indicator remains discernible against nearby colors. Assess your actual implementation in context.

Use this copyable row template; add rows until every relevant combination is represented:

Component: [control] | State: [normal/hover/selected/unselected] | Background/context: [surface or image area] | Indicator tested: [style or color] | Observation: [clear, blends at edge, hard to notice] | Follow-up: [review/change/retest]

Worked example, with invented placeholder details: “Component: Tab | State: selected | Background: [dark sidebar] | Indicator: [single light outline] | Observation: [outline hard to distinguish on selected fill] | Follow-up: [compare an alternative treatment, then retest].” Repeat for the tab when unselected and for any other background it can appear on. Keep observations tied to the exact combination you reviewed. After a design change, repeat the affected rows, including the focused and unfocused comparison; don’t mark unreviewed combinations as clear.