Accessibility
Accessible colour and typography: contrast in brand design
Accessible colour and typography start with treating your brand design as a system of testable relationships: between text and background, controls and their surroundings, and information and its visual presentation. For WCAG 2.2 Level AA, normal text generally needs a contrast ratio of at least 4.5:1, while large text needs at least 3:1. Colour must not be the only way important information is conveyed. Content must also remain usable when enlarged, displayed in narrow viewports or viewed with adjusted text spacing.
This does not mean replacing every brand colour. Often, the solution is to define its use more precisely, add functional variants and test components consistently. This article explains the route from a colour palette to a verifiable interface. All user journeys and failure examples described here are hypothetical: they illustrate methods, not documented client outcomes.
1. Give brand colours defined responsibilities
A traditional colour palette does not tell you which combinations work in an interface. A vibrant orange might be effective across a large decorative area but provide insufficient contrast for a small link on white. Decide not only which colours belong to the brand, but also where they may be used. Distinguish roles such as background, primary text, supporting text, link, primary action, border and focus indicator.
Assign specific values to these roles. Design tokens connect design and development: a role such as “text on brand surface” points to a tested text colour rather than an improvised choice. Include rules for light and dark surfaces. Approval should always apply to a combination, not to a colour value in isolation. Document prohibited uses too, such as applying a pale accent colour to small labels. This preserves brand recognition without forcing every new page to repeat the same fundamental decisions.
2. Measure and assess text contrast correctly
The W3C’s WCAG 2.2 distinguishes between normal and large text. Large text means at least 18 point, or 14 point when bold, equivalent to approximately 24 and 18.7 CSS pixels respectively. A heading therefore does not qualify as large text merely because it is a heading. Smaller text generally requires 4.5:1; qualifying large text requires 3:1. Rounding up does not make a measurement just below the threshold sufficient.
Test the combination actually rendered, including transparency, background images and overlapping surfaces. For a gradient, the average is not what matters: text needs sufficient contrast across all relevant background areas. A contrast tool calculates the ratio, but assessment also requires knowing the font size, weight and use. Keep the colour values, ratio and tested component as acceptance evidence. Where possible, allow some margin above the minimum rather than designing every combination precisely at the threshold.
3. Distinguish boundaries, icons and controls
Visual information needed to identify interface controls and their states generally requires at least 3:1 against adjacent colours, subject to the conditions of the non-text contrast criterion. Examples include a necessary input border or an icon that conveys meaning. Not every decorative line needs to meet that ratio. The important question is whether users need the visual information to recognise a function or state.
Consider a hypothetical form with white input fields on a white background and barely visible grey borders. If those borders are what makes the fields identifiable, they need sufficient contrast. The correction might be a darker border or a sufficiently distinct field surface. The visible label independently needs the appropriate text contrast. Avoid blanket rules such as “Every button needs a dark outline”: whether its boundary is necessary depends on the complete presentation. Instead, assess each visual feature that users rely on for identification.
4. Design states as a connected family
An approved default button does not prove that the component is accessible. Define its default, hover, keyboard focus, pressed, selected and, where relevant, error states together. Each variant needs the relevant text and non-text contrast. A hover effect that lightens the background can make previously readable white text difficult to see. A selected filter needs more than a change from grey to green, such as a check mark and a programmatically identifiable selected state.
For links within paragraphs, a persistent underline is often the most robust solution. It makes their function visible independently of colour perception. Identify disabled controls clearly and explain why an action is unavailable where necessary. Inactive components are exempt from certain contrast requirements, but that is not a recommendation to make their labels practically invisible. In multistep journeys especially, users need to understand which action will allow them to proceed.
5. Keep keyboard focus visible and discoverable
People navigating with a keyboard need a reliable visual indication of their position. Deliberately design the focus indicator as part of the brand, for example as a contrasting ring separated from the component by a small offset. Test it on every intended surface. An outline that works on white can disappear on a dark brand panel. Two outlines with different lightness levels can help across changing surroundings, but they still require practical testing.
The W3C overview of what is new in WCAG 2.2 explains Level AA “Focus Not Obscured (Minimum)”: author-created content must not entirely hide the focused component. A fixed cookie banner therefore belongs in the test. Keeping the whole component visible is a useful design goal, but goes beyond this minimum requirement. Do not confuse this with the Level AAA “Focus Appearance” criterion. Also check the 24 × 24 CSS pixel minimum target size or the applicable exceptions; a visible outline does not automatically enlarge the interactive area.
6. Make errors understandable, not merely red
Imagine a hypothetical appointment booking form: after submission, a red border appears around the email address, with no other visible change. Someone with impaired colour perception may not understand what went wrong. A screen reader also receives no useful information from colour alone. Add a specific message such as “Please add the domain after the @ symbol”, provided that this cause has been reliably identified. Associate the message programmatically with the field and preserve information already entered.
The WAI Forms Tutorial: User Notifications explains understandable error and success feedback. For brand design, the implication is straightforward: errors need a combination of text, colour and, where useful, an icon. Define a sufficiently contrasting error summary when several fields are affected. Acceptance evidence is not just a screenshot, but a reproducible journey: trigger the error, perceive the message, locate the field, correct the input and continue successfully. Success must not be communicated solely through a change to green either.
7. Typography is a system, not a font badge
WCAG does not prescribe a particular font family. Neither a sans-serif typeface nor a specialist font makes a website accessible on its own. Choose sizes, weights and line lengths that keep actual content readable. Check similar characters such as uppercase I, lowercase l and the numeral 1, along with accented characters, punctuation and long compound words in German content. Very thin weights can be difficult to read in practice even when the calculated colour contrast is sufficient.
Develop a limited typographic scale for headings, body text, labels and supporting information. Avoid de-emphasising important instructions through both small size and low contrast. Relative units support flexible implementations but do not replace testing. Semantic structure matters just as much: a large, bold line is not automatically a programmatically identifiable heading. Visual hierarchy and document structure should align so that people can find their way both by scanning the page and by using assistive technologies.
8. Test enlargement and reflow together
Text generally needs to support enlargement to 200 per cent without losing content or functionality, taking account of the exceptions stated in the criterion. Test navigation, buttons, cookie dialogs and form instructions as well as article text. A hypothetical fixed-height button might clip a second line when its text becomes larger. A robust correction lets the component grow and preserves sufficient internal spacing instead of shrinking the text again when space becomes tight.
For reflow of horizontally written content, a width of 320 CSS pixels is relevant: reading should generally remain possible without requiring both horizontal and vertical scrolling. Exceptions cover content whose use or meaning requires a two-dimensional layout. A wide data table may qualify, but that does not automatically exempt the whole page. Test the content outside those exceptions separately. Acceptance evidence might document that a booking page still displays all labels and keeps its primary action reachable in a narrow viewport.
9. Personalised text spacing must not break content
The WCAG text spacing criterion does not prescribe a universal appearance for your default design. It requires that specified adjustments do not cause loss of content or functionality: line height of at least 1.5 times the font size, paragraph spacing of at least twice the font size, letter spacing of at least 0.12 times the font size and word spacing of at least 0.16 times the font size. Test these settings together using an appropriate test stylesheet or tool.
Common failures arise from fixed heights, clipped overflow or cards with insufficient room. After spacing is adjusted, a hypothetical product card might still show the price but hide the product details link. The solution usually lies in the layout: flexible heights, sensible wrapping and sufficient room between content areas. Include long button labels and error messages in the test. A screenshot of the unchanged desktop view cannot demonstrate this quality; you need a documented test of the adjusted presentation with its functions still reachable.
10. Design charts without colour puzzles
A chart using several brand colours may look consistent yet become difficult to understand when two shades are perceived similarly. Use direct labels, different line patterns, distinguishable markers or a combination of these. Meaningful graphical elements need the applicable non-text contrast. Avoid associating information exclusively through a legend that contains only coloured dots.
The WAI Images Tutorial: Complex Images explains why complex visualisations need appropriate text alternatives. For a hypothetical comparison of bookings across several months, a short description could explain the purpose while an accompanying table provides exact values. The alternative should make the same relevant information available without forcing a purely visual description of every detail. For interactive charts, also check whether information shown in hover tooltips is available through the keyboard and without requiring precise pointer movement.
11. Text over images needs editorial rules
Dark text on a pale photograph works only while the relevant part of the image remains pale. A different crop on mobile frequently changes that assumption. Prefer separate text panels or a sufficiently opaque background behind the text. A subtle shadow or transparent gradient is not automatic proof of sufficient contrast. Test every intended crop and the least favourable areas behind the letters.
Avoid images of text when real text can deliver the presentation; WCAG recognises certain exceptions, including essential presentations. Logos should not be treated as equivalent to replaceable promotional headings. Editorial teams need clear templates: where may text appear, which image variants are permitted, and when is a separate text panel necessary? A campaign graphic with an embedded discount message often remains inflexible when enlarged. Real HTML text, by contrast, can resize, wrap and respond to individual presentation settings.
12. Organise acceptance and ongoing maintenance
Start with a matrix of colour roles, components, backgrounds and states. For each check, add the expected result, actual finding and evidence. An error-state entry might record that the label is readable, the field is identifiable, the message does not rely on colour alone and correction is possible. Automated checks help detect many contrast problems, but do not reliably assess every image area, interaction or meaning. Manual keyboard, zoom and content tests remain necessary.
Apply corrections to central components and editorial guidance rather than only to individual pages. Retest when colours, fonts, image templates or interaction patterns change. WCAG 2.2 AA includes all applicable Level A and AA criteria, not just the design topics covered here. EN 301 549 is not interchangeable with it, and a technical audit is not complete evidence of legal compliance. For Austria’s BaFG, which has applied to covered services since 28 June 2025 and does not automatically cover every website, see the Zensations guide to accessible websites in Austria.
Frequently asked questions
Do we need to replace our brand colour?
Not necessarily. The original colour can often remain in decorative use, while darker or lighter functional variants serve text, links and controls. Tested combinations and clear usage rules are what matter.
Is black text on white always the best solution?
It provides high contrast, but it is not the only suitable combination. Coloured surfaces can work too. Check contrast, readability and every state rather than prescribing one colour combination universally.
Is an automated contrast check enough?
No. It cannot replace assessment of meaningful elements or testing with a keyboard, enlarged text and adjusted spacing. Images, gradients and dynamic states particularly need additional examination.
Which font makes our website accessible?
No font does that alone. Accessibility depends on the interaction of letterforms, size, weight, contrast, flexible presentation and semantic structure. Test real content rather than relying exclusively on typography specimen pages.
Your next step: a focused design system review
If you want to understand which brand combinations work in digital interfaces, a Zensations accessibility audit is a useful starting point. Bring your colour palette, typography guidelines, core components and an important user journey. These provide a concrete basis for prioritising corrections. Founded in Vienna in 2010, Zensations supports the connection between design and implementation through its accessibility services. The goal is demonstrable improvement and verifiable requirements, not a blanket guarantee of conformity.
Sources and editorial review
Content reviewed on 7 November 2026. The following primary sources provide the technical foundation; WAI tutorials explain implementation approaches and do not replace the normative standard.
