Using the 60-30-10 Color Rule on a Website

What the 60-30-10 rule means for a website

The 60-30-10 color rule is a simple planning split: approximately 60 parts for a dominant color, 30 for a supporting color and 10 for an accent. On a website, it can prompt a useful hierarchy question: what should stay calm, what should support the content and where should emphasis help the reader act?

Treat the split as a sketch rather than a technical requirement. It is not a WCAG criterion, a measured optimum for every website or proof that a particular layout converts better. Start with the page’s actual task. A long explanation, an ordering page and a dense dashboard have different amounts of text, controls, imagery and supporting information.

Three planning categories also do not mean exactly three CSS color values. Text on the dominant field needs a foreground; text on the accent may need a different one. Borders, focus, errors and other meaningful states need their own decisions. Keep those roles explicit instead of forcing them into a decorative percentage.

The examples use fictional Cedar Desk Sessions, a workshop information page. Its names, colors, sketches and allocations are original teaching choices. No live client page, audience study or sales result is being reported.

Assign color jobs before counting area

In this example, cream gives ordinary copy a reading field, slate separates supporting information, and dark orange gives a labelled action or underlined link a deliberate appearance. Charcoal copy on the two light surfaces and white on dark orange are separate foreground/background decisions. The colors’ names do not establish their suitability; the actual pairs need checking.

Carbon’s color overview distinguishes a role from its value and uses neutral dominance with purposeful action colors in its own themes. Material Web likewise maps color tones to specific component roles and corresponding content colors. Those systems support planning by purpose; they do not prescribe this example’s three values or an exact 60-30-10 ratio for your page.

Keep semantic meanings separate from a broad brand accent. An error, a selected option and a decorative stripe do different jobs even if they happen to share a hue. Write the visible label or other cue that preserves each meaning, and assess the actual component and state.

Compare two layouts while preserving the roles

The desktop sketch places the “What to bring” panel beside the main explanation. The phone sketch places it below that explanation. Its heading still tells readers why the information is there, and “View details” remains a visible action label. The arrangement changes without redefining what the colors mean.

Review the narrow layout with real content, including longer headings and expanded instructions. Text wraps, a sidebar stacks and the visible screen includes a different portion of the document. Forcing every screenshot to preserve the same percentage can shrink copy or hide a useful instruction for no reader benefit.

Do not remove required content to make an accent look rare. If every panel competes for attention, first identify which information belongs to the main task and which can move to a supporting position. Adjust emphasis for that reason, then check the result at the viewport and content state you are actually designing.

Explore a chosen allocation without pretending to measure the page

Enter three whole-number weights from 0 to 1000, with at least one above zero. The explorer divides each weight by the total and multiplies by 100. A 12 / 6 / 2 choice therefore gives the same 60 / 30 / 10 allocation as 60 / 30 / 10. The numbers define an illustrative budget, not pixels measured from your website.

Try a reading-heavy 80 / 15 / 5 sketch, then a zero-accent 80 / 20 / 0 sketch. Neither is automatically better. Use them to ask whether the proposed emphasis fits the task. The bar changes; the original desktop and phone diagrams remain role-placement examples, rather than secretly becoming measurements of those inputs.

The calculation uses unrounded shares; the visible labels round to one decimal place. Three equal weights display as 33.3% each, so their displayed sum can be 99.9% even though the underlying shares total 100%. Do not report those labels as precision measurements of a rendered interface.

Define a scope before discussing real area. A screenshot can include photographs, letter shapes, borders, overlays and many shades. Nested rectangles overlap; a card occupies space inside the page field rather than adding new page area. Viewport and scroll position also change the visible denominator. This tool measures none of those things.

Check the actual text pairs separately from the ratio

The first five pairs exceed 4.5:1 using the unrounded WCAG sRGB calculation. The pale-gold counterexample is deliberately listed as below the ordinary-text threshold; it is not used for white text in the sketches. An accent occupying only a small part of a layout can still make its label hard to read.

WCAG Contrast (Minimum) generally requires at least 4.5:1 for ordinary text and images of text, with defined exceptions. Large-scale text has a 3:1 threshold and a specific size/weight definition, generally at least 18 point regular or 14 point bold. Calling something a heading does not establish that it qualifies. The table checks every example against the ordinary-text threshold.

The method converts the specified sRGB channels to relative luminance and divides lighter luminance plus 0.05 by darker luminance plus 0.05. Only the displayed ratio is rounded. A result below 4.5 does not pass because its label rounds to 4.50. Changing either foreground or background creates a new pair to check.

These calculations assume solid, opaque colors. A photograph, transparency or gradient changes the actual background. Assess the implemented text instead of transferring the flat-color result to a different situation. If you change the palette, use the editable color usage guide to check its named pairs and document the change.

When to adjust the split and what still needs checking

Increase quiet reading space when the page’s useful content needs it. Move a supporting panel below the main task when a narrow layout benefits from that order. Reserve stronger emphasis for a clear, named action rather than repeating bright fills on every card. These are design decisions to examine in context, not new universal percentage prescriptions.

Allow product imagery or a photograph to contribute its own colors while keeping information on suitable surfaces. Do not distort every image to fit a three-color quota. Similarly, a dense data display may require labelled series and distinct meaningful cues that are separate from the website’s brand accent.

Assess links, focus and other component states individually. WCAG Non-text Contrast addresses visual information needed to identify controls, states and meaningful graphics, generally at least 3:1 against adjacent colors, with defined exceptions. It does not impose an identical border requirement on every decorative rectangle, nor require a default and hover color to contrast with one another when they are not adjacent.

WCAG Use of Color asks for an additional visible means when color alone communicates information or a particular meaning. Keep a selected option visibly identified and an error usefully explained. A favorable area allocation and text-pair table leave reading order, keyboard operation, resizing, labels and other requirements to be assessed on the actual page.

Treat a dark theme as a separate set of surfaces, foregrounds and states. Preserve the roles where useful, but do not assume that reversing a light sketch supplies a tested dark design. Record what changed and which real presentation still needs review.

Six website color decisions with explained answers

These invented cases distinguish area planning from contrast, meaningful cues and responsive layout. Choose an answer before opening the explanation. None describes measured audience behavior or a verified client design.

Keep a usable layout-color record

Download the role record, six cases with answers and exact example pair values. Record the page’s task first, then assign the dominant, support, accent and additional component roles. Keep the planning scope and outstanding checks visible.

Page and reader task:
Viewport/content state being reviewed:
Dominant reading surface and exact text pair:
Supporting field, purpose and phone placement:
Accent, visible action label and text pair:
Other text, focus, selected/error and image roles:
Chosen allocation scope (sketch, not measured coverage):
Contrast pairs checked and outstanding implementation checks:
Change, reason and next review:

Finish with a reason another person can apply: “Keep the long explanation on the cream field; stack the preparation panel below it on a phone; preserve the checked labelled action.” That is more usable than asking someone to recover an unexplained screenshot percentage after every content edit.

If you later change a surface, recalculate its text pairs and inspect affected components. If you change the page’s content or task, reconsider the arrangement. The allocation sketch can help start that review; it should not prevent an adjustment that makes the information easier to use.