Brand color accessibility checks for websites: a practical workflow

Brand color accessibility checks for websites: a working method designers can trust

A redesign looked finished on a Friday afternoon and fell apart on Monday morning. A product manager opened the new homepage on a calibrated office monitor and the primary call-to-action button nearly disappeared against the hero background. The brand orange, the one everyone had defended in three meetings, registered at a contrast ratio of 2.1 to 1. WCAG 2.2 asks for 4.5 to 1 against adjacent text, and 3 to 1 for non-text components such as icons and button borders. The launch was delayed for ten days while the team rebuilt a second palette.

That kind of failure is not rare. Color is one of the few brand assets that can pass an art review and still lose a usability audit, and the people most affected are readers with low vision, color vision differences, and users in bright sunlight. Brand color accessibility checks for websites are the structured tests that close that gap between brand approval and real-world reading conditions. They treat a palette as a functional product, not a decoration, and they give a design system a repeatable way to say yes or no to a swatch.

This guide walks through a working method for those checks. It starts with the standards, moves into the practical ratios, covers non-text components, dark mode, motion, and data visualization, and ends with a checklist you can run before any release. It is written for designers, brand leads, and front-end developers who own the look of a site and need it to work for everyone who lands on it.

What the standards actually require

Two documents shape most of the rules: the Web Content Accessibility Guidelines, currently at version 2.2, and the older Section 508 regulations in the United States that point back to those same guidelines. WCAG 2.2 organizes requirements under four principles, and color sits inside the first principle, Perceivable, under the success criterion 1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast.

There is a useful distinction in those criteria between text and everything else. Text is judged at a stricter threshold because it carries meaning, while non-text elements like icons, form borders, and focus rings are judged at a softer threshold because users can still glean meaning from shape, position, and label. Both matter for brand color accessibility checks for websites, and a passing text ratio does not automatically pass a non-text element.

Another useful framing comes from the W3C’s own explanation pages, which separate luminance (how light or dark a color is in technical terms) from hue (the color family such as red or green). A color that fails for one reader may not fail for another. Roughly 8 percent of men and 0.5 percent of women of Northern European descent have some form of color vision deficiency, and the global numbers shift with population mix. The contrast ratio is a more reliable baseline than guessing about hue combinations.

The contrast ratio, explained without the math headache

Every brand color accessibility check for websites starts with the contrast ratio. The WCAG formula is:

(L1 + 0.05) divided by (L2 + 0.05), where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color. Relative luminance is a weighted average of the red, green, and blue channels after gamma correction. The result is a number between 1 and 21.

The thresholds you need to remember are simple. Normal body text needs 4.5 to 1 against its background. Large text, defined as 18 point regular or 14 point bold (about 24 pixels regular or roughly 18.66 pixels bold), needs 3 to 1. Non-text components and graphical objects need 3 to 1 against adjacent colors. There is an enhanced ratio at 7 to 1 for normal body text and 4.5 to 1 for large text, useful for AAA targets in long-form reading.

Two practical points often get missed:

• Brand color accessibility checks for websites must test the color as it actually appears on the page, not the swatch in the Figma file. Transparency, blend modes, and the underlying background all change the effective color.
• Anti-aliasing softens edges and effectively lowers the contrast you measure. A solid 4.5 to 1 ratio on paper can feel like 4.3 to 1 in a browser. Aim for a small buffer, around 0.2, on critical text.

A small worked example with three brand colors

Imagine a brand system built around three colors: a deep navy, a warm orange, and a soft cream. The first step is to measure each against the others and against the neutral backgrounds actually used on the site.

Pair	Hex values	Ratio	Normal body text	Large text	Non-text element
Navy text on cream	#0F2A4A on #F5EFE3	13.4 to 1	Pass	Pass	Pass
Orange text on cream	#E26A2C on #F5EFE3	3.4 to 1	Fail	Pass	Pass
Orange text on navy	#E26A2C on #0F2A4A	4.8 to 1	Pass	Pass	Pass
Cream text on orange	#F5EFE3 on #E26A2C	7.3 to 1	Pass	Pass	Pass

