Web Tasarımında Renk Kontrastı: Kontrast Hataları Nasıl Test Edilir ve Düzeltilir

Telefonunun parlaklığı sonuna kadar açılmış halde, güneş alan bir kafede oturan, düşük görme yetisine sahip bir ziyaretçinin web sitenize indiğini hayal edin. Açık gri gövde metniniz beyaz bir arka planın üzerinde duruyorsa, içeriğinizi okuyamaz — her kelimeyi ne kadar özenle yazmış olursanız olun. Bu senaryo varsayımsal değil: 2026 başı itibarıyla, en popüler bir milyon ana sayfanın %83.9’unda düşük kontrastlı metin tespit edildi; bu da onu art arda yedinci yıl boyunca web’de en sık tanımlanan erişilebilirlik hatası haline getiriyor; her sorunlu ana sayfada ortalama 34 ayrı örnek bulunuyor.

Renk Kontrastı Sandığınızdan Daha Fazla Neden Önemli

Çoğu insan, kontrast sorunlarının yalnızca tamamen kör olan veya ekran okuyucu kullanan kullanıcıları etkilediğini varsayar. Gerçek çok daha geniştir. Dünya çapında yaklaşık 300 milyon insanın bir tür renk görme bozukluğu vardır ve çok daha fazlası düşük kontrastı günlük bir sürtünme noktası olarak yaşar — ucuz monitör kullananlar, yaşlanan gözlere sahip olanlar veya parlak bir günde dışarıda gezinirken ekranına bakan herkes. Düşük görme, tam körlüğe kıyasla çok daha yaygındır: Görme yetisi hiç olmayanlara kıyasla neredeyse üç kat daha fazla insan düşük görme yetisine sahiptir.

WCAG’in kontrast eşiklerinin arkasındaki araştırma bunu somutlaştırır. Standart metin için 4.5:1 minimum oran, görmesi yaklaşık 20/40 seviyesine eşdeğer olan birinin tipik olarak yaşadığı kontrast duyarlılığı kaybını telafi edecek şekilde kalibre edilmiştir — bu, genellikle seksenlerindeki insanlar için bildirilen görme keskinliğidir. WCAG’in daha sıkı 7:1 Seviye AAA eşiği de benzer şekilde kalibre edilmiştir: Yardımcı teknolojiler kullanmayan, düşük görme yetisine sahip kişilerdeki kontrast duyarlılığı kaybını telafi etmek için, görmesi 20/80 seviyesine eşdeğer olan kullanıcıları hedefler.

Ayrıca çok gerçek yasal ve ticari sonuçlar da vardır. Amerika Birleşik Devletleri’nde erişilebilirlik davaları 2024’te 4,605 ADA dijital erişilebilirlik başvurusuna ulaştı ve Avrupa Erişilebilirlik Yasası Haziran 2025’te yürürlüğe girerek zorunlu uyum yükümlülüklerini çok çeşitli ticari web siteleri ve uygulamalara genişletti. Renk kontrastı hataları tespit edilebilir, belgelenebilir ve davalarda rutin olarak atıf yapılır. Uyum yöneticileri için bu, bunları düzeltmeyi “güzel olur” değil, bir öncelik haline getirir.

Son olarak, erişilebilir kontrast basitçe iyi tasarımdır. Yüksek kontrastlı metin herkes için taramayı kolaylaştırır, bilişsel yükü azaltır ve genel olarak okuma hızını artırır — bu da onu uyum yükümlülüğü kadar bir iş performansı iyileştirmesi haline getirir.

Gerçekte Bilmeniz Gereken WCAG Kontrast Kuralları

WCAG 2, kontrastı iki renk arasındaki algılanan parlaklık farkının bir ölçüsü olarak tanımlar. Formül, bir ön plan renginin göreli parlaklığını arka planına göre karşılaştırır ve sonucu 1:1’den (hiç fark yok — beyaz üzerinde beyaz) 21:1’e (maksimum fark — beyaz üzerinde siyah) uzanan bir oran olarak ifade eder. Bunu manuel olarak hesaplamanız gerekmez; önemli olan hangi oranların ne zaman gerektiğini anlamaktır.

