Choosing Website Colours: An Accessible Colour-System Guide

Choosing website colours is not simply a matter of placing several attractive swatches next to one another. Colour affects whether text can be read, whether an action can be recognised, whether error and success states can be distinguished, and whether the brand remains coherent across pages. A useful palette is therefore a system of named roles and usage rules, not a loose collection of hex values.

This guide does not promise a universal answer to “which colour converts best?” It provides a shared decision record for designers, content owners and developers. Colour alone does not guarantee trust, revenue, rankings or conversion. Outcomes still depend on the offer, content, user need, interaction design and technical implementation.

Define interface roles before selecting a palette

Start by listing the roles that the interface needs: page background, raised surface, primary text, secondary text, border, primary action, secondary action, link, keyboard focus, error, warning, success and disabled states. A single brand colour may not safely serve every one of these roles.

Functional names make implementation more durable. Tokens such as action-primary, text-link and focus-ring retain their meaning if the exact shade later changes. The design file, CSS variables and component library should use the same vocabulary so that a visual decision does not become an undocumented developer guess.

A brand colour is not automatically an interface colour

A shade that works well in a logo may not provide enough contrast for small text or a button background. The answer is not necessarily to abandon the brand colour. Define lighter and darker variants, neutral surfaces and approved text pairings. The core shade can remain prominent in suitable accents while an accessible variant performs the functional role.

Test the palette on at least three contexts: a light surface, a dark surface and an image or video. Text placed over imagery needs a repeatable overlay, shadow or solid backing rule. “Choose a suitable photograph” is not a reliable system because the content will change.

Measure contrast rather than judging it by eye

The WCAG 2.2 explanations use a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Meaningful graphical objects and visual information required to identify user-interface components are also considered against a 3:1 threshold in relevant cases. See the W3C guidance for minimum text contrast and non-text contrast.

These ratios are a baseline, not the entire review. Thin type, low screen brightness, sunlight and differences in colour perception can still make an interface difficult to use. Combine automated measurement with checks on representative devices and at browser zoom.

Do not communicate information through colour alone

A red border without an error message, a green dot without a label or a colour-only required-field indicator can remove information for some users. The W3C explanation of use of colour requires colour not to be the only visual means of conveying information in the covered situations.

Pair colour with text, an icon, a pattern, an underline or a clear position. A form error should include an explicit message near the affected field. Links need a distinguishable treatment appropriate to their context. Data visualisations should identify series through labels or patterns as well as hue.

Treat interaction states as part of the palette

A button has more than a default colour. It can have hover, keyboard focus, pressed, selected, loading and disabled states. If these states are absent from the system, teams tend to invent shades page by page and consistency erodes.

The keyboard focus indicator must remain visible on both light and dark surroundings. A disabled component should not merely look faint; it must behave as unavailable and, where necessary, explain why the action cannot be completed.

The Kumsal colour-system matrix

Record each colour role through five fields:

Including this matrix in the design handover gives developers the intent as well as the colour value. Use it with the professional web-design quality guide, the UI design guide and the UX design guide to connect colour decisions with broader acceptance criteria.

Do not treat colour meanings as universal rules

Claims such as “blue creates trust” or “red makes people buy” are not sufficient design evidence. Perception varies with culture, sector, surrounding colours, copy and component context. The same red may indicate an error in a form, emphasis in a campaign panel or the primary identity of a brand.

Test the context rather than assuming a universal meaning. Is the primary action distinguishable from secondary actions? Does a warning differ from success through wording and structure as well as hue? Do non-colour cues retain the meaning on localised pages? Representative task testing can inform the decision, but its result should not be presented as a universal colour-psychology law.

Test what happens when content changes

A colour system must survive real content, not only ideal design-file examples. A long button label, a two-line heading, a missing image, a new campaign card or a table added by an editor can alter the hierarchy. In a CMS, giving editors approved semantic roles and components is safer than exposing unrestricted colour selection.

Review at least one form, list, detail page, campaign component and system message during handover. When a theme or brand update changes a token, repeat automated contrast checks and include critical components in visual regression review. This turns the palette into a maintainable system rather than a one-off presentation.

Example colour-system acceptance scenario

Consider a proposal form with a primary button, link, required field, error and success message. Its acceptance record identifies the default and focus states, text-and-surface pairing, measured contrast and non-colour cue for each component. Complete the form with a keyboard, trigger an error, check the relationship between the message and field, and confirm that success is described explicitly rather than shown only as a green panel.

The scenario evaluates whether the system supports a real task, not whether individual swatches look attractive. The same method can be applied to basket, account, filtering and administration workflows.

Implementation and test checklist

1. 
   

   
   

2. List interface roles before selecting shades.

3. 
   

   
   

4. Define approved pairings for light and dark surfaces.

5. 
   

   
   

6. Measure text and non-text contrast.

7. 
   

   
   

8. Add a second signal for errors, success, warnings and selection.

