Contrast for non-text content
Non-text content, such as graphical objects or active user interface components, needs to have sufficient contrast for sighted users to be able to see what it is and the meaning that it conveys.
Meeting the Web Accessibility Standard
When meaningful graphical objects and the important visual aspects of user interface components and their states meet minimum contrast requirements, this meets WCAG 2 Success Criterion 1.4.11 — Non-text Contrast (Level AA).
Graphical objects
Graphics or parts of graphics that are essential for understanding the content must have a minimum contrast ratio of 3:1 against adjacent colours.
Graphical objects include things such as:
- standalone icons — for example, a phone icon (with no visible text)
- the important parts of complex diagrams — for example, the different shapes and lines in a graph.
Exceptions
Graphical objects are exempt from contrast requirements if:
- they have no meaning that is required for users to understand the content
- the particular way that they are visually displayed is essential to understanding what they mean.
More information on contrast for graphical objects
- Colour contrast for graphical objects — Accessibility Developer Guide
- Color in Graphics, Charts, etc. — Color Contrast Tutorial — Michigan State University
- Contrast with colour gradients and background images — Knowledge Area: Colour and contrast
- Understanding Success Criterion 1.4.11: Non-text Contrast — Graphical objects — WCAG 2 — W3C.
User interface components
User interface components, or controls, are discrete interactive elements with a distinct function. This includes things like:
- form fields
- buttons
- links.
Contrast for controls
The visual parts of an active control (not including any text) that a person needs to see to be able to identify the control and how it operates must have a minimum contrast ratio of 3:1 against their adjacent colours.
For more about contrast ratios of active user interface components with adjacent colours, see: Understanding Success Criterion 1.4.11: Non-text Contrast — WCAG 2 — W3C.
Contrast of visual boundaries
Some controls use a border or background colour as a visual boundary to indicate a control’s ‘clickable’ zone or hit area. If that visual boundary is the only way to identify the control, it needs a minimum contrast ratio of 3:1 against its adjacent colours.
Where a control can be identified through means other than its visual boundary — such as its position or the text it contains — that boundary does not have any contrast requirements.
For more information on the contrast requirements around user interface components with visual boundaries, see: Understanding Success Criterion 1.4.11: Non-text Contrast — WCAG 2 — W3C.
Contrast for states
Any visual effects used to indicate a control’s state — for example, whether it’s focused or selected — must have a minimum contrast ratio of 3:1 against adjacent colours.
Note: The minimum 3:1 contrast ratio is especially critical for the visible indicator that displays when a control receives keyboard focus.
Currently, different states — for example, a link’s normal and hover states — do not need to contrast with one another. The only requirement is that, in each of its states, the visual indicators of what the control is and its current state have at least a 3:1 contrast ratio against adjacent colours.
When WCAG 2.2 comes out, however, Success Criterion 2.4.11 Focus Appearance (Minimum) will likely require that a control's focus state have a contrast ratio of at least 3:1 with its non-focused state.
Exceptions
The visual parts of user interface component or controls do not need to meet contrast requirements if:
- they are not required for identifying the control
- the way the control looks is set by the browser and not modified via CSS by the designer or developer
- the control is inactive or disabled.
Take care with inactive or disabled controls
Inactive or disabled controls are often indicated by being ‘greyed out’ or having low contrast. This can present accessibility and usability problems for users, and disabled buttons in forms are a good example of this.
Disabling form fields and buttons is almost always a bad idea. For more information, see Disabled buttons.