WCAG 2.x Seviye AA kapsamında — çoğu yasa ve erişilebilirlik standardında atıf yapılan seviye — gereklilikler şu şekilde ayrılır:

• Normal metin (gövde metni, etiketler, 18pt altı veya 14pt kalın altı arayüz metni): arka plana karşı minimum 4.5:1 kontrast oranı.
• Büyük metin (en az 18pt / 24px veya 14pt / ~18.66px kalın): minimum 3:1 kontrast oranı. Mantık, daha büyük harf biçimlerinin doğası gereği ayırt edilmesinin daha kolay olması, dolayısıyla daha gevşek bir eşiğin haklı görülmesidir.
• Metin dışı arayüz bileşenleri ve bilgi amaçlı grafikler (WCAG 2.1 ile gelen Başarı Ölçütü 1.4.11): bitişik renklere karşı minimum 3:1 kontrast oranı. Bu, form girdi kenarlıkları, odak göstergeleri, yalnızca ikon içeren düğmeler ve veriyi anlamak için gereken grafik parçaları gibi öğeleri kapsar.

Seviye AAA kapsamında çıta daha yüksektir: normal metin için 7:1 ve büyük metin için 4.5:1. Seviye AAA nadiren bütünüyle zorunlu kılınsa da, okuma doğruluğunun kritik olduğu metin ağırlıklı sayfalar veya kullanıcı arayüzleri için bir tasarım hedefi olarak ele almaya değerdir.

Önemli nüans: WCAG “büyük metni” CSS’inizdeki değere göre değil, tarayıcıda işlenen boyuta göre tanımlar. 1.2rem olarak ayarlanmış bir font, kullanıcının tarayıcı temel font boyutuna bağlı olarak büyük metin sayılabilir de sayılmayabilir de. Emin olmadığınızda 4.5:1 eşiğini uygulayın ve gerçek işlenen boyutu doğrulamak için araçlar kullanın.

Birkaç öğe kontrast gerekliliklerinden açıkça muaftır. Tamamen dekoratif görseller, devre dışı form kontrolleri, logolar ve gerçek fotoğraflar 1.4.3 başarı ölçütüne tabi değildir. Bu istisna mantıklıdır — bir filigran arka plan veya ürün fotoğrafı, bir gezinme etiketiyle aynı eşiği karşılamaya zorlanmamalıdır — ancak ekipler bunu tembel tasarım tercihlerini gerekçelendirmek için sık sık yanlış uygular. Bir görsel veya grafik, sayfanın içeriğini anlamak için gerekliyse, yine de 3:1 metin dışı kontrast gerekliliğini karşılamalıdır.

Dikkat edilmesi gereken bir diğer önemli kural: WCAG 1.4.1 (Renk Kullanımı). Bağlantıları çevresindeki gövde metninden yalnızca renkle ayırt ediyorsanız — alt çizgi yoksa, ağırlık farkı yoksa, başka görsel ipucu yoksa — bu bağlantılar, standart 4.5:1 metin-arka plan oranını karşılamaya ek olarak, bitişik gövde metnine karşı 3:1 kontrast oranına ulaşmak zorundadır. Üç gerekliliği aynı anda karşılamak gerçekten zordur; en basit çözüm bağlantı alt çizgilerinizi korumaktır.

Kontrast Hatalarını Nasıl Test Edebilirsiniz