9. 
   

   
   

10. Design hover, focus, active and disabled states.

11. 
    

    
    

12. Check important pages on real devices at high and low brightness.

13. 
    

    
    

14. Complete critical forms with a keyboard.

15. 
    

    
    

16. Keep design tokens and code variables aligned.

17. 
    

    
    

A successful colour system makes the brand recognisable without obscuring content or interaction. It moves the discussion from preference to roles, measurable thresholds, states and verification evidence.

Bir web sitesinde renk seçimi, beğenilen birkaç tonu yan yana getirmekten ibaret değildir. Renk; metnin okunmasını, bir butonun fark edilmesini, hata ve başarı durumlarının ayırt edilmesini ve marka kimliğinin sayfalar boyunca tutarlı kalmasını etkiler. Bu nedenle iyi bir palet, tek tek renklerden önce rolleri ve kullanım kuralları tanımlanmış bir sistemdir.

Bu rehberin amacı “hangi renk daha güzel?” sorusuna evrensel bir cevap vermek değil; tasarımcı, içerik ekibi ve geliştiricinin aynı karar setiyle çalışmasını sağlamaktır. Renklerin tek başına gelir, güven veya dönüşüm artışı yaratacağı varsayılmaz. Sonuç; içerik, teklif, kullanıcı ihtiyacı, etkileşim ve teknik uygulamayla birlikte değerlendirilir.

Renk paletinden önce arayüz rollerini belirleyin

İlk adım marka kılavuzundaki renkleri kopyalamak değil, arayüzde hangi rollerin bulunduğunu listelemektir. Genellikle zemin, yüzey, ana metin, ikincil metin, kenarlık, birincil eylem, ikincil eylem, bağlantı, odak, hata, uyarı, başarı ve devre dışı durumlar gerekir. Aynı marka rengi bu rollerin tamamını güvenli biçimde karşılayamayabilir.

Rengi adıyla değil rolüyle kaydetmek uygulamayı kolaylaştırır. mavi-500 yerine action-primary, text-link veya focus-ring gibi işlevsel adlar kullanıldığında daha sonra ton değişse bile bileşen mantığı korunur. Tasarım dosyasındaki bu roller CSS değişkenleriyle ve bileşen kütüphanesiyle aynı adlandırmayı izlemelidir.

Marka rengi ile kullanılabilir arayüz rengi aynı olmayabilir

Logoda iyi görünen bir ton, küçük metinde veya buton zemininde yeterli kontrast vermeyebilir. Çözüm marka rengini terk etmek değil; ana tonun açık ve koyu varyantlarını, nötr yüzeyleri ve uygun metin eşleşmelerini tanımlamaktır. Kurumsal renk vurgu alanlarında korunurken okunabilirlik gerektiren yerlerde sistemdeki uygun varyant kullanılabilir.

Palet en az üç bağlamda denenmelidir: açık zemin, koyu zemin ve fotoğraf ya da video üstü. Görsel üzerindeki metin için sabit bir kaplama, gölge veya metin arka planı tanımlanmadan yalnızca “uygun fotoğraf seçilir” demek sürdürülebilir bir kural değildir.

Kontrastı göz kararıyla değil ölçerek kontrol edin

WCAG 2.2 açıklamaları, normal metin için en az 4.5:1; büyük metin için en az 3:1 kontrast oranını temel alır. Kullanıcı arayüzü bileşenleri ve anlam taşıyan grafik nesneleri için de komşu renklere karşı 3:1 eşiği ele alınır. Ayrıntılar W3C minimum kontrast ve metin dışı kontrast açıklamalarında bulunur.

Bu oranlar son kontrol değil, başlangıç eşiğidir. İnce yazı tipi, düşük ekran parlaklığı, güneş ışığı ve renk algısı farkları kullanımı zorlaştırabilir. Bu yüzden tasarım, otomatik kontrast aracına ek olarak gerçek cihazlarda ve tarayıcı yakınlaştırmasıyla incelenmelidir.

Bilgiyi yalnızca renkle anlatmayın

Hata alanını yalnızca kırmızı kenarlıkla, başarıyı yalnızca yeşil noktayla veya zorunlu alanı yalnızca renk farkıyla belirtmek bazı kullanıcılar için bilgiyi ortadan kaldırır. W3C renk kullanımı açıklaması, rengin bilginin tek görsel aracı olmaması gerektiğini belirtir.

Renge metin, simge, desen, alt çizgi veya konum gibi ikinci bir işaret eşlik etmelidir. Örneğin form hatasında alanın yanında açık bir hata mesajı gösterilir; bağlantılar yalnızca farklı renge değil, bağlama uygun ayırt edici bir stile sahip olur; grafiklerde seri adı veya desen kullanılır.

Etkileşim durumlarını paletin parçası yapın

