WCAG renk kontrast oranı: AA, AAA ve APCA — 2026 için eksiksiz rehber
Bir buton yayına aldınız. Marka turuncusu, beyaz yazı, 4K monitörünüzde iyi duruyor. Sonra erişilebilirlik denetimi kırmızı dönüyor: WCAG kontrast oranı 1,97:1; gövde metni için 4,5:1 AA eşiğine yaklaşamıyor bile. Size sorunsuz görünen o buton, dünya çapında düşük görme yetisine sahip yaklaşık 220 milyon kişi için okunaksız. Bu rehber, durumu düzeltmek için ihtiyacınız olan her sayıyı kapsıyor: WCAG 2 oranları, AAA seviyesi, yeni APCA Lc algoritması, sekiz farklı renk görme eksikliği tipi ve build hattınıza doğrudan yerleştirebileceğiniz çalışan bir JavaScript uygulaması.
Hızlı başvuru: tek bakışta WCAG ve APCA eşikleri
| Standart | Normal metin | Büyük metin | UI / ikonlar | Notlar |
|---|---|---|---|---|
| WCAG AA | ≥ 4,5:1 | ≥ 3:1 | ≥ 3:1 | Yasal taban |
| WCAG AAA | ≥ 7:1 | ≥ 4,5:1 | ≥ 3:1 | Gelişmiş hedef |
| APCA gövde | Lc 75+ | Lc 60+ | Lc 45+ (ikonlar) | Taslak, algısal |
“Büyük metin”, ≥ 18pt normal veya ≥ 14pt kalın anlamına gelir (CSS’de yaklaşık 24px ve yaklaşık 18,66px). “UI” ise form sınırlarını, odak halkalarını ve kullanıcının sayfayı kullanabilmesi için algılaması gereken her grafik nesneyi kapsar. Logolar ve yalnızca dekoratif grafikler kontrast gerekliliklerinden muaftır.
WCAG renk kontrastı nedir?
WCAG kontrast oranı, metnin bağıl parlaklığını arka planınkiyle karşılaştıran ve 1:1’den (kontrast yok) 21:1’e (maksimum) uzanan sayısal bir ölçüdür. Web İçeriği Erişilebilirlik Kılavuzu, gövde metni için ≥ 4,5:1 (AA) veya gelişmiş uyumluluk için ≥ 7:1 (AAA) talep eder.
Bu tek oran, dünya genelindeki erişilebilirlik denetimlerinin büyük bölümünde belirleyicidir. W3C bu kuralı ilk kez 2008’de WCAG 2.0 ile yayımladı, 2.1 (2018) ve 2.2 (2023) ile rafine etti; bugün her büyük düzenleyici bu noktayı işaret ediyor. ABD’deki ADA, Haziran 2025’te uygulamaya geçen Avrupa Erişilebilirlik Yasası, ABD federal kurumları için Section 508 ve Kanada’nın AODA’sı; hepsi WCAG 2.x AA’yı fiilî zemin olarak kullanır.
Yasal boyutun ötesinde bu neden önemli? Dünya genelinde yaklaşık 220 milyon kişi düşük görme yetisine sahip ama kör değil; ekranları okuyabiliyorlar, ancak yalnızca metin/arka plan kontrastı yeterince yüksekse. Erkeklerin yaklaşık %8’inde ve kadınların %0,5’inde renk görme eksikliği var. Yaşlı okurlarda gözün lensi sararıyor ve göz bebeği açıklığı azalıyor; bu, 60 yaşından sonra algılanan kontrastı işlevsel olarak %20-30 düşürüyor. Akıllı telefonun dış mekânda kullanımı yansımalar yüzünden bir %20-40 daha kaybediyor. Masanızda 4,5:1 puanlayan bir sayfa, tüm bu kullanıcıların hâlâ okuyabildiği taban değeridir.
Bunu en çok önemsemesi gerekenler şunlar: üretim ortamına UI gönderen frontend mühendisleri, marka paletini seçen tasarımcılar, denetim yürüten erişilebilirlik uzmanları ve yasal riskten sorumlu uyumluluk ekipleri. Matematik kısadır; onun zorladığı kararlar değil.
WCAG 2.x kontrast oranı: matematik ve eşikler
W3C, kontrastı üç kısa adımda tanımlar. WCAG kontrast oranını hesaplamak için: (1) her rengi gamma kodlanmış sRGB’den doğrusal-ışık değerlerine çevirin, (2) insan gözünün kırmızı, yeşil ve maviye duyarlılığını yansıtan sabit katsayılarla bağıl parlaklığı hesaplayın ve (3) siyaha yakın değerleri ele almak için küçük bir sabit kaydırma ekleyerek iki parlaklığı bölün.
WCAG 2.1 §1.4.3’teki bağıl parlaklık formülü şudur:
L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin
R_lin, G_lin, B_lin, sRGB gamma eğrisi geri çevrildikten sonraki doğrusal-ışık kanal değerleridir. Yeşil üzerindeki 0,7152 ağırlığı, insan gözünün yeşile karşı güçlü duyarlılığını yansıtır: yeşil, birim ışık enerjisi başına maviden kabaca 7 kat daha “görsel olarak yüksek sesli”dir.
Oran formülü:
ratio = (L_lighter + 0.05) / (L_darker + 0.05)
+0,05 sabiti, saf siyah (L = 0) için sıfıra bölmeyi önler ve saf beyaz üzerinde saf siyah için maksimum (1 + 0,05) / (0 + 0,05) = 21:1 verir. Minimum değer 1:1’dir; iki özdeş rengin oranı.
Eksiksiz uygulama, yaklaşık otuz satır sade JavaScript ile yazılır. Bağımlılığı yok, her yerde çalışır:
// sRGB hex → doğrusal-ışık kanalı
function srgbToLinear(channel8bit) {
const v = channel8bit / 255;
return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}
// "#RRGGBB" → bağıl parlaklık [0, 1]
function relativeLuminance(hex) {
const h = hex.replace("#", "");
const r = parseInt(h.slice(0, 2), 16);
const g = parseInt(h.slice(2, 4), 16);
const b = parseInt(h.slice(4, 6), 16);
return (
0.2126 * srgbToLinear(r) +
0.7152 * srgbToLinear(g) +
0.0722 * srgbToLinear(b)
);
}
// İki hex renk arasında WCAG 2.x kontrast oranı
function contrastRatio(hexA, hexB) {
const lA = relativeLuminance(hexA);
const lB = relativeLuminance(hexB);
const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
return (lighter + 0.05) / (darker + 0.05);
}
// Örnek: beyaz üzerine koyu slate gövde metni
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" — AA 4,5:1'in oldukça üstünde ve AAA 7:1'in az üzerinde
İki hex kodu Renk Dönüştürücü içine bırakın; aynı sayılar, bir APCA Lc değeri, gamut sınıflandırması ve sekiz kanallı CVD önizlemesiyle birlikte size geri döner. Eşiklerin kendisi şöyle:
| Öğe | AA min | AAA min | Notlar |
|---|---|---|---|
| Normal gövde metni | 4,5:1 | 7:1 | 18pt normal / 14pt kalının altında |
| Büyük metin | 3:1 | 4,5:1 | ≥ 18pt normal VEYA ≥ 14pt kalın |
| UI bileşenleri / ikonlar | 3:1 | — | WCAG 2.1 §1.4.11, 2018’de eklendi |
| Logolar ve dekoratif | muaf | muaf | Kontrast gerekliliği yok |
CSS birim dönüşümleri ekipleri tökezletir. Tarayıcı varsayılanında 18pt = 24px, 14pt = 18,66px’tir. Modern varsayılan olan 16px gövde fontu, “büyük metin” eşiğinin altındadır, dolayısıyla daha sıkı 4,5:1 AA kuralına tabidir. font-weight: 700 ile 20px bir başlık büyük sayılır ve daha gevşek 3:1 alır.
Ekipleri hazırlıksız yakalayan bir ince nokta: WCAG’in “büyük metin” muafiyeti, başlık semantiğiyle değil, ölçekteki kullanıcı okunabilirliğiyle ilgilidir. 14px bir <h2> büyük metin değildir; yine 4,5:1 gerektirir. 24px’lik bir pazarlama paragrafı büyük metindir ve 3:1 tabanını alır. Kural; tag adına değil, render edilen piksel boyutu ve ağırlığa kilitlenir. Denetçiler uyumsuzlukları işaretler; gerçeğin kaynağı CSS’inizdir, HTML semantiği değil.
Oran formülündeki +0,05 sabitinin belirli bir kökeni vardır: ekran yüzeyinden yansıyan ortam ışığını temsil eden flare terimidir; saf siyahın görünen parlaklığını bir minimum tabana yükseltir. O olmadan, saf beyaza karşı gerçek siyahı render eden bir OLED piksel sıfıra bölme verirdi. Onunla birlikte ulaşılabilir maksimum oran 21:1 olur; her erişilebilirlik aracında öne çıkarılan bir sayı. Flare hesaba katıldığında 21:1’den fazlasını verebilen fiziksel bir ekran yoktur; WCAG ölçeğinin orada zirveye ulaşmasının nedeni budur.
AA mı AAA mi: hangisini hedeflemelisiniz?
AA yasal tabandır; AAA ise özlenen seviyedir. Çoğu ticari site AA hedefler, çünkü AAA markaları markalı renkleri geçer hâle getirmek için gri tona doğru iter ki bunu çoğu pazarlama ekibi kabul etmez. Karar “ne kadar çoksa o kadar iyi” değildir; kullanıcı erişimi ile marka ifadesi arasında bir denge meselesidir.
| Bağlam | Önerilen seviye | Neden |
|---|---|---|
| Genel ticari site | AA | ADA / EAA uyumluluk tabanı; mahkemeler WCAG 2 AA’yı işaret eder |
| Devlet / kamu hizmetleri | AAA | Section 508 ve AB’deki muadil mevzuat AAA önerir |
| Sağlık / eğitim | AAA | Kullanıcı tabanı yüksek erişilebilirlik ihtiyaçlarına meyleder |
| Şirket içi gösterge paneli | AA | Kitle bellidir, ROI dengelemesi kabul edilebilir |
| Pazarlama açılış sayfası | AA + marka istisnası | Hero/CTA’larda marka rengine izin, gövde yine AA |
AAA’nın gizli maliyeti, doymuş bir marka turuncusunu beyaza karşı 7:1 geçirmeye çalıştığınız ilk anda ortaya çıkar. Geçemez. Ya turuncuyu artık markanız olmaktan çıkana dek koyulaştırırsınız ya da AA’yı kabul edip turuncuyu kolayca AAA’ya ulaşabileceği koyu zeminlerde kullanırsınız. Pek çok şirket (erişilebilirliğe en duyarlı olanlardan bazıları dâhil) gövde içeriğinde açıkça AA’yı hedefler ve yalnızca hata mesajları ya da yasal bildirimler gibi kritik metinlerde AAA’yı zorlar.
Düzenleyiciler AAA’nın yaygınlaşmasını beklemedi. ADA’nın 2024 web erişilebilirlik düzenlemesi WCAG 2.1 AA’yı esas alır. Haziran 2025’ten beri uygulanan Avrupa Erişilebilirlik Yasası, kapsam dahilindeki dijital hizmetlerde WCAG 2.1 AA’yı zorunlu kılar. ABD federal hükümetindeki Section 508, taban olarak WCAG 2.0 AA’yı kullanır (uygulanabilir olduğu yerde AAA önerilir). Ontario’nun erişilebilirlik yasası AODA da WCAG 2.0 AA’yı işaret eder. Örüntü tutarlıdır: AA çıtadır, AAA hedeftir.
APCA: yeni algısal algoritma
APCA (Myndex çatısı altında Andrew Somers tarafından tasarlanan Advanced Perceptual Contrast Algorithm), WCAG 3 için aday algoritmadır. WCAG 2’nin simetrik oranını, -108 ile +108 arasında polarite işaretli bir Lc skoruyla değiştirir; işaret, kontrastın hangi yönde çalıştığını söyler (açık zemine koyu metin mi, koyu zemine açık metin mi), büyüklük ise gerçek bir emisyon görüntü cihazında algılanan kontrastı yansıtır.
APCA önemlidir, çünkü WCAG 2’nin simetrik formülü gerçek dünyadaki iki etkiyi ıskalar:
- Polarite asimetrisi. Koyu zemin üzerine açık metin, aynı WCAG oranında bile açık zemin üzerine koyu metinden farklı okunur. WCAG 2 her iki yön için aynı sayıyı döndürür; APCA döndürmez.
- Görüntü modeli. WCAG 2’nin formülü basılı kâğıt parlaklık modellerinden türetildi. APCA ise tipik ofis aydınlatmasındaki sRGB ekranlara göre ayarlandı; bu, kullanıcılarınızın gerçekte gördüğüne daha yakındır.
Karşı denge: APCA daha karmaşıktır (polarite duyarlı üsler ve font ağırlığı düzeltmeleri içerir) ve henüz düzenleyici bir standart değildir. Adrian Roselli’nin 2026 Nisan analizi, APCA’nın bulunduğu noktayı özetleyen en açık metin olmaya devam ediyor: teknik açıdan umut verici, ama WCAG 3’ün kendisi hâlâ erken taslak aşamasındaki Silver hattında geliştiriliyor ve APCA henüz resmî algoritma olarak onaylanmadı.
APCA Bronz seviyesi eşikleri (çoğu ekibin hedeflediği pratik taban) şöyle görünür:
| Kullanım | Önerilen Lc | Minimum Lc |
|---|---|---|
| Gövde metni (16px, ağırlık 400) | 90+ | 75 |
| Büyük metin (24px, ağırlık 400) | 75+ | 60 |
| UI öğeleri ve metin dışı ikonlar | 60+ | 45 |
| Spot metin / placeholder | 30+ | 30 |
APCA neden ilginç ve Renk Dönüştürücü neden her iki metriği yan yana sunuyor? WCAG 2 ile anlaşamadığı durumlar için:
#FFA500(turuncu) üzerine#FFFFFF: WCAG 2 1,97:1 verir, AA’da net bir başarısızlık. APCA da hemfikir, yaklaşık Lc 38 puanlar; yine başarısız. Şimdilik iki algoritma da hayır diyor, ama izlediğim çoğu tasarımcı “iyi görünüyor” diye bu kombinasyonu hâlâ yayına alıyor.#767676(orta gri) üzerine#FFFFFF: WCAG 2 4,54:1 verir, AA 4,5:1’in az üstünde, teknik olarak geçer. APCA bu ikiliyi yaklaşık Lc 60 puanlar; bu, APCA Bronz’un gövde metni için 75 eşiğinin altındadır. WCAG geçer; APCA çakar. Kullanıcının yaşanmış deneyimi APCA’nın hükmüne daha yakındır: beyaz üzerine bu gri, oranın söylediğinden gövde boyutlarında daha zor okunur.#3b82f6(Tailwind blue-500) üzerine#000000: WCAG 2 5,71:1 verir, rahat bir AA geçişi. APCA bunu yaklaşık Lc 65 puanlar; gövde metni Lc 75 minimumunun altında. Koyu zemin üzerine açık mavi metin, sevilen bir dark mode örüntüsü, “WCAG geçer, APCA işaretler”in kanonik örneğidir.
Bir tarafı seçmek zorunda değilsiniz. Çoğu üretim ekibinin yerleştiği pragmatik tutum şudur: WCAG 2 AA’yı düzenleyici taban olarak tutun çünkü uyumluluk denetimleri buna bakar; APCA’yı paralelde “bu gerçekten okunabilir mi?” sezgisel kontrolü olarak çalıştırın, özellikle dark mode tasarımları ve doymuş marka renkleri için. Renk Dönüştürücü, kontroller arasında bağlam değiştirmek zorunda kalmayasınız diye her iki sayıyı da tek satırda gösterir.
Renk körlüğü ve kontrastın ötesi
Kontrast oranları renk erişilebilirliğinin yalnızca yarısıdır. Erkeklerin yaklaşık %8’i ve kadınların %0,5’i renkleri ders kitabı trikromatından farklı görür; en yaygın varyant olan deuteranomali, başarı/hata durumları için her yerde kullandığımız kırmızı/yeşil ikilisinin tam ortasında oturur. WCAG 1.4.1 (“Renk Kullanımı”), bilginin tek taşıyıcısı olarak rengi açıkça yasaklar; uygulamak için var olan kural budur.
Renk görme farklılıklarının tam taksonomisi üç gruba ayrılır: dikromasi (bir koni eksik), anormal trikromasi (bir koni kaymış) ve nadir monokromasiler.
| Tip | Yaygın ad | Etkilenen kanal | Sıklık (E / K) |
|---|---|---|---|
| Protanopia | Kırmızı kör | L konisi yok | %1,0 / %0,01 |
| Deuteranopia | Yeşil kör | M konisi yok | %1,1 / %0,01 |
| Tritanopia | Mavi kör | S konisi yok | %0,003 / %0,003 |
| Protanomaly | Kırmızı zayıf | L konisi kaymış | %1,3 / %0,02 |
| Deuteranomaly | Yeşil zayıf | M konisi kaymış | %5,0 / %0,4 |
| Tritanomaly | Mavi zayıf | S konisi kaymış | %0,01 / %0,01 |
| Achromatopsia | Renk yok | Tüm koniler yok | %0,003 (çok nadir) |
| Koni monokromasisi | Kısmî gri | Yalnızca tek koni | %0,001 |
Tek başına deuteranomali, erkeklerin %5’idir; yirmide bir. Bu kitle; kırmızı bir hata göstergesini ve yeşil bir başarı göstergesini neredeyse aynı zeytin-kahverengi tonu olarak görür. Çözüm renk sisteminizi yeniden tasarlamak değildir; ikinci bir kanal eklemektir. ”×” şekli ve “Hata” sözcüğüyle eşleştirilmiş kırmızı bir hata ikonu, tablodaki her varyantı atlatır. Çıplak bir kırmızı nokta atlatamaz.
Kodda CVD simülasyonu iki standart matris kümesi kullanır: dikromasiler için Brettel–Viénot–Mollon (1997) ve anormal trikromasiler için Machado–Oliveira–Fernandes (2009). Brettel yaklaşımı, kullanıcının giriş rengini kalan iki koni yanıtının gerdiği bir düzleme yansıtır; Machado ise koni kaymasını şiddete göre parametrize eder. Her ikisi de SVG filtreleri veya CSS matrisleri olarak uygulanabilir. Renk Dönüştürücü, bir marka rengini sayfadan ayrılmadan spektrum boyunca tarayabilmeniz için sekiz varyantın tümünü tek tıkla önizleme olarak sunar.
Kısa bir SVG filtresi (sayfanıza bırakın ve kimlikle referans verin) tarayıcıda hızlı testler için protanopia simülasyonu sağlar:
<svg style="display: none">
<filter id="protanopia">
<feColorMatrix type="matrix" values="
0.567 0.433 0.000 0 0
0.558 0.442 0.000 0 0
0.000 0.242 0.758 0 0
0.000 0.000 0.000 1 0"/>
</filter>
</svg>
<style>
.preview-protanopia { filter: url(#protanopia); }
</style>
Bir protanopun ne gördüğünü görmek için sayfa sarmalayıcınıza .preview-protanopia uygulayın. Deuteranopia ve tritanopia matrisleriyle (katsayıları Brettel makalesinde belgelenir ve çoğu CVD simülatör kütüphanesinde paketlenir) tekrar edin. Chrome DevTools’un Rendering panelinde aynı simülatörler “Emulate vision deficiencies” altında yerleşik gelir; hızlı kontroller için faydalı, CI’de ekran görüntüsü yakalamak için daha az faydalı.
Simülasyonun ötesindeki daha derin kural: rengin asla iki durum arasındaki tek fark olmasına izin vermeyin. İkonlar şekille farklı olmalı (× vs ✓), durumlar metin etiketiyle (“Hata” vs “Başarılı”), kategoriler örüntüyle (dolu vs taralı). Renk, bu diğer sinyallerin yerine geçen değil onları çarpan bir öğedir.
Kontrast denetleyicilerinin yakalamadığı ama CVD simülatörlerinin yakaladığı bir hata sınıfı vardır. Yalnızca tonla ayrılan pasta grafik dilimleri, ülkeleri renkle kodlayan harita lejantları, yeşil/sarı/kırmızı gradyana dayanan durum etiketleri; hepsi arka plana karşı WCAG 2 kontrastını geçebilir ama bir deuteranopa için birbirlerine karşı okunaksızdırlar. Kural; tasarımda yan yana duran renkler arasındaki okunabilirliği denetlemektir, yalnızca çevredeki tuvale karşı değil. Aynı açıklıktaki iki yan yana slate-500 dilimi, ton döndürmesi ne olursa olsun ayırt edilemez. Komşu bölgeler arasına bir parlaklık adımı eklerseniz grafik her CVD varyantını atlatır.
Achromatopsia ve koni monokromasisi nadirdir ama açıkça tasarlamaya değerdir, çünkü tüm ton ayrımlarını çökertirler. Achromatopsiası olan bir kullanıcı yalnızca parlaklığı algılar; renkle kodlanmış UI’nız onlara gri tonlamalı bir fotoğraf gibi görünür. Tüm sayfaya filter: grayscale(1) uygulandığında tasarımınız ayakta kalıyorsa (DevTools’ta deneyin), “renk tek sinyal değildir” kuralının en katı sürümünü geçmişsiniz demektir. Yapabileceğiniz en ucuz erişilebilirlik testidir ve açıp kapadığınız anda şaşırtıcı sayıda hatayı yüzeye çıkarır.
Tailwind ve Material paletlerini denetleme
Çoğu frontend çalışması önceden hazırlanmış bir palet kullanır: Tailwind v4, Material 3, Radix ya da shadcn. Erişilebilirlik sorusu “metin bu rampanın hangi durağında okunabilir hâle gelir?” hâline dönüşür; cevap, dokümantasyonun kabul ettiğinden daha çok pratik kurallarla şekillenir.
Tailwind v4’ün slate rampasının saf beyaza karşı WCAG ve APCA sayıları şöyledir:
| Tailwind sınıfı | Yaklaşık hex | Beyaza karşı WCAG | AA gövde | AAA gövde | APCA Lc (yaklaşık) |
|---|---|---|---|---|---|
| slate-400 | #94a3b8 | 2,56:1 | ✗ | ✗ | ~38 ✗ |
| slate-500 | #64748b | 4,76:1 | ✓ | ✗ | ~60 ✗ gövde |
| slate-600 | #475569 | 7,58:1 | ✓ | ✓ | ~78 ✓ gövde |
| slate-700 | #334155 | 10,35:1 | ✓ | ✓ | ~90 ✓ gövde |
Buradan çıkan pratik kurallar:
- Gövde metni slate-600 veya daha koyu gerektirir. Slate-500 WCAG AA’yı geçer ama APCA’nın gövde metni eşiğinde çakar: uyumlu ama rahatsız edicidir. Slate-600 güvenli tabandır.
- UI etiketleri ve ikincil metin slate-500 kullanabilir. UI bileşenleri yalnızca 3:1 gerektirir; slate-500’ün 4,76:1’i rahattır ve metin genelde destekleyici görsel bağlam taşır.
- Placeholder’lar slate-400 ya da daha açığını kullanmalıdır. Placeholder metni WCAG 1.4.3 muafiyetiyle dekoratiftir, yalnızca alanın üstünde görünür bir etiketiniz varsa. Etiket-yerine-placeholder örüntüleri gövde metni eşiğine ulaşmak zorundadır.
- Slate-100 / slate-200 üzerine saf siyah, mürekkep israfıdır. 17:1 ve üstündesiniz; okunabilirliği kaybetmeden daha yumuşak bir his için metin rengi olarak slate-700 ya da slate-800 düşünün.
Material 3 benzer bir tonal palet yapısı kullanır. surface-container-high’ı yaklaşık ton 92 civarındadır (çok açık); on-surface’i ton 10 civarında (siyaha yakın) durur. Aynı ailedeki herhangi bir on-surface ile herhangi bir surface-* token arasındaki kontrast, Material’in spec’i tarafından AA’yı geçeceği şekilde garanti edilir. on-surface-variant (ton 30) ile surface-container (ton 94) eşleştirmesini denetlemeden yapmayın; gerçek dünyada üretime sızdığını gördüğüm bir kaçaktır.
Kontrastı çakan mevcut bir paletiniz varsa, en temiz düzeltme yolunu OKLCH sunar. Hex kodlarını rasgele oynamak yerine renginizi OKLCH’e dönüştürün, C (kroma) ve H (ton) sabit tutun ve kontrast geçene dek L (parlaklık) değerini düşürün. OKLCH’in L kanalı gerçekten algısal olduğundan, marka tanınırlığı bozulmazken kontrast sıkılaşır. HEX → OKLCH aracı bu dönüşümü tek adımda yapar; kardeş yazı OKLCH açıklaması ise matematiği derinlemesine ele alır.
Dark mode kendine ait bir paragrafı hak ediyor. WCAG 2’nin simetrik oranı, tanım gereği aynı kombinasyonları açık ve koyu modda geçer. Polarite duyarlı olan APCA, koyu mod gövde metnini sıklıkla aynı hex çiftinin açık moddakine göre daha zor okunur olarak işaretler. Açık-üstüne-koyu, aynı sayısal oranda koyu-üstüne-açık’a göre her zaman bir miktar algılanan kontrast kaybeder; gözün uyum sağlama biçiminin bilinen bir etkisidir. Yayına almadan önce her dark mode ikilisinde APCA’yı yeniden çalıştırın.
Kontrast denetleyicileri ve CI iş akışları
Tasarımcıların ve mühendislerin her birinin favori bir denetleyicisi vardır; pratik soru, gerçek bir iş akışına hangi araç kombinasyonunu işlediğinizdir. 2026 itibarıyla saha şöyle:
| Araç | WCAG 2 | APCA | CVD sim | Palet denetimi |
|---|---|---|---|---|
| WebAIM Contrast Checker | ✓ | ✗ | ✗ | ✗ |
| Adobe Color | ✓ | ✗ | ✓ | ✓ |
| Stark (Figma eklentisi) | ✓ | ✓ | ✓ | ✓ |
| Polypane (tarayıcı) | ✓ | ✓ | ✓ | ✓ |
| Chrome DevTools renk seçici | ✓ | ✓ (deney.) | ✗ | ✗ |
| axe DevTools | ✓ | ✗ | ✗ | ✓ (sayfa düzeyi) |
| Go Tools Renk Dönüştürücü | ✓ | ✓ | ✓ (8 tip) | ✓ (Tints/Shades) |
Gerçek ürün baskısı altında ayakta kalan bir iş akışı şuna benzer:
- Figma’da tasarımcılar, çakan ikilileri erken yüzeye çıkarmak için her freym’de Stark’ı çalıştırır. Stark, herhangi bir hex kod kod tabanına ulaşmadan önce bariz suçluları yakalar.
- Hex kodu devri sırasında mühendisler değeri Renk Dönüştürücü’ye yapıştırarak WCAG oranı + APCA Lc + gamut sınıflandırması + CVD önizlemesini tek satırda alır. İkili dark mode ya da doymuş marka rengi ise, ikili metrik Stark’ın gözden kaçırabileceği “WCAG geçer, APCA çakar” durumlarını yakalar.
- PR aşamasında
axe-core/playwright, render edilmiş DOM’daki dinamik durumlar dahil her kontrast ihlali için derlenmiş sayfaları tarar. Bu, statik tasarım dosyalarının kaçırdığı odak halkalarını, hover durumlarını ve devre dışı kullanım önerilerini yakalar. - QA’da Chrome DevTools’un Rendering sekmesi, kritik akışların noktasal kontrolü için protanopia/deuteranopia/tritanopia simüle eder. DevTools’taki renk seçici de bir öğenin üzerine geldiğinizde satır içi WCAG oranını yüzeye çıkarır.
Pa11y, Lighthouse CI ve @axe-core/playwright; hepsi daha geniş erişilebilirlik denetimlerinin parçası olarak kontrast iddialarını sunar. Bugün hiçbiri APCA’yı denetlemez; hepsi WCAG 2’yi denetler. Gerçekçi uzlaşma şudur: “CI’de WCAG 2 AA’yı zorla, marka renkleri ve dark mode için APCA Lc’yi manuel olarak sezgisel kontrol et.”
Daha büyük tasarım sistemi ekiplerinden ödünç almaya değer bir örüntü: kontrast kontrolünü yalnızca sayfa düzeyindeki QA’ya değil, token doğrulama adımınıza da pişirin. Tasarım token’larınız bir kaynak dosyadan (JSON, YAML ya da TypeScript modülü) derleniyorsa, sistemin izin verdiği her --text-* × --surface-* eşleşmesini sıralayan ve minimum WCAG oranını öne süren bir betik ekleyin. Betik milisaniyeler içinde çalışır, biri bir token değerini ayarladığında regresyonları yakalar ve tasarım ekibi için dokümantasyon görevi gören bir kontrast matrisi üretir. Kontrol, render edilmiş bir sayfadan bağımsızdır; yalnızca token’lar üzerinde çalışır, böylece herhangi bir UI yayına çıkmadan önce hatayı yakalar.
Bu iş akışı sırasındaki anlık dönüşümler için (siz hata ayıklarken hex, RGB, HSL ve OKLCH arasında geçiş yapmak için) HEX → RGB, HEX → HSL, HEX → OKLCH ve RGB → HEX spoke’ları, takım zincirinizin beklediği her renk biçimine giriş-çıkış gidiş-dönüşlerini kapsar.
Yaygın hatalar ve nasıl düzeltilir
Yıllarca süren erişilebilirlik denetimlerinden sonra aynı altı hata tekrar ortaya çıkıyor. Her birinin düzgün bir çözümü var:
-
Açık gri placeholder metni. Beyaz üzerine
#9999992,85:1’dir, AA’da çakar. Ya#666666’ya derinleştirin (5,74:1, AA geçer) ya da daha iyisi placeholder-as-label örüntülerini, alanın üzerinde kalıcı görünür bir etiketle değiştirin. Placeholder bilgi taşımamalıdır. -
Beyaz metinli marka turuncusu butonu. Beyaz üzerine
#FFA5001,97:1’dir, AA’da kötü çakar. Markayı koruyan çözüm, kontrast yönünü tersine çevirmektir: turuncu zemin üzerine koyu metin (örn.#451a03), ya da beyaz metni tutup butonu derin doymuş kahve-turuncuya koyulaştırın. Yayına almadan önce Renk Dönüştürücü ile doğrulayın. -
Dark mode’da parlak mavi link.
#000000üzerine#3b82f65,71:1’dir; WCAG AA geçer, ama APCA Lc yaklaşık 65, Lc 75 gövde eşiğinin altında. OKLCH’e uzanın ve L’yi ≈ 0,63’ten 0,75’e yükseltin, C ve H sabit kalsın;#7aa5f8civarına ineceksiniz ve rahat bir APCA Lc 80+ ile aynı tonu yakalayacaksınız. -
#CCCCCCdevre dışı metin. Beyaza karşı 1,61:1. WCAG 1.4.3, yalnızca dekoratif metni oran kuralından muaf tutar, ama devre dışı UI kontrolleri dekoratif değildir; “bu şu anda kullanılamıyor” iletisini taşırlar. Donuk rengi renk dışı bir ipucuyla (üstü çizili, kilit ikonu, “Devre dışı” tooltip) eşleştirin ki CVD ya da düşük görme yetisi olan kullanıcı durumu anlayabilsin. -
Yalnızca tonla farklılaşan durum ikonları. Kırmızı bir
×ve yeşil bir✓iyidir, çünkü şekil onları zaten ayırır. Kırmızı bir nokta ile yeşil bir nokta değildir. Şekil ve rengi birlikte kullanın; Renk Dönüştürücü’nün CVD önizlemesi, hata durumunu bir saniyede gözle görülür kılar. -
Gradyan arka plan üzerine metin. Beyaz metne karşı
#3b82f6’dan#a78bfa’ya akan bir gradyan, ortada kontrastı geçer ve lavanta ucunda çakar. Çözüm, kontrastı gradyanın en kötü noktasına karşı zorlamak ya da efektif arka plan parlaklığı her zaman bilinen bir eşiğin altında kalsın diye yarı saydam koyu bir scrim bindirmektir.
Her bir düzeltme dakikalar alır. Onların önlediği denetim döngüsü haftalar.
SSS
WCAG AA kontrast oranı nedir?
WCAG AA, gövde metni ile arka plan arasında ≥ 4,5:1 veya büyük metin (≥ 18pt normal veya ≥ 14pt kalın) ve form sınırları gibi UI bileşenleri için ≥ 3:1 gerektirir. AA; ADA, EAA ve Section 508 altındaki yasal tabandır; çoğu ticari site AA’yı hedefler çünkü düzenleyici çıtayı, marka renklerini gri tona doğru itmek zorunda kalmadan karşılar.
AAA için ne kadar kontrast oranı gerekir?
WCAG AAA, normal gövde metni için ≥ 7:1 ve büyük metin için ≥ 4,5:1 gerektirir. AAA; sağlık, eğitim ve devlet siteleri için, kullanıcı tabanının yüksek erişilebilirlik ihtiyaçlarına doğru meylettiği yerlerde önerilir. Marka renkleri AAA’yı geçmek için sıklıkla gri tona yakın değerlere yassılaştırılmak zorunda kalır; bu yüzden pek çok ticari ürün AA’da durur.
APCA nedir ve WCAG 3.0 mı?
APCA (Advanced Perceptual Contrast Algorithm), Andrew Somers / Myndex tarafından tasarlanan ve WCAG 3 Silver projesi altındaki aday algoritmadır. Simetrik oran yerine -108 ile +108 arasında polarite duyarlı Lc skorları kullanır. 2026 itibarıyla WCAG 3 hâlâ erken taslak ve APCA resmî olarak onaylanmadı; bugün vurmanız gereken düzenleyici standart WCAG 2.1 / 2.2 AA olmaya devam ediyor.
Dark mode kontrast erişilebilirliğine yardımcı olur mu?
Bazen, ama otomatik olarak değil. WCAG 2’nin simetrik oranı aynı kombinasyonları açık ve koyu modda geçer; ancak polarite duyarlı APCA, dark mode gövde metnini sıklıkla aynı hex çiftinin açık moddakine göre daha zor okunur olarak işaretler. Dark mode’u yayına almadan önce her zaman WCAG ve APCA’nın ikisine karşı yeniden test edin; açık-üstüne-koyu, simetrik oranın göremediği biçimlerde algılanan kontrast kaybeder.
Marka rengim neden WCAG AA’da çakıyor?
Doymuş orta-parlaklıklı renkler (çoğu turuncu, sarı, açık yeşil, açık mavi) 4,5:1’i geçmek için beyaza fazla yakın bağıl parlaklık değerlerine sahiptir. Çözüm: marka tonunu vurgular ve büyük başlıklar için tutun, ama gövde metnini aynı ton ailesinden daha koyu bir renkle eşleştirin. Tonu kaydırmadan L kanalını düşürmek için OKLCH kullanın; Renk Dönüştürücü, geçen en yakın tonu tek adımda bulur.
WCAG 2 oranları ve APCA skorları birbirine uyumlu mu?
Hayır. WCAG 2 simetrik bir oran (1–21) döndürür; APCA polarite işaretli bir Lc skoru (-108 ile +108 arası) döndürür. İlişki doğrusal değildir: WCAG’de 4,5:1 olan bir ikili, hangi rengin üstte olduğuna bağlı olarak APCA’da Lc 60 ya da Lc 75 puan alabilir. Bunlara birbirinin tercümesi değil, iki bağımsız kontrol olarak davranın.
Küçük UI ikonları için renk kontrastı kullanabilir miyim?
Evet, çekincelerle. WCAG 2.1 §1.4.11, UI bileşenleri ve grafik nesneler için ≥ 3:1 gerektirir. Görünür metin etiketiyle eşleştirilmiş dekoratif ikonlar için kontrast gereklilikleri gevşer; anlamı etiket taşır. Tek başına ikonlar için (örn. etiketsiz bir arama büyüteci), çevreleyen arka plana karşı tam 3:1’i zorunlu kılın.
Renk körlüğünü simüle etmeden nasıl test ederim?
Protanopia, deuteranopia, tritanopia ve achromatopsia için Chrome DevTools → Rendering → “Emulate vision deficiencies” kullanın. Anormal trikromasi varyantları için (en yaygını erkeklerin %5’iyle deuteranomalidir) Renk Dönüştürücü’nün 8 tipli CVD önizlemesiyle birleştirin. Denetim raporlaması için her simülasyon altında ekran görüntüleri yakalayın ki gözden geçirenler hata modlarını satır içinde görebilsin.
Sonuç
Beş çıkarım tüm rehberi taşır:
- AA 4,5:1 yasal tabandır. Tüm gövde metniniz için tutturun ya da uyumluluk gürültüsü bekleyin.
- AAA 7:1 sağlık, eğitim ve devlet içindir. Çoğu ticari marka tasarım gereği AA’da durur.
- APCA Lc, gerçek okunabilirlik sezgisel kontrolüdür. WCAG 2 ile paralel çalıştırın, özellikle dark mode ve doymuş marka renkleri için.
- Renk asla tek sinyal değildir. Her renk ipucunu şekil, metin ya da örüntü ile eşleştirin; tek başına deuteranomali erkek kullanıcıların %5’idir.
- OKLCH’in L’si doğru düğmedir. Bir renk kontrastta çaktığında, ton kaymadan düzeltmek için L’yi düşürün (S’yi değil, B’yi değil).
WCAG oranı, APCA Lc, gamut sınıflandırması ve 8 tipli CVD önizlemesini yan yana görmek için herhangi iki hex kodunu Renk Dönüştürücü’ye bırakın. Bu tek görünüm altı ayrı aracı yerine koyar ve bu rehberin tarif ettiği denetimleri kapatmanın en hızlı yoludur.