Non-text Contrast for Controls: The Decisions That Matter
The contrast of buttons, form field borders, icons, focus indicators and other visual elements needed to identify and use interface controls.
Marcus Adeyemi
The key figures
- WCAG 1.4.11 Non-text Contrast, AA
- 3:1 against adjacent colors for UI components and meaningful graphics
- Covered elements
- input borders, checkboxes, icons, focus indicators and states
- Not covered
- inactive or disabled components
- Text contrast
- handled separately by 1.4.3 at 4.5:1 for normal text
Why this is worth getting right
Low-contrast input borders and icons are hard to see for people with low vision or in bright light, and WCAG requires a minimum ratio for them at level AA.
Do this, not that
Do
- Check field borders and checkbox outlines against backgrounds
- Measure contrast of each state, including hover and selected
- Give icon-only buttons sufficient contrast
- Include contrast checks in design system reviews
- Test designs in bright light conditions
Don’t
- Pale gray input borders on white
- Selected states shown with a faint color change
- Ghost buttons with barely visible outlines
- Assuming only text needs contrast
When to bring in help
Our advice Bring in help when a design system uses subtle borders throughout, or when an audit flags non-text contrast across many components.
Where this comes from
- W3C Web Accessibility Initiative — Understanding SC 1.4.11 Non-text Contrast
- WebAIM — Contrast and color accessibility
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