That table shows a common pattern. The orange works as a background for cream text and as a button background with white text, but it fails on cream for body copy. Brand color accessibility checks for websites need to record which role each color plays, because the same swatch can be a hero, an accent, or a failure depending on what sits next to it.

Tools that actually speed the work up

A reliable toolkit mixes a Figma plugin, a browser extension, and a script that runs on real pages. The list below is not exhaustive, but it covers the categories most teams end up with.

• Stark (Figma, Sketch, Adobe XD): measures contrast inside the design file, flags failing text and components, and simulates color vision deficiencies. It is useful in the design phase before a single line of CSS is written.
• axe DevTools (browser extension): audits live pages against WCAG 2.2, including color contrast, and reports each failure with the exact element selector.
• Lighthouse (Chrome DevTools): includes a contrast check among its accessibility audits. It is less detailed than axe but runs in seconds.
• WebAIM Contrast Checker (web): a quick two-field checker that also shows the result against the three common color vision simulations.
• Polypane (browser): a multi-pane browser for visual testing, with built-in contrast overlays and a deficiency simulator.
• A small in-house script: a Node or Python script that crawls a staging URL, reads computed styles, and logs any color pair that falls below threshold. This catches hard-coded values that escape the design tokens.

For a single source of truth on the standard, the W3C Web Content Accessibility Guidelines page on contrast is the right starting point. The W3C is a useful anchor because it maintains the working drafts and errata that no third-party blog can match.

Why text contrast is only half the job

Success criterion 1.4.11 is the one that catches a lot of design systems out. Non-text elements such as icons, form field borders, button states, and charts also need a 3 to 1 contrast against adjacent colors. The reasoning is that a user with low vision has to identify the element by its edge, not by reading the word on it. A ghost button that is just a one-pixel outline in the brand color can vanish against a photograph on the hero.

Brand color accessibility checks for websites should cover at least these element types:

• Primary, secondary, and tertiary button states, including hover and focus.
• Form field borders, focus rings, and error states.
• Icon-only controls in the navigation, footer, and product UI.
• Link color in running text, including visited states.
• Chart strokes, axis lines, and legend swatches in data visualization.
• Status badges, tags, and notification pills.

A button label is text, but the border and the icon are non-text. The two checks can return different verdicts on the same swatch. The safe pattern is to set the button background to a token that already passes text contrast and then pick a border color that passes against both the background and the underlying surface.

Building a contrast-friendly palette from scratch

It is easier to design accessibility in than to fix it later. A useful method starts with two neutrals, picks one accent that meets the strictest threshold against both, then layers supporting tones. The example below uses a small, intentional system.

Token	Hex	Role	Tested against	Ratio	Verdict
surface-base	#FFFFFF	Page background	—	—	Reference
surface-sunken	#F2F4F7	Card and panel background	—	—	Reference
ink-primary	#0B1B33	Body text	surface-base	17.2 to 1	Pass AAA
ink-secondary	#3D4D63	Secondary text	surface-base	8.6 to 1	Pass AAA
accent-primary	#1E4FD8	Links and primary button	surface-base	7.0 to 1	Pass AAA
accent-primary	#1E4FD8	Links and primary button	surface-sunken	6.3 to 1	Pass AAA
accent-warn	#A8430B	Warning state and badge	surface-base	5.1 to 1	Pass AA

That table is also a contract. The next time someone suggests a tweak to the warning color, the verdict column forces a conversation. Brand color accessibility checks for websites work best when the table lives next to the design tokens, not buried in a one-off audit report.

Where hue, not luminance, still matters

Contrast ratio is a luminance measure, which means two colors with the same ratio can still confuse a reader with red-green color vision deficiency. Imagine a status page that uses red for “down” and green for “up” with no icons and no text. The luminance difference may be fine, and the contrast against the page background may be fine, and a reader with deuteranopia or protanopia will still see two colors that look the same.

The fix is not to abandon the brand palette, but to pair it with a second signal. Brand color accessibility checks for websites should ask three questions for any state or category that uses color alone:

• Is there a text label or icon that conveys the same meaning?
• Is the state difference reinforced by shape, position, or pattern?
• Does the color choice keep a useful luminance difference, so high-contrast mode users also benefit?