Kontrastı test etmek, erişilebilirlik çalışmalarının araç dostu kısımlarından biridir. Alttaki hesaplama matematiksel ve deterministiktir; bu da otomatik araçların bunu güvenilir şekilde yakalayabileceği anlamına gelir — insan yargısı gerektiren birçok diğer erişilebilirlik sorunundan farklı olarak. Bununla birlikte, otomasyonun yetersiz kaldığı uç durumlar vardır ve tam test yığınını anlamak denetimlerinizi çok daha kapsamlı hale getirecektir.

Adım 1: Otomatik bir sayfa taraması çalıştırın

WAVE (WebAIM web erişilebilirlik değerlendirme aracı) ve axe DevTools, en yaygın kullanılan iki tarayıcı tabanlı tarayıcıdır. Her ikisi de Chrome ve Firefox uzantıları olarak mevcuttur. İşlenen DOM’u tararlar — yani CSS ve JavaScript uygulandıktan sonra tarayıcının renkleri gerçekte boyadığı haliyle değerlendirirler — ve WCAG AA kontrast eşiğini karşılamayan metin öğelerini işaretlerler. Axe DevTools, her sorunun ciddiyetini raporlayarak, onu ilgili WCAG başarı ölçütüne bağlayarak ve iyileştirme konusunda rehberlik sağlayarak daha da ileri gider. Kurumsal ekipler için axe-core, CI/CD hatlarına doğrudan entegre edilebilir; böylece kontrast gerilemeleri yayına alınmadan önce yakalanır.

Google Lighthouse, Chrome DevTools’a yerleşik olarak, erişilebilirlik denetiminin bir parçası olarak kontrast kontrolleri de gerçekleştirir. Özellikle çoğu geliştiricinin iş akışında zaten bulunduğu için kullanışlı bir ilk geçiştir — ancak axe-core kurallarının bir alt kümesi üzerinde çalışır, bu nedenle tam axe DevTools uzantısı kadar kapsamlı değildir.

Önemli bir sınırlama: Otomatik tarayıcılar, degrade arka plan, arka plan görseli, yarı saydam katman veya karmaşık CSS yığılmasına sahip bir öğe üzerinde duran metnin kontrastını güvenilir şekilde değerlendiremez. Bu durumlar manuel inceleme gerektirir.

Adım 2: Hedefli inceleme için Chrome DevTools renk seçicisini kullanın

Chrome DevTools’ta herhangi bir öğe için Styles panelini açıp bir renk değerinin yanındaki renk örneğine tıklamak, öğenin hesaplanmış arka planına karşı mevcut kontrast oranını gösteren yerleşik bir renk seçici başlatır. Renk başarısız olduğunda, DevTools bir otomatik düzeltme özelliği sunar: En yakın AA ve AAA geçer renkleri gösterir, böylece tek tıkla uyumlu bir değeri benimseyebilirsiniz. Bu, geliştirme sırasında hızlı yineleme için çok değerlidir. DevTools ayrıca Rendering paneli altında bir Görme Yetersizlikleri emülatörü içerir; bulanık görme, protanopi, deuteranopi, akromatopsi ve diğer durumları simüle ederek renk bozukluğu yaşayan kullanıcıların paletinizi nasıl deneyimlediğine dair niteliksel bir fikir edinmenizi sağlar.

Adım 3: Belirli renk çiftlerini özel bir denetleyiciyle test edin

Yalnızca tek tek renk kombinasyonlarını doğrulamak için — örneğin, henüz hiçbir şey inşa edilmeden önce Figma’daki bir tasarım incelemesi sırasında — WebAIM Contrast Checker (webaim.org/resources/contrastchecker) sektör standardıdır. Ön plan ve arka plan için hex değerleri girersiniz ve araç, kontrast oranını ve normal ve büyük metin boyutlarında AA ve AAA için geçer/kalır derecelendirmesini anında döndürür. Windows ve macOS için Colour Contrast Analyser (CCA) masaüstü uygulaması da aynı derecede kullanışlıdır ve yarı saydam ön planlar ve yalnızca tarayıcı değil, herhangi bir uygulamadan ekran üstü damlalık örnekleme gibi karmaşık durumları da ele alır.

