How should a small business test colour contrast across a customer journey?

Audit the route a customer takes

A palette swatch is an incomplete test. Customers see a sequence: landing page, product or service details, form, confirmation and error recovery. Each stage contains text on different backgrounds, controls in several states and sometimes icons that carry meaning. Record one realistic route through the journey at desktop and mobile widths. Note the visible colour pairs and the task each element supports. Include banners, sale prices, required-field hints, disabled controls and overlays. An audit based only on the design system's default button may miss the moment a customer cannot read an error or see where keyboard focus has moved.

Use the current WCAG 2.2 Level AA success criteria as separate questions. Criterion 1.4.3 covers text and images of text: ordinary text needs at least 4.5:1 contrast against its background; large-scale text has a 3:1 threshold. Criterion 1.4.11 covers visual information needed to identify a user interface component or meaningful graphic: at least 3:1 against adjacent colours, subject to its stated exceptions. These thresholds describe different kinds of information. A button's label is text even though it sits inside a control; its border or state indicator may be non-text. Testing the whole button against one number confuses the two requirements.

Test text in the state it appears

Measure the foreground and background colours that actually meet behind the text. A dark headline on white can pass while the same colour on a tinted card fails. Placeholder text, secondary descriptions, link labels, form instructions and error wording may all be needed for a decision and should be tested as text when visible. Do not assume a bold-looking style qualifies as large-scale text; WCAG defines size by its own large-text conditions, so check the rendered font size and weight. The exceptions for incidental text, inactive components and logotypes are narrow. An ordinary low-contrast instruction does not become incidental merely because it looks less prominent.

A worked example makes the distinction practical. Suppose a checkout page uses pale grey for delivery instructions and a darker navy for the submit label. Measure each text pair independently on its actual surface. If the instruction fails the ordinary-text threshold, darken that text or change its background, then check again at the rendered size. Do not solve the problem by calling the instruction decorative when it tells buyers when delivery happens. The submit button needs a second examination: its label may pass 4.5:1 while the button shape disappears into a similarly coloured panel. That is a separate non-text contrast issue. No ratio is asserted for these hypothetical colours until they are measured.

Identify what makes a control visible

For each input, button, checkbox and selected tab, ask what visual feature tells a person where it is and what state it is in. It might be a border, fill, check mark, underline or focus indicator. Compare that necessary feature with its adjacent colour, not with an unrelated colour elsewhere in the palette. The W3C non-text contrast guidance sets a 3:1 threshold for these required visual cues. If an input relies on a thin grey border, measure the border against the page. If a checkbox relies on a check mark to show selection, measure the mark against its surrounding fill. A large clickable area by itself does not make its boundary perceivable.

Inspect interactive states rather than one screenshot. A control may pass at rest and fail when focused, selected, hovered or shown with an error. Keyboard users need to see focus; an error state must remain distinguishable even when a red hue is hard to perceive. WCAG's Use of Color criterion also requires that colour is not the only visual means of conveying information or prompting an action. Pair a colour change with a clear label, icon shape, border or explanatory message as appropriate. Test that added cue for its own contrast, and ensure the message is in a sensible reading order. Colour contrast and information design solve related but distinct problems.

Keep meaningful graphics readable

A chart, status icon or diagram may convey information that prose nearby does not. Identify the pieces needed to understand it, then test those pieces against neighbouring colours under the non-text rule. A decorative photograph is different; WCAG does not require every natural colour in a photograph to meet a numerical contrast ratio. A brand logo also has a stated exception. Do not apply those exceptions to an instructional arrow simply because it sits inside a marketing image. If a chart uses several coloured series, provide labels or a data table as well as visually separable marks, so readers are not forced to decode meaning from colour alone.

Contrast checkers are useful for controlled colour pairs, but the computed ratio is only as good as the colours entered. Inspect rendered pages for gradients, translucent overlays, photographs behind text and state changes driven by scripts. A semi-transparent panel can produce different effective backgrounds over different parts of an image. Choose the least favourable plausible area and verify the rendered result, then adjust the design to create a stable text surface if necessary. Avoid treating a screenshot sampler as the sole authority: antialiasing and display conditions can alter sampled edge pixels, while WCAG guidance asks evaluators to consider authored or user-agent colours in the relevant cases.

Repair by role and retest the journey

Fix a repeated design token at its source when many pages share it, but check every place that token appears. Darkening a muted-text token may help descriptions yet create a new clash on a dark card. Record each failing pair with page URL, viewport, state, foreground, background, measured ratio and applicable criterion. Agree on a replacement colour that preserves the visual role while meeting the relevant threshold. Recheck real pages after deployment, including mobile overlays and form feedback. Pair numerical checks with a keyboard walk-through and a visual read of the task; a passing ratio cannot tell you whether an instruction is clear or whether a required control has been omitted.

Give the business a concrete exit decision. For the chosen customer route, all necessary text and non-text cues have been identified, their relevant colour pairs measured in default and consequential states, and any failures fixed and retested on live output. Preserve the small audit record so the next campaign palette or template change can be checked against the same route. If a supplier controls a widget, document the affected state and send a reproducible example rather than silently accepting an inaccessible checkout step. The point is to let customers read and act at every stage, including when an error occurs, not merely to obtain a green score for the home page.

Use the audit to make durable design choices

Colour tokens should encode a role and a tested pairing, not merely a fashionable shade. Define body text on the main surface, secondary text on cards, action labels on buttons and focus cues against the backgrounds where they appear. If a campaign team swaps a background, the token pair has changed even if the foreground value has not. Record approved combinations in the design file or style guide with the use case and criterion. This gives a non-specialist editor a practical choice when building a new landing page and reduces the chance of recreating a known failure.

Test language versions separately. English and Traditional Chinese copy can wrap differently, move onto an image area or cause a button to grow into a differently coloured region. A contrast checker run on the English desktop mockup cannot prove the Chinese mobile flow. Open each locale at representative widths and trigger the same validation errors and selected states. If a translation adds a longer hint, ensure it remains visible rather than being clipped behind a decorative layer. The numeric requirement stays the same, but the actual pixels and adjacent colours a reader encounters may change with layout.

Prioritise failures by the task they block, without redefining the standard. An unreadable payment error or invisible selected delivery option should be fixed before a low-priority decorative detail, while all applicable failures remain in the repair list. Assign an owner, make the colour or layout change and repeat the same route. Ask a person unfamiliar with the page to complete the task if possible; they may expose a missing cue that the original designer has learned to infer. Record that observation as user feedback, not as a substitute for the measured WCAG checks.