Bir butonun yalnızca varsayılan rengi yoktur. Üzerine gelme, klavye odağı, basılı, seçili, yükleniyor ve devre dışı durumları bulunur. Bu durumlar tasarım sisteminde tanımlanmazsa ekipler sayfa bazında rastgele tonlar ekler ve tutarlılık kaybolur.

Özellikle klavye odak halkası hem açık hem koyu zeminlerde fark edilmelidir. Devre dışı bileşenin soluk görünmesi tek başına yeterli değildir; bileşen gerçekten etkileşime kapalı olmalı ve gerekiyorsa neden kullanılamadığı açıklanmalıdır.

Kumsal renk sistemi matrisi

Her renk rolünü aşağıdaki beş alanla kaydedin:

Bu matris tasarım tesliminin parçası olursa geliştirici yalnızca hex kodları değil, kullanım niyetini de alır. Genel kaliteyi diğer kabul ölçütleriyle birlikte değerlendirmek için profesyonel web tasarım kalite rehberi, bileşen davranışları için UI tasarım rehberi ve kullanıcı akışları için UX tasarım rehberi birlikte kullanılabilir.

Renk anlamlarını evrensel kural gibi kullanmayın

“Mavi güven verir” veya “kırmızı satın alma isteği yaratır” gibi genellemeler, tasarım kararı için yeterli kanıt değildir. Rengin algısı kültüre, sektöre, komşu renklere, metne ve kullanıldığı bileşene göre değişir. Aynı kırmızı ton bir formda hata, bir kampanya alanında vurgu, kurumsal kimlikte ise ana marka rengi olabilir.

Bu nedenle “rengin anlamı” yerine kullanıcının karşılaştığı bağlam test edilir. Ana eylem diğer eylemlerden ayırt ediliyor mu? Uyarı, başarıdan yalnızca tonla değil mesajla da ayrılıyor mu? Uluslararası sayfalarda renk dışındaki işaretler aynı anlamı taşıyor mu? Gerekirse temsilî kullanıcılarla görev testi yapılır; sonuç evrensel psikoloji iddiası olarak sunulmaz.

İçerik değiştiğinde sistemin bozulup bozulmadığını deneyin

Renk sistemi yalnızca tasarım dosyasındaki ideal örneklerle değil, gerçek içerik varyasyonlarıyla denenmelidir. Uzun buton metni, iki satırlı başlık, eksik görsel, yeni kampanya kartı ve editörün eklediği tablo mevcut hiyerarşiyi değiştirebilir. CMS kullanan ekiplerin sınırsız renk seçmesi yerine onaylı rol ve bileşenleri seçmesi daha güvenlidir.

Teslim sırasında en az bir form, bir liste, bir detay sayfası, bir kampanya bileşeni ve bir sistem mesajı birlikte incelenmelidir. Tema veya marka güncellemesinde token değeri değiştiğinde otomatik kontrast kontrolleri yeniden çalıştırılır; kritik bileşenler görsel regresyon kontrolüne alınır. Böylece palet tek seferlik sunum değil, bakımı yapılabilir bir sistem olur.

Renk sistemi kabul senaryosu örneği

Bir teklif formunda ana buton, bağlantı, zorunlu alan, hata ve başarı mesajını ele alalım. Kabul kaydında her bileşenin varsayılan ve odak durumu, metin-zemin eşleşmesi, ölçülen kontrastı ve renk dışı işareti bulunur. Form klavyeyle doldurulur; hata oluşturulur; mesajın alanla ilişkisi ve odak hareketi kontrol edilir; başarı sonucu yalnızca yeşil bir alanla değil açık metinle bildirilir.

Bu senaryo, tek tek renklerin güzelliğini değil sistemin gerçek bir görevi destekleyip desteklemediğini gösterir. Aynı yöntem sepet, üyelik, filtre ve yönetim paneli akışlarına uygulanabilir.

Uygulama ve test kontrol listesi

1. 
   

   
   

2. Marka renklerini değil, arayüz rollerini listeleyin.

3. 
   

   
   

4. Her rol için açık ve koyu zemin eşleşmelerini belirleyin.

5. 
   

   
   

6. Metin ve metin dışı kontrastı ölçün.

7. 
   

   
   

8. Hata, başarı, uyarı ve seçim bilgisini ikinci bir işaretle destekleyin.

9. 
   

   
   

10. Hover, focus, active ve disabled durumlarını tasarlayın.

11. 
    

    
    

12. Sayfaları yüksek ve düşük parlaklıkta gerçek cihazlarla kontrol edin.

13. 
    

    
    

14. Kritik formları klavye ile tamamlayın.

15. 
    

    
    

16. Renk tokenlarını tasarım ve kod tarafında aynı adlarla saklayın.

17. 
    

    
    

Sonuçta başarılı renk sistemi, markayı görünür kılarken içeriği ve etkileşimi gölgelemez. Karar, kişisel beğeniden çıkarılıp roller, oranlar, durumlar ve test kanıtlarıyla yönetilir.