Adım 4: Bağlam içinde test edin — karanlık mod, hover durumları ve odak göstergeleri

Birçok ekip topu burada düşürür. Varsayılan açık temanızda geçen bir renk çifti, karanlık modda tamamen başarısız olabilir. Beyaz arka plan üzerinde canlı görünen marka vurgu renkleri, koyu bir yüzeyde çamurlu veya göz alıcı hale gelebilir. Her etkileşim durumu — hover, focus, active, visited — yeni kontrast hatalarının potansiyel bir kaynağıdır. Benzer şekilde, odak göstergeleri (bir klavye kullanıcısı bir kontrole sekmeyle geldiğinde görünen görünür çerçeve) WCAG 2.1 Başarı Ölçütü 1.4.11 kapsamında bitişik renklere karşı 3:1 kontrast sağlamalıdır. Yayın öncesinde her iki temayı da test edin; karanlık mod, sadece cilalı göründüğü için otomatik olarak erişilebilir değildir.

En Yaygın Kontrast Hataları — ve Bunları Nasıl Düzeltirsiniz

Denetimlerde en sık görülen hata kalıplarını anlamak, iyileştirme çalışmalarınızı önceliklendirmenizi sağlar. Çoğu kontrast sorunu öngörülebilir bir kategori setine girer.

Beyaz üzerinde gri gövde metni

#767676 veya #999999 gibi orta ton griler, modern düz tasarımda yaygındır. Kalibre edilmiş monitörlere sahip tasarımcılara havadar ve rafine gelirler. Çoğu zaman 4.5:1 eşiğini geçemezler ve düşük görme yetisine sahip kullanıcılar için görünmezdirler. Çözüm genellikle basit bir renk değeri değişikliğidir — #767676’yı (4.54:1 ile zar zor geçen) #595959’a kaydırmak size 7.0:1 oranı ve çok daha iyi okunabilirlik sağlar; çoğu gören kullanıcı için görünür fark ise minimumdur.

Kontrast ayarlamaları yapmak için daha sezgisel bir renk modeli olan HSL ile çalışırken, seçtiğiniz ton ve doygunluğu korurken kontrast oranını değiştirmek için yalnızca Lightness bileşenini değiştirmeniz gerekir. Beyaz bir arka plan üzerinde Lightness değerini düşürmek metni koyulaştırır ve kontrastı artırır; koyu bir arka plan üzerinde artırmak metni açar. Lightness’ta küçük değişiklikler (2–5 puan) çoğu zaman tasarımınızı fark edilir biçimde değiştirmeden, başarısızlıktan net bir AA geçişine geçmek için yeterlidir.

/* Önce: WCAG AA’yı geçemez (beyaz üzerinde oran ~3.9:1) */
.body-text {
  color: #888888;
}

/* Sonra: WCAG AA’yı hem AA hem AAA’da geçer (beyaz üzerinde oran ~7.0:1) */
.body-text {
  color: #595959;
}

Form alanlarındaki placeholder metni

Tarayıcının varsayılan stiliyle işlenen placeholder metni — tipik olarak #AAAAAA veya #BBBBBB civarında açık gri — beyaz girdi arka planında neredeyse evrensel olarak WCAG AA’da başarısız olur. Birçok tasarımcı, kullanıcı tarafından girilen içerikten görsel olarak ayırt etmek için placeholder kontrastını kasıtlı olarak düşük tutar, ancak bu izin verilen bir istisna değildir. Placeholder metni bir kullanıcı arayüzü metnidir ve 4.5:1 standardını karşılamalıdır. Daha koyu bir ton kullanın ve görsel ayrımı, açıklık yerine italik stil, konumlandırma veya animasyona dayandırın.

::placeholder {
  /* Başarısız: #AAAAAA beyaz üzerinde yaklaşık 2.3:1’dir */
  color: #AAAAAA;
}

::placeholder {
  /* Geçer: #767676 beyaz üzerinde yaklaşık 4.54:1’dir */
  color: #767676;
  font-style: italic; /* Alternatif görsel ipucu */
}

Orta ton marka rengi üzerinde beyaz veya açık metin

HSL’nin #5–6 lightness aralığındaki orta doygunluk bölgesindeki marka renkleri — yaygın mavi, yeşil ve mor tonları — üzerlerine bindirilen beyaz metin için sıklıkla yeterli kontrast sağlamaz. Logoda harika görünen canlı bir marka mavisi, beyaza karşı yalnızca 2.8:1 oran üretebilir; bu da gövde metni için 4.5:1 minimumunun çok altındadır. Çözüm, ya arka plan rengini koyulaştırmak (tasarım sisteminizde marka tonunu 800 veya 900 token’ına kaydırmak), ya o arka plan üzerinde koyu metne geçmek ya da orta ton rengi kontrast kurallarının uygulanmadığı tamamen dekoratif öğelere ayırmaktır.

Arka plan görselleri veya degrade üzerinde metin

Doğrudan bir fotoğraf veya degrade üzerine yerleştirilen metin, en zorlayıcı durumlardan biridir; çünkü arka plan parlaklığı homojen değildir — kontrast oranı, görselin farklı bölümlerinde değişir. En güvenilir çözüm, CSS kullanarak, görselin altında görünür kalmasını sağlayacak şekilde bir pseudo-element olarak uygulanan yarı saydam koyu veya açık bir örtüdür. Yaklaşık %50–60 opaklıktaki siyah bir örtü, beyaz metni genellikle sınırda kontrasttan sağlam AAA seviyesine taşır.

.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff;
}

Devre dışı durum ve ikincil arayüz öğeleri

WCAG, devre dışı arayüz bileşenlerini kontrast gerekliliklerinden açıkça muaf tutar — etkin olmayan bir düğmenin 4.5:1’i karşılaması gerekmez. Ancak birçok ekip bu istisnayı, gerçekte devre dışı olmayan ikincil metin, altyazı, yardımcı metin ve etiketlere aşırı uygular. Bir öğe, kullanıcının anlaması veya harekete geçmesi için gereken bilgiyi iletiyorsa, görsel hiyerarşisinden bağımsız olarak ilgili kontrast standardını karşılamalıdır. Tasarım sisteminizin nötr ölçeğindeki her tonu, göründüğü arka planlara karşı kontrol edin.

Kontrastı Tasarım Sisteminizin Bir Parçası Haline Getirmek

Tek tek kontrast hatalarını reaktif olarak düzeltmek yavaş ve hataya açıktır. Daha kalıcı yaklaşım, erişilebilir renk çiftlerini sonradan düşünce değil, varsayılan çıktı haline getirecek şekilde kontrast uyumunu tasarım sisteminize gömmektir.

Temel, düzgün derecelendirilmiş bir token ölçeğidir. Paletinizdeki her rengin, standart arka plan renklerinize karşı önceden hesaplanmış kontrast oranları belgelenmiş olmalıdır. Mantıklı bir gelenek, token’ları kontrast performansına göre etiketlemektir: --color-text-primary token’ı, --color-surface-default üzerinde her zaman AA’yı geçmelidir ve bu garanti belgelenmeli, test edilmeli ve uygulanmalıdır. Bir tasarımcı metni renklendirmek için bir token’a uzandığında, her seferinde manuel kontrol yapmadan minimum standardı karşıladığına güvenebilmelidir.

CSS özel özellikleri bunu özellikle yönetilebilir kılar. Tüm paletinizi değişkenler olarak tanımlayabilir ve herhangi bir renk çiftini hardcode etmeden, medya sorgularıyla karanlık mod için bunları değiştirebilirsiniz — böylece kontrast uyumu yönetimini tek bir yerde tutarsınız.

