How to Share Website Color Scheme Rules with Your Team
When designers, developers, and content editors work on the same website, sending around a collection of color swatches may not answer practical questions: which blue is approved for purchase buttons, or may a new promotional banner introduce another color? The team needs more than a palette. It needs one shared set of rules covering color roles, combinations, and changes. Here is how to prepare and maintain one for a film-festival ticket-booking website.
Share each color’s role and combinations, not just its name
Start by choosing one reference document that everyone on the team can access. For each color, record its role, a consistent name, its HEX code, the components that use it, and the adjacent background or text colors it must work with. A HEX code is a way of specifying a web color using hexadecimal characters. Role names such as “Purchase action” and “Supporting text” tell people more than “Blue 1” or “Nice yellow.”
Document combinations that should not be used as well. For example, do not turn the pale Early Sale badge background into ordinary body text, and do not give purchase success and input errors the same notification treatment. Name the relevant screens so a developer knows where the rule applies and an editor can check it when preparing a new announcement.
Also agree on where the shared document lives and who updates it. One workable arrangement is for a designer to propose a color change and explain its purpose, a developer to review the affected components, and a content or operations editor to check the old and new appearances before release. The exact responsibilities can vary by team; what matters is that the current approved version is clear.
Example: a shared color table for a film-festival ticket page
Imagine a ticket page showing screenings in white cards, a Buy Ticket button, an Early Sale badge, and notifications about completed purchases or input errors. The table below pairs each color with its approved role so that the same decisions can be handed off between team members.
| Color role | Shared name | Color and HEX code | Where to use it |
|---|---|---|---|
| Page background | page-background |
#F5F7FA | Canvas around the page |
| Card background | surface-card |
#FFFFFF | Screening schedules and seat details |
| Main text | text-main |
#26384B | Headings and body text on white cards |
| Supporting text | text-sub |
#566779 | Venue and time notes on white cards |
| Purchase action | action-primary |
#1B5E88 | Buy Ticket button and underlined links |
| Action text | action-on-primary |
#FFFFFF | Text inside purchase buttons |
| Input border | border-input |
#738699 | Boundary of white inputs on the pale page |
| Early-sale badge background | badge-early-bg |
#FFF1D7 | Early Sale label on a screening card |
| Early-sale badge text | badge-early-text |
#754A16 | Text reading “Early Sale” |
| Purchase-success background | success-bg |
#E9F6EF | Notification after payment confirmation |
| Purchase-success text | success-text |
#176446 | Text reading “Purchase complete” |
| Error background | error-bg |
#FDEDED | Notification when information needs correction |
| Error text | error-text |
#A12634 | Text identifying the information to correct |
On a white card #FFFFFF, main text #26384B has a contrast ratio of approximately 12.00:1, and supporting text #566779 has approximately 5.81:1. The purchase button pairs a blue background #1B5E88 with white #FFFFFF text, approximately 6.99:1. If the same blue is used for a link on a white card, include an underline rather than making color the only cue that it is clickable.
The Early Sale badge combines a pale gold background #FFF1D7 with dark-brown text #754A16, providing approximately 6.85:1. However, the badge fill contrasts with the surrounding white #FFFFFF by only about 1.12:1. Keep the “Early Sale” wording visible instead of using the tint alone to indicate the offer.
A confirmed-purchase message can use pale green #E9F6EF and dark green #176446 with approximately 6.41:1 contrast. An input-error message can use pale red #FDEDED and dark red #A12634 with approximately 6.51:1. Labels such as “Purchase complete” and “Please review your details” make each meaning explicit in text.
The pale page background #F5F7FA and white cards #FFFFFF differ by only about 1.07:1. Where a recognizable input outline is necessary, use #738699: it contrasts with the white inside of the input by approximately 3.75:1 and with the surrounding pale page by approximately 3.49:1. This is why the shared rules should include both neighboring colors and the purpose of the element, not an isolated color code.
Agree on how changes are proposed, checked, and published
Suppose a content editor wants to recolor the Buy Ticket button for an autumn promotion. Instead of adding an unreviewed color, they can propose a HEX value in the shared document, identify the pages it would affect, and specify how long the exception should last. The developer checks whether that action color also appears on links or fixed mobile buttons. After approval, the team updates both the reference document and the actual site, recording the change date and reason.
Before publication, check the real page: ordinary text on its background, labels on action buttons, necessary input outlines, and success and error messages. Under WCAG (Web Content Accessibility Guidelines) 2.2 Level AA, normal text generally needs at least 4.5:1 contrast against its background and qualifying large text at least 3:1. Essential non-text information, such as some input outlines, generally needs at least 3:1 against adjacent colors. The ratios above are calculated for opaque solid-color pairs and do not establish accessibility conformance for an entire site.
HueRoll can help you inspect HEX codes, lighter and darker color suggestions, and contrast against white or black. It does not directly compare two arbitrary custom colors or automatically determine AA or AAA conformance. Its My Palette saves colors in a cookie in the current browser, without automatic synchronization between team members. Record approved values in your team’s shared document, and check the actual adjacent-color combinations separately.