Contrast and colour: a testing workflow for your web design
Make text, buttons and error messages clear: measure WCAG contrast correctly and check colours across your whole design.
In short
An accessible colour scheme makes text readable, controls recognisable and information understandable without relying on a particular colour. To get there, check specific combinations and states: a beautiful colour palette on its own tells you nothing about how readable a form error or a button is.
Understanding the minimum values
WCAG 2.2 AA requires a contrast of at least 4.5:1 between normal text and its background. Large text needs at least 3:1. Text counts as large from 18 point, or 14 point when bold; in CSS, 18 point corresponds to 24 pixels. Headings are therefore not exempt from the higher value simply because of their function. The calculated value is not rounded up: 4.49:1 falls short of 4.5:1.
The guideline includes exceptions, for example for purely decorative text, inactive controls and text in logos. Ordinary body text in your brand colour does not fall under the logo exception. In practice, leave yourself some margin, especially with thin fonts.
Don't just measure text
Under success criterion 1.4.11, important graphical information and the visual cues people use to identify active controls or their state generally need 3:1 against adjacent colours. This applies, for example, to a necessary field outline, a meaningful icon or the mark on a selected checkbox. The actual design is what counts; not every decorative border has to meet this value.
So check a search field as a whole: can you see the field, read the text you type and tell where the keyboard focus is? A high-contrast label on its own does not fix an invisible focus.
Add words and shapes to the information
A red outline does not explain an error. Add something like: “Please enter an e-mail address with @.” An availability status can show “In stock” next to the coloured dot. Charts become easier to understand when lines also have different patterns and direct labels. That way the meaning stays visible when someone perceives colours differently or uses a screen with a changed colour mode.
Build a colour matrix for real components
- Collect body text, links, buttons, input fields, notices and error messages from your actual design.
- For each component, note the foreground and background for the default, focus, selected and error states.
- Measure the CSS colours used with a contrast checker; take transparency, images and gradients in the background into account.
- Define readable variants as shared design tokens and fix the component at its source.
- Then check light and dark modes and the affected pages in the browser.
Example: test a form, not just a palette
Take a contact form and trigger an error on purpose. Check the field label, the input text, the error message and the submit button. Move between the fields with the keyboard. Zoom in on the page and check whether the error message still belongs to its field. This small scenario shows which colour combinations actually meet in the product and gives you a repeatable test for later changes.
Record the sign-off so others can follow it
Document the component tested, its states and the values used. For text on images, note the exact image area or add a solid background behind the text. An automatically detected contrast error is a helpful starting point; what it tells you ends with the state that was actually tested. Retest new components and larger design changes so that the approved combinations hold up in everyday use.
Sources & review status
Here you’ll find the original sources for this article. Last checked on .
- W3C: text contrast and exceptions (1.4.3)
- W3C: contrast of controls and graphics (1.4.11)
- W3C: don't use colour as the only visual cue (1.4.1)
Legal requirements depend on the country, the provider and the specific offer. This article explains the basics and practical steps. Test results apply to their documented scope and date.