Color is a fast and beautiful signal, and it should stay in the design. It should never be the only signal.

Dark mode and the inverse problem

Inverting a palette is the most common mistake in dark mode. Brand color accessibility checks for websites have to be re-run on the dark surfaces, because a color that passes at 7 to 1 on white can fail at 2.5 to 1 on a near-black background. Light-mode tints need a darker version for dark mode, not the same swatch.

Two practical rules help:

• For dark mode, lower the lightness of accent colors by around 10 to 15 percent and re-test against the new surface. Pure white text on a pure black background is too sharp and causes halation for some users with astigmatism; aim for a soft white like #E6E8EC on a near-black like #0E1116, which measures around 14.8 to 1.
• Treat dark mode as a separate palette with its own token names, such as accent-primary-dark, rather than reusing the light-mode token. The audit script then has to test both sets, which is a small extra cost and a major reliability gain.

A useful overview of how color contrast behaves across modes is the W3C page on Web Content Accessibility Guidelines, which is the same standard for both modes and which the rest of the design system should be measured against. Wikipedia’s entry on web accessibility offers a short orientation for readers who want a one-page summary of the broader context beyond color.

Data visualization, charts, and infographics

Charts are where brand color accessibility checks for websites earn their keep. A line chart with four series in light blue, sky blue, teal, and mint may look harmonious on the designer’s monitor and look like a single color to a reader with tritanopia. The fix is to test with a deficiency simulator and add a redundant encoding such as line dash style, marker shape, or direct labels at the end of each series.

Heatmaps and choropleths are even harder. They rely on a sequential color ramp to communicate value, and the ramp has to maintain contrast against the legend and the surrounding chart elements. Two patterns work well:

• Use a perceptually uniform ramp such as Viridis, Cividis, or a custom ColorBrewer-style ramp. These ramps are designed to look ordered even in grayscale, which is the closest thing to a universal accessibility win in data visualization.
• For categorical charts, pick a palette from a tested set like Wong’s eight-color palette or the Okabe-Ito palette. Both are designed for color vision deficiencies and have luminance differences that survive most simulations.

Test every chart with a deficiency simulator before it ships. It takes two minutes and catches the most common complaint from users, which is that two adjacent series in a dashboard look identical.

Motion, focus, and the colors that show up only on interaction

Some brand colors live only at the moment of interaction. The focus ring, the hover state, the loading spinner, the drag-and-drop highlight, and the selection background are all part of the brand color system, and they are easy to forget in the design tokens.

Three checks keep these colors honest:

• Focus rings: the focus indicator must have a 3 to 1 contrast against the surface it sits on, and it must be visible on every interactive element, including custom controls. Removing the default browser outline and replacing it with a low-contrast brand color is a common failure pattern.
• Hover and active states: if the hover state changes only the background color, the text on top still has to meet the 4.5 to 1 threshold. A 10 percent darken or lighten of the background can break contrast against a body text color that was fine on the resting state.
• Loading and progress indicators: the moving bar or spinner needs to read against its track and against the page background. A neon brand color on a white track often fails; a darker or more saturated version of the brand color usually passes.

What the audit actually looks like on a live site

A practical audit has four steps and takes about an afternoon on a small site or two days on a large one.

1. Pull the design tokens. Export the color tokens from the design system file into a single JSON or CSV file. Include the hex value, the role, and the intended surface for each token.
2. Pair every token against every surface. A short script can run the WCAG contrast formula on every combination and flag the pairs that fall below threshold. The output is a table, similar to the ones in this article, that the design lead can read in minutes.
3. Run the page audit. Open the live site in a browser with axe DevTools and a color deficiency simulator. Walk through the homepage, a content page, a form, a checkout or signup, and any data-heavy page. Log every visual failure with a screenshot and a selector.
4. Re-test the changes. After the design and engineering team adjusts the tokens, re-run steps 2 and 3. Keep a short release note that lists which token values changed and which components were affected.

Brand color accessibility checks for websites are not a one-off project. They belong in the release checklist, the design system governance, and the front-end component library, in the same place where button styles and spacing rules already live.

Common patterns that fail and how to fix them