:root {
  --color-surface-default: #ffffff;
  --color-text-primary: #1a1a1a;   /* beyaz üzerinde ~16:1 */
  --color-text-secondary: #595959; /* beyaz üzerinde ~7.0:1 */
  --color-text-subtle: #767676;    /* beyaz üzerinde ~4.54:1 */
  --color-accent: #0052cc;         /* beyaz üzerinde ~8.0:1 */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-default: #121212;
    --color-text-primary: #ededed;   /* #121212 üzerinde ~14.5:1 */
    --color-text-secondary: #c0c0c0; /* #121212 üzerinde ~9.4:1 */
    --color-text-subtle: #909090;    /* #121212 üzerinde ~5.1:1 */
    --color-accent: #6fa8ff;         /* #121212 üzerinde ~6.5:1 */
  }
}

Yukarıdaki karanlık mod token değerlerine dikkat edin. Beyaz arka plan üzerinde AA’yı geçen renkler, koyu yüzeylerde sıklıkla başarısız olur ve tersi de geçerlidir. Karanlık mod için tasarım yaparken, açık mod değerlerinizi basitçe ters çevirmekten kaçının. Tam doygunlukta veya saf beyaz metnin saf siyah (#000000) üzerinde kullanılması, bazı kullanıcılar için zorlayıcı olan, yüksek kontrast uçlarında görsel bulanıklık etkisi (halation) yaratabilir. #121212 yüzeyi ve #ededed metni, hâlâ mükemmel kontrast sağlayan, ancak daha konforlu bir eşleştirmedir.

Otomatik kontrast testleri, bileşen hattınıza da entegre edilebilir. axe-core gibi kütüphaneler, Jest veya Playwright testlerinde çağrılarak kontrast hatalarını standart test paketinizin bir parçası olarak işaretleyebilir; böylece gerilemeler, harici bir denetim noktasında değil, tanıtıldıkları anda yakalanır.

Otomatik Araçların Yakalayamadıkları — ve Bunun İçin Ne Yapmalı

Otomatik tarama güçlü bir başlangıç noktasıdır, ancak gerçek sınırlamaları vardır. Otomatik testler, erişilebilirlik kriterlerinin tam yelpazesi dikkate alındığında, potansiyel WCAG ihlallerinin genellikle %20 ile %30’u arasında bir kısmını tespit edebilir — gerçi renk kontrastı, daha güvenilir şekilde tespit edilebilen kategorilerden biridir. Yine de, birkaç kontrast hata senaryosu rutin olarak otomatik araçların gözünden kaçar.

Degradeler ve arka plan görselleri üzerindeki metin en yaygın kör noktadır. Axe ve WAVE, hem ön plan hem arka plan tek, deterministik bir renk değerine sahip olduğunda renk eşleştirmelerini tanımlayabilir. Arka plan bir CSS degrade veya JPEG fotoğraf olduğunda, araç çoğu zaman anlamlı bir oran hesaplayamaz ve öğeyi kesin bir başarısızlık yerine “gözden geçirilmeli” olarak işaretler. Bu durumlar, ideal olarak Colour Contrast Analyser gibi piksel düzeyinde damlalık aracı kullanılarak, çakışma alanının birden fazla noktasında gerçek ön plan ve arka plan değerlerinin örneklenmesiyle, insan incelemesi gerektirir.

Yarı saydam ve bileşik renkler benzer zorluklar yaratır. Yeşil bir sayfa arka planı üzerinde işlenen mavi bir düğme üzerinde beyaz bir düğme etiketi, hesaplanmış kontrastını üç renk katmanının tümüne bağlı kılar — bu da DOM tabanlı araçların her zaman doğru şekilde gerçekleştiremediği bir hesaplamadır. Alfa değerlerini manuel olarak düzleştirin veya işlenen piksel rengini örneklemek için ekran yakalama tabanlı bir araç kullanın.

Dinamik olarak oluşturulan durumlar — JavaScript ile tetiklenen araç ipuçları, modal diyaloglar, açılır menüler, hata mesajları — uçuş sırasında işlenir ve otomatik tarama çalıştığında görünür olmayabilir. Betiklenebilen araçlar (Playwright testinde axe-core gibi) bu durumlara gidip onları değerlendirebilir, ancak bu kapsamı yapılandırmak bilinçli çaba gerektirir. Bunu QA iş akışınıza dahil edin ve yeni renk eşleştirmeleri getiren her yeni bileşen için kontrastı, “tamamlandı” tanımınızın bir parçası haline getirin.

Son olarak, WCAG’in iyi yerleşmiş matematiksel kontrast formülü, algılanan okunabilirlik için mükemmel bir vekil değildir. Formül, font ağırlığı, harf aralığı veya kenar yumuşatma gibi faktörleri hesaba katmaz. 4.5:1 oranındaki ince ağırlıklı bir yazı tipi, aynı oranı daha ağır bir ağırlıkla elde etmeye kıyasla daha zor okunur hissedilecektir. WCAG eşiğini bir taban — ulaşmanız gereken minimum — olarak ele alın, bir optimizasyon hedefi olarak değil. Mümkün olduğunda 7:1’e yönelin ve renk seçimlerinizin gerçek dünyada işe yaradığını doğrulamak için gerçekten düşük görme yetisine sahip insanlarla kullanıcı testleri yapın.

Temel Çıkarımlar

• Renk kontrastı, web’in bir numaralı erişilebilirlik hatasıdır. Düşük kontrastlı metin, 2026 itibarıyla en popüler bir milyon ana sayfanın %83.9’unda görüldü. Kuruluşunuzun erişilebilirlik programı ne kadar olgun olursa olsun, kontrast şu anda çözülmemiş hatalara sahip olmanızın en olası yeridir — ve en kolay düzeltilebilir olanlar arasındadır.
• İçeriğinize uygulanan eşikleri bilin. WCAG AA, normal metin için 4.5:1, büyük metin için 3:1 (18pt+ veya 14pt+ kalın) ve girdi kenarlıkları ve yalnızca ikon içeren kontroller gibi metin dışı arayüz bileşenleri için 3:1 gerektirir. Bunlar, arayüzünüz açık veya karanlık mod kullansa da geçerlidir.
• Katmanlı test yapın: otomatik tarama, DevTools incelemesi, bağımsız denetleyici ve manuel gözden geçirme. Hızlı tam sayfa taraması için axe DevTools veya WAVE çalıştırın; hızlı yineleme için Chrome DevTools’un yerleşik renk seçicisini kullanın; belirli çiftleri doğrulamak için WebAIM Contrast Checker veya CCA’yı kullanın; ve otomatik araçların güvenilir şekilde değerlendiremeyeceği degradeleri, görselleri ve dinamik durumları manuel olarak inceleyin.
• Kontrastı bileşen düzeyinde değil, tasarım sistemi düzeyinde düzeltin. Önceden doğrulanmış kontrast oranlarına sahip bir token ölçeği oluşturun, hangi metin token’larının hangi yüzey token’ları üzerinde geçtiğini belgeleyin ve uyumu CI’da otomatik testlerle uygulayın. Bu, üretime ulaşmadan önce tüm bir hata sınıfını ortadan kaldırır.
• WCAG’i hedef değil, taban olarak ele alın. 4.54:1’e ulaşmak zar zor geçer — ama yine de birçok kullanıcıyı zor durumda bırakır. Tipografi, okunabilirlik ve marka izin verdiği ölçüde 7:1’e doğru ilerleyin ve metni yalnızca teknik olarak uyumlu değil, gerçekten rahat okunur hale getirmek için font ağırlığı, boyutu ve aralığını ek kaldıraçlar olarak kullanın.