- Katılım
- 21 May 2023
- Mesajlar
- 496
- Tepki
- 17
- Puan
- 18
Bir renk çifti ekranda hoş görünebilir; buna rağmen küçük metni, form sınırını ya da grafikteki önemli bir çizgiyi seçmek zor olabilir. “Gözüme yeterince koyu geliyor” demek yerine WCAG 2.2 AA eşiklerini kullanınca karar, zevk tartışmasından çıkıp ölçülebilir hale geliyor.
Buradaki önemli ayrım şu: WCAG bir web içeriği standardıdır. Dijital afiş, sosyal medya görseli ve arayüz taslağı için güçlü bir kontrol çerçevesi sunar; fakat tek bir renk paletinin geçmesi, bütün sayfanın WCAG uyumlu olduğu anlamına gelmez.
W3C WCAG 2.2 içinde normal metin ve metin görselleri için AA düzeyindeki asgari oran 4,5:1. “Büyük ölçekli” metinde eşik 3:1; W3C bunu web sunumunda en az 18 punto normal veya 14 punto kalın metin olarak tanımlıyor. Bunlar CSS punto ölçüsüne dayanıyor ve yaklaşık 24 piksel ile 18,5 piksele karşılık geliyor.
Görsel düzenleme programındaki punto kutusunu körlemesine aynı eşik saymayın. Uygulamaların 72 veya 96 PPI gibi farklı varsayılanları sonucu değiştirebilir. W3C’nin verdiği örnekte 72 PPI bir görselde kullanıcıya gerçekten büyük ölçekli metin sunabilmek için yaklaşık 24 punto normal veya 19 punto kalın değer gerekebilir. Son dışa aktarımın sayfadaki görüntülenme boyutunu esas alın. Logo yazıları, salt dekoratif öğeler ve tesadüfen görünen metinler gibi istisnalar ayrıca belirtilmiş.
Bu eşikleri her renkli şekle aynen uygulamak doğru değil. Önce öğenin metin mi, işlevi anlatan bir arayüz bileşeni mi, bilgi taşıyan grafik mi, yoksa yalnız süs mü olduğuna bakmak gerekiyor. Özellikle ince yazı karakterlerinde sadece eşiği kıl payı geçmek yerine biraz güvenlik payı bırakmak daha rahat bir okuma sağlıyor.
Kontrast, iki rengin göreli parlaklığını karşılaştırıyor. W3C formülü şöyle:
Burada L1 daha açık, L2 daha koyu rengin göreli parlaklığı. sRGB kanalları 0–255 aralığından dönüştürülüyor; kırmızı, yeşil ve mavi için ağırlıklar sırasıyla 0,2126, 0,7152 ve 0,0722. Yani sadece hex kodundaki rakamları birbirinden çıkarmak geçerli bir kontrast hesabı değil.
W3C’nin minimum kontrast açıklaması eşik değerinin yuvarlanmaması gerektiğini özellikle söylüyor. Hesap 4,499:1 çıkarsa ekranda 4,50 diye gösterilse bile 4,5:1 şartını karşılamıyor.
Küçük bir sRGB hesabını beyaz zemin üzerinde üç griyle yeniden çalıştırdım. Kullanılan betik W3C’deki 0,04045 kanal eşiğini ve yukarıdaki parlaklık formülünü doğrudan uyguladı:
İlk iki gri yan yana neredeyse aynı görünebilir; ölçümün faydası tam da burada. Tasarım aracındaki renk seçicinin verdiği değerle dışa aktarılan son dosyanın renk uzayı da aynı olmalı. Aksi halde doğru hesap, farklı renge uygulanmış olur.
W3C 1.4.11 açıklamasına göre bir kontrolü ve nasıl kullanılacağını tanımak için gerekli görsel bilgi, komşu renklere karşı en az 3:1 olmalı. Form alanını belli eden sınır, seçili durumu gösteren işaret, tek başına anlam taşıyan ikon veya grafikte veriyi anlatan çizgi buna örnek olabilir. Pasif kontroller için istisna var; ayrıca her dekoratif çerçeveye zorunluluk yüklenmiyor.
Renk tek başına mesaj da taşımamalı. W3C’nin renk kullanımı ölçütü, hata veya başarı gibi bilgilerin yalnız kırmızı ve yeşille ayrılmamasını istiyor. İkon, metin etiketi, desen ya da belirgin bir şekil farkı eklemek bu sorunu çözer.
Tek bir ekran görüntüsünde geçer sonuç almak, tasarım sistemi büyüdüğünde yetmiyor. Küçük bir kayıt tablosunda ön plan rengi, arka plan rengi, hesaplanan ham oran, öğe türü ve kullanılan eşik yan yana tutulabilir. “Mavi 600 erişilebilir” gibi bağlamsız bir etiket yerine “Mavi 600, beyaz zeminde normal metin için geçti” notu daha doğru; aynı mavi farklı zeminde başarısız olabilir.
Yarı saydam katmanlarda da sadece görünen üst rengin hex kodunu ölçmeyin. Opaklık ve alttaki zemin birleşince oluşan son renk çifti hesaba girmeli. Açık ve koyu tema, hover, klavye odağı ve hata durumu ayrı renkler üretiyorsa her birinin kaydını ayrı tutun. Böylece sonradan yapılan küçük bir palet değişikliğinin hangi metin ve kontrolleri etkilediği bulunabilir.
Renk kararını bağlama oturtmak için grafik tasarımda renklerin etkileri, harf biçimi ve okunabilirlik için tipografide dikkat edilecek noktalar, daha geniş yaklaşım için de erişilebilir ve kapsayıcı tasarım konuları iyi birer devam niteliğinde.
Önce öğenin görevini belirleyin, sonra doğru eşiği seçin ve oranı yuvarlamadan kontrol edin. Tasarımınızda sınırda kalan bir renk çifti varsa hex kodlarını paylaşın; aynı hesap üzerinden birlikte okuyabiliriz.
Güncelleme: 16 Ağustos 2026. Eşikler ve formül, W3C’nin güncel WCAG 2.2 metniyle kontrol edildi.
Buradaki önemli ayrım şu: WCAG bir web içeriği standardıdır. Dijital afiş, sosyal medya görseli ve arayüz taslağı için güçlü bir kontrol çerçevesi sunar; fakat tek bir renk paletinin geçmesi, bütün sayfanın WCAG uyumlu olduğu anlamına gelmez.
Önce hangi öğeyi ölçtüğünüzü ayırın
W3C WCAG 2.2 içinde normal metin ve metin görselleri için AA düzeyindeki asgari oran 4,5:1. “Büyük ölçekli” metinde eşik 3:1; W3C bunu web sunumunda en az 18 punto normal veya 14 punto kalın metin olarak tanımlıyor. Bunlar CSS punto ölçüsüne dayanıyor ve yaklaşık 24 piksel ile 18,5 piksele karşılık geliyor.
Görsel düzenleme programındaki punto kutusunu körlemesine aynı eşik saymayın. Uygulamaların 72 veya 96 PPI gibi farklı varsayılanları sonucu değiştirebilir. W3C’nin verdiği örnekte 72 PPI bir görselde kullanıcıya gerçekten büyük ölçekli metin sunabilmek için yaklaşık 24 punto normal veya 19 punto kalın değer gerekebilir. Son dışa aktarımın sayfadaki görüntülenme boyutunu esas alın. Logo yazıları, salt dekoratif öğeler ve tesadüfen görünen metinler gibi istisnalar ayrıca belirtilmiş.
Bu eşikleri her renkli şekle aynen uygulamak doğru değil. Önce öğenin metin mi, işlevi anlatan bir arayüz bileşeni mi, bilgi taşıyan grafik mi, yoksa yalnız süs mü olduğuna bakmak gerekiyor. Özellikle ince yazı karakterlerinde sadece eşiği kıl payı geçmek yerine biraz güvenlik payı bırakmak daha rahat bir okuma sağlıyor.
Oranın arkasındaki hesap
Kontrast, iki rengin göreli parlaklığını karşılaştırıyor. W3C formülü şöyle:
Kod:
(L1 + 0.05) / (L2 + 0.05)Burada L1 daha açık, L2 daha koyu rengin göreli parlaklığı. sRGB kanalları 0–255 aralığından dönüştürülüyor; kırmızı, yeşil ve mavi için ağırlıklar sırasıyla 0,2126, 0,7152 ve 0,0722. Yani sadece hex kodundaki rakamları birbirinden çıkarmak geçerli bir kontrast hesabı değil.
W3C’nin minimum kontrast açıklaması eşik değerinin yuvarlanmaması gerektiğini özellikle söylüyor. Hesap 4,499:1 çıkarsa ekranda 4,50 diye gösterilse bile 4,5:1 şartını karşılamıyor.
Sınırdaki iki gri gerçekten ne söylüyor?
Küçük bir sRGB hesabını beyaz zemin üzerinde üç griyle yeniden çalıştırdım. Kullanılan betik W3C’deki 0,04045 kanal eşiğini ve yukarıdaki parlaklık formülünü doğrudan uyguladı:
- #777777 / #FFFFFF: 4,478089:1. Normal metin için 4,5:1 eşiğini geçmiyor.
- #767676 / #FFFFFF: 4,542225:1. Normal metin için eşiği geçiyor.
- #94A3B8 / #FFFFFF: 2,564041:1. Ne normal metnin 4,5:1 ne de 3:1 eşiğinin üzerinde.
İlk iki gri yan yana neredeyse aynı görünebilir; ölçümün faydası tam da burada. Tasarım aracındaki renk seçicinin verdiği değerle dışa aktarılan son dosyanın renk uzayı da aynı olmalı. Aksi halde doğru hesap, farklı renge uygulanmış olur.
Metin dışındaki öğelerde 3:1 ne zaman devreye girer?
W3C 1.4.11 açıklamasına göre bir kontrolü ve nasıl kullanılacağını tanımak için gerekli görsel bilgi, komşu renklere karşı en az 3:1 olmalı. Form alanını belli eden sınır, seçili durumu gösteren işaret, tek başına anlam taşıyan ikon veya grafikte veriyi anlatan çizgi buna örnek olabilir. Pasif kontroller için istisna var; ayrıca her dekoratif çerçeveye zorunluluk yüklenmiyor.
Renk tek başına mesaj da taşımamalı. W3C’nin renk kullanımı ölçütü, hata veya başarı gibi bilgilerin yalnız kırmızı ve yeşille ayrılmamasını istiyor. İkon, metin etiketi, desen ya da belirgin bir şekil farkı eklemek bu sorunu çözer.
Dosyayı teslim etmeden önce kısa kontrol
- Metin, arka plan, kontrol sınırı ve bilgi taşıyan grafikleri ayrı ayrı sınıflandırın.
- Normal metinde 4,5:1; büyük metinde ve gerekli metin dışı görsel bilgide ilgili 3:1 eşiğini denetleyin.
- Degrade veya fotoğraf üzerindeki yazıyı, karşılaşacağı en zayıf tipik arka plan bölgesinde de ölçün.
- Web arayüzünde harfin yumuşatılmış kenar pikselini değil, tanımlanan metin ve zemin renklerini esas alın; W3C metin değerlendirmesinde kenar yumuşatmanın kapalı kabul edilebileceğini belirtiyor.
- Normal, odaklanmış, seçili ve hata durumlarını ayrı ekranlarda gözden geçirin.
- Oranı yuvarlamadan kaydedin; sınırdaysa daha koyu ya da daha açık güvenli bir ton seçin.
Renk tablosunu kanıtla birlikte saklayın
Tek bir ekran görüntüsünde geçer sonuç almak, tasarım sistemi büyüdüğünde yetmiyor. Küçük bir kayıt tablosunda ön plan rengi, arka plan rengi, hesaplanan ham oran, öğe türü ve kullanılan eşik yan yana tutulabilir. “Mavi 600 erişilebilir” gibi bağlamsız bir etiket yerine “Mavi 600, beyaz zeminde normal metin için geçti” notu daha doğru; aynı mavi farklı zeminde başarısız olabilir.
Yarı saydam katmanlarda da sadece görünen üst rengin hex kodunu ölçmeyin. Opaklık ve alttaki zemin birleşince oluşan son renk çifti hesaba girmeli. Açık ve koyu tema, hover, klavye odağı ve hata durumu ayrı renkler üretiyorsa her birinin kaydını ayrı tutun. Böylece sonradan yapılan küçük bir palet değişikliğinin hangi metin ve kontrolleri etkilediği bulunabilir.
Renk kararını bağlama oturtmak için grafik tasarımda renklerin etkileri, harf biçimi ve okunabilirlik için tipografide dikkat edilecek noktalar, daha geniş yaklaşım için de erişilebilir ve kapsayıcı tasarım konuları iyi birer devam niteliğinde.
Özetle
Önce öğenin görevini belirleyin, sonra doğru eşiği seçin ve oranı yuvarlamadan kontrol edin. Tasarımınızda sınırda kalan bir renk çifti varsa hex kodlarını paylaşın; aynı hesap üzerinden birlikte okuyabiliriz.
Güncelleme: 16 Ağustos 2026. Eşikler ve formül, W3C’nin güncel WCAG 2.2 metniyle kontrol edildi.
Dijital Dünyanıza Yön Veren Pusula