There is a small library of mistakes that come up again and again across sites. The list below is drawn from that library, with the fix that most often works without a brand overhaul.

• Light gray placeholder text on white. A 9-pixel placeholder at #BBBBBB on white measures about 1.6 to 1. Raise the placeholder color to at least #6B7280 for a 4.6 to 1 ratio, or keep the lighter color only for truly empty fields and add a visible label that meets contrast.
• Disabled buttons that look like ghost buttons. A 50 percent opacity brand color over a light surface can fall below 3 to 1. Use a separate, lower-saturation token for the disabled state, and add a label or icon change so the meaning is clear without relying on color alone.
• Toast messages on colored backgrounds. A green success toast with white text can pass against pure white but fail against a soft tint or a photograph in the background. Pin toasts to a solid surface token rather than a transparent overlay, and re-test the text against the new surface.
• Brand color links in body copy. A link color that passes against white can fail when a paragraph sits on a tinted callout background. The link color and the callout background need their own test, and the design system needs a token that works on both.

Each of these patterns has the same shape: a color choice that worked in one context and was assumed to work in another. The fix is always a token plus a documented test.

Working with brand teams who are protective of color

Brand color accessibility checks for websites can feel like a critique of the brand itself. They are not. They are a translation of the brand into the medium of a screen, where lighting, glare, vision differences, and assistive technology all change the rules. The conversation that tends to work best is to show, not argue. Pick the most-used brand color, test it against the most common surface, and put the failing pair in front of the brand lead on a phone in bright sunlight. The fix usually becomes obvious.

A second approach is to keep the brand color as an accent and introduce a near-neighbor that meets contrast. Many brand oranges, teals, and magentas have a darker relative that still feels like the same family. Tools like Stark’s color suggestion feature, or a hand-tuned HSL adjustment, can produce a swatch that passes the test and stays within a few degrees of the original hue. The brand gets a larger system; the design gets a passing test; the readers get a usable site.

How this connects to the rest of the design system

Color is one of the most cross-cutting tokens in a design system, and brand color accessibility checks for websites sit at the intersection of typography, components, and motion. The checks feed into the same governance that already reviews icon set changes and type scale changes. A useful internal page to keep nearby is the studio’s broader accessibility guide, which covers keyboard navigation, semantic HTML, and screen reader behavior, all of which matter when color is unavailable.

Two pieces from the studio’s working library pair well with this article. The web accessibility guide covers the rest of WCAG 2.2 and is the right next read for a team that has just finished a color pass. The visual identity guide is the right earlier read for a team that is building a brand system from scratch and wants to set the color tokens with accessibility built in from the first commit.

Used together, those pages form a small path: pick the brand colors, test them, ship the components, audit the live site, and re-test after every change. The pattern is the same one any design system uses for spacing or type. Color just needs the same care.

A short pre-release checklist

Before any release that changes a color token, a component, or a layout surface, run the list below. It is short on purpose, so it actually gets used.

• Every new color token has a documented role and a tested contrast pair for both light and dark surfaces.
• Every text color passes 4.5 to 1 against its background at the smallest body size used on the page, with a 0.2 buffer to account for anti-aliasing.
• Every large text color passes 3 to 1 against its background.
• Every icon, border, and chart element passes 3 to 1 against the adjacent surface.
• Focus indicators are visible on every interactive element, with at least 3 to 1 contrast.
• Hover and active states keep text and non-text contrast above threshold.
• Status colors are paired with text, icon, or shape so the meaning is clear without color.
• The release is tested with a color vision deficiency simulator and in a high-contrast browser mode.

If any item fails, the release does not ship. The fix is usually a token change rather than a component rewrite, and the change is small enough to test in an afternoon.

Limitations to keep in mind

Contrast ratio is a necessary baseline, not a complete picture. It does not measure reading comfort, which depends on line length, line height, font choice, and the visual weight of the body text. It does not measure the experience of users with low vision who use zoom or screen magnification, where a 200 percent zoom changes the effective size of text and the layout around it. It does not measure the experience of users with cognitive or neurological conditions, where subtle color cues can be more confusing than helpful.

Brand color accessibility checks for websites also depend on calibrated monitors. A color that measures 4.5 to 1 on a well-calibrated display can look very different on a cheap laptop screen. The audit script can only test the values in the CSS, not the screen the reader happens to be using. Pair the automated checks with a quick visual review on at least two devices, one bright and one dim, before signing off.

Frequently asked questions

What contrast ratio does WCAG 2.2 require for body text on a website?

WCAG 2.2 asks for 4.5 to 1 for normal body text and 3 to 1 for large text, which it defines as 18 point regular or 14 point bold and above. The ratio is between the text color and the immediate background. The same standard applies in dark mode; a palette has to be re-tested against the dark surface tokens, not assumed to work from the light mode test.

Do brand color accessibility checks for websites also cover icons and buttons?

Yes. Success criterion 1.4.11 sets a 3 to 1 ratio for non-text components such as icons, form field borders, and graphical objects against adjacent colors. A button label is text and uses the 4.5 to 1 threshold, but the button border, the icon inside, and the focus ring use the 3 to 1 threshold. Both checks belong in any audit of a design system.

How do color vision deficiencies change the rules for a brand palette?

Color vision deficiencies do not change the contrast thresholds, because the thresholds are based on luminance rather than hue. They do change the meaning of color-only signals. A status page that uses red and green with no text label or icon will confuse readers with red-green deficiencies, even if both colors pass the contrast test. Pair color with shape, label, or position so the meaning survives in a deficiency simulation.

Can a brand color that fails contrast be used somewhere on the site?

Yes, in a constrained role. A swatch that fails for body text can still work for a large heading, a decorative background, an icon, or a hover state on a darker surface, as long as that role passes its own threshold. The useful pattern is to keep the original brand color in the design system with a clear note on which role it can play, and to introduce a near-neighbor token for any role where the original fails.

How often should a team re-run brand color accessibility checks for websites?

Run the checks at three points. First, when the design system adds or changes a color token. Second, when a component is added to or removed from the library, since that changes which surfaces the token has to work against. Third, before any release that touches a page template, a chart, or a form. A quarterly full audit is a useful addition, because the contrast formula does not change but the content and the screens do.

What is the difference between AA and AAA contrast targets?

AA is the standard most public-sector and consumer sites aim for. Normal body text at 4.5 to 1, large text at 3 to 1, and non-text components at 3 to 1. AAA is a stricter enhanced target, with normal body text at 7 to 1 and large text at 4.5 to 1. AAA is harder to reach with brand colors and is usually applied to long-form reading surfaces rather than the whole site.

Do I need separate color tokens for dark mode?

In practice, yes. Light-mode accents often fail against dark surfaces, and reusing the same token in both modes is the most common reason a dark mode launch feels washed out or unreadable. The reliable approach is to define a parallel set of tokens such as accent-primary-dark and to run the same contrast checks against the dark surface tokens. The audit script then has to test both palettes, which is a small cost for a much more reliable result.

Are automated contrast checkers enough, or does a human need to review?

Automated checkers are necessary but not sufficient. They catch the failures in the CSS and the rendered DOM, and they do it quickly. They do not catch a layout where a 4.5 to 1 ratio technically passes but a 14-pixel body text in a thin weight becomes hard to read. Pair the script with a short visual review on at least two devices, one bright and one dim, and with a deficiency simulation, before each release.

What is the fastest way to start if the current site has many contrast failures?

Triage. Pull the design tokens, run the automated script on every combination, and rank the failures by traffic. Fix the highest-traffic pages and the most visible components first, which is usually the body text, the primary button, and the navigation links. The largest visible win is often a single body text color change that also raises the contrast for hundreds of pages at once.

How do brand color accessibility checks for websites fit with other accessibility work?

They are one part of a broader accessibility program that also covers keyboard navigation, semantic HTML, alt text, captions, form labels, and screen reader behavior. The color work tends to surface first because it is the most visual and the easiest to test with a script. The same governance, release checklist, and audit rhythm that catch color failures can be extended to the rest of the WCAG 2.2 criteria without much extra cost.

Related reading

• Gaming keyboard choices: switches, layouts, and features that actually matter
• Motion design: what it is and how to use it in